08 — Workstream G: Governance Handoff Integration Design

Principle: governance stays decoupled. Birth/admission blocks creation; governance coverage may block activation/use — never birth. The handoff must lose nothing and must not create an inline dependency from birth to governance.

Current state (live)

Object	State	Role
event_type_registry → handoff.object_born	registered, active = false	when inactive, the event is captured (to event_pending), not emitted/delivered
event_pending	present	capture buffer for not-yet-active events
registry_changelog	70,434 rows	the durable BORN/change tail (CDC source)
governance_candidate_state	present	per-object dirty/candidate intake state
governance_build_authorization (OSPA)	0 rows → NO-GO	governance build/activation gate

Integration design (0 new tables)

A decoupled cursor-tail / CDC consumer:

birth_registry BORN tail  ─┐
registry_changelog (70434) ─┼─► cursor consumer ─► upsert governance_candidate_state(dirty=true)
                            │                     ─► emit-or-capture handoff.object_born
                            │                          • event active=true  → emit to delivery lane
                            └                          • event active=false → capture to event_pending

• The consumer is pull/tail-based: reads the BORN tail and registry_changelog past a stored cursor. Birth does not call the consumer inline — no birth → governance call in the hot path, so governance being down/idle never blocks a birth.
• For each newly BORN object: upsert governance_candidate_state (dirty=true), then handoff.object_born: if active=true emit to lane; if active=false (today) capture to event_pending. Either way durably recorded — no-lost-handoff.

What blocks what (the decoupling contract)

Layer	Blocks	Does NOT block
Birth admission permit	object creation (no permit → no row)	governance
Governance coverage / OSPA	governed activation / use where policy requires coverage	birth / object creation
RP/DOT preflight guard	RP cleanup & DOT mutation actions (4 BLOCK dims)	birth of new objects

A dot_tools row can be born today (permit gate, once applied) even with OSPA=0; it enters event_pending/candidate_state and cannot be governed-activated until OSPA ≥ 1.

Exact OSPA gate

Governance activation of captured candidates requires:

(SELECT count(*) FROM governance_build_authorization) >= 1   -- currently 0

Until then handoff is capture-only: candidates accumulate with no activation. Intentional and safe — nothing lost, nothing prematurely activated.

No-lost-handoff proof obligation (for apply)

1. Cursor is persisted and advanced only after the candidate upsert + capture succeed in the same transaction.
2. Re-running from the stored cursor is idempotent (governance_candidate_state upsert by object key; event_pending insert guarded by unique (event_type, object_key, born_at)).
3. Reconciliation view v_handoff_lag = BORN objects with no candidate row → must trend to 0; non-zero = consumer behind.

Heartbeat / freshness requirement

A handoff_cursor_heartbeat timestamp advances each run. If now() - heartbeat > threshold, the drift monitor (doc 09) flags the handoff stale and the post-create guard treats coverage claims as unknown (fail-closed for activation, never for birth).

Decision

HANDOFF = design-clear, decoupled, 0-new-tables, capture-only until OSPA ≥ 1. Activation gated by human OSPA seed (the single non-engineering blocker for the governance layer). Birth is independent of it.