IU Core Runtime Activation E2E — 04 Parallel trigger path ruling

The two sinks for version_applied

public.unit_version carried 4 triggers before this macro. The relevant one:

• Existing: trg_aa_iu_notif_version → fn_iu_notif_version (SECURITY DEFINER). Fires AFTER INSERT only when version_seq > 1; writes a version_applied row into public.iu_notification_event (the directus-facing UI notification feed), source='trg_aa_iu_notif_version'.
• New (runtime/030): trg_iu_out_version → fn_iu_outbound_on_version → fn_iu_emit_event. Fires AFTER INSERT on every version; writes into public.event_outbox (the governed cross-domain workflow/DOT event bus). Fail-closed behind the master gate.

Ruling: COEXIST — attach trg_iu_out_version alongside the existing trigger

Evidence and rationale:

1. Different sinks, different consumers. iu_notification_event is a user-facing notification table; event_outbox is the machine event bus consumed by route workers / DOT. They are complementary, not redundant — neither delivers what the other does.
2. Attaching is risk-free. Both trigger functions are fail-closed: they no-op while dot_config 'iu_core.routes_master_enabled' is not 'true'. Attaching trg_iu_out_version changes zero behaviour until the master gate opens (proven in doc 06 SECTION 1).
3. The event bus is the point of IU Core. Suppressing trg_iu_out_version would defeat the runtime layer's two-way event/route model.
4. Replacing/suppressing the existing trigger is out of scope. trg_aa_iu_notif_version is a pre-existing production trigger feeding a live UI on a non-iu-core object; mutating it is a separate blast radius and not approved by this macro.

Documented divergence for the route-enable macro

The existing path filters version_seq > 1; the new path emits on every version (including version_seq = 1). The separate route-enable macro must decide whether event_outbox should also filter first versions or treat the first version as a meaningful bus event. This is a route-enable-stage decision; at attach + gate-closed it is moot.

DDL guard note

CREATE TRIGGER fires evt_trigger_guard_ddl; DROP TRIGGER fires evt_trigger_guard_drop. Both guard functions are log-only — they INSERT into trigger_guard_alerts and RAISE WARNING, but never RAISE EXCEPTION. They permit any trigger DDL and merely audit it.