02 — Governance Compatibility Matrix

Purpose. Prove, axis by axis, that the No-Vector Staging Zone is governed exactly like the rest of the system, with vector exclusion as the only exception. Parent: 01-d36-no-vector-staging-zone-addendum.md.

If any cell of this matrix shows "different" for any axis other than the vector axis, the addendum is broken and the implementation must be blocked.

---

1. Headline contract

governance_compatibility:
  same_as_system:
    - collection_birth         # Điều 0-G + Điều 36
    - species_mapping          # Species Law v0.5
    - birth_registry           # Điều 0-G universal counter
    - collection_registry      # tbl_registry_collections + purpose REQUIRED
    - purpose_required         # collection_registry.purpose NOT NULL
    - lifecycle                # Điều 36 lifecycle + state machine
    - audit                    # event_outbox / safe_payload trail
    - DOT                      # dot_iu_command_catalog entries
    - rollback                 # REFUSED-guarded fn + paired DOT
    - healthcheck              # runtime/110 D9 conformance
  different_only:
    - vector_embedding_excluded
    - semantic_search_excluded
    - Qdrant_excluded

---

2. Point-by-point matrix

Axis	Normal governed collection	No-Vector Staging Zone	Same?
Governance role	governed	governed	✅ same
Allowed governance roles	governed / observed / excluded	only governed (observed/excluded forbidden — design constraint)	✅ same baseline; staging is more restrictive, not less
Species mapping	Must have a species (SPE-xxx)	Must have a species — proposed SPE-NVS (no_vector_staging)	✅ same
Birth registry row	One row per entity (Điều 0-G)	One row per staging item (PG trigger on iu_staging_record insert)	✅ same
collection_registry entry	Required, with purpose	Required, with purpose	✅ same
purpose field	NOT NULL, human description	NOT NULL, human description (e.g. "MARK manifest staging for IU-Core cut workflow")	✅ same
Lifecycle column	lifecycle_status enum	lifecycle_status enum — see 03-…-architecture.md §5	✅ same
Lifecycle state transitions	Guarded by trigger / fn	Guarded by fn_iu_staging_transition + lifecycle check	✅ same
Audit trail	event_outbox with safe_payload	event_outbox with safe_payload, event_domain = 'staging'	✅ same
DOT-only writes	Raw psql forbidden	Raw psql forbidden	✅ same
DOT command registration	dot_iu_command_catalog row + dot_iu_command_run audit	Same; new DOTs dot_iu_staging_create / approve / consume / reject / cleanup	✅ same
Rollback path	REFUSED-guarded fn or paired DOT	REFUSED-guarded fn + paired DOT (dot_iu_staging_unregister proposed)	✅ same
D9 / DOT conformance	SSOT inventory bump same commit	SSOT inventory bump same commit	✅ same
Pinning tests	Bump per macro	Bump per macro	✅ same
Directus exposure	Optional; if exposed → tbl_registry_collections row + UI	Same; staging tables likely surface under /knowledge/registries/staging page	✅ same
Permissions / role	workflow_admin owns; directus reads	Same; writes via DOT under workflow_admin	✅ same
Trigger guard (dot-trigger-guard)	Applies	Applies	✅ same
Healthcheck inclusion	Included in IU-Core healthcheck if IU-Core; otherwise own healthcheck	New healthcheck fn_iu_staging_healthcheck covering vector-exclusion invariant + lifecycle counts + retention status	✅ same shape
Backup / pg_dump	Included	Included	✅ same
Retention policy	Optional iu_core_retention_policy row	Required iu_core_retention_policy row (staging is by definition temporary; retention is part of contract)	✅ same mechanism; staging is stricter
Cleanup contract	Per-collection	Per-collection, plus mandatory consumed → cleaned transition	✅ same mechanism
Reference (Điều 37)	May reference other governed entities	May reference other governed entities (e.g. a staging MARK manifest references a directus_file source)	✅ same
Vector embedding	Vectorized if eligible	NEVER vectorized — Rule N1	❌ different
Qdrant point creation	Created on emit	Never created	❌ different
Semantic search inclusion	Eligible	Excluded for normal-mode queries; explicit include_staging=true may be considered (review question)	❌ different
Connector lane	Default lanes	Hard skip-list (species-level or collection-prefix-level)	❌ different

Result. Of 24 governance axes, 21 are identical, 3 are "vector excluded". Rule N1 from 01-…-addendum.md is the only substantive departure from the normal governed regime.

---

3. Where staging is stricter, not looser

It is worth highlighting these — they are deliberate and prevent the zone from becoming an ungoverned shadow area:

1. governance_role = governed only. observed and excluded are forbidden. Reason: staging items must be counted by the universal counter.
2. Retention policy REQUIRED. A staging collection without an iu_core_retention_policy row is non-compliant. Reason: "temporary" without retention is just a leaky permanent.
3. DOT-only writes — no exception. Even INSERT … RETURNING from inside another stored procedure must go through fn_iu_staging_create. Reason: audit and lifecycle integrity.
4. Cleanup is part of the contract. A staging collection's healthcheck fails if the cleaned/consumed ratio drifts from policy.

---

4. Where staging is narrower, not wider

• No staging item may be promoted to a permanent governed entity by direct state transition. Promotion is always: staging consumed → a separate governed write of a new permanent entity (with its own birth registry row).
• No staging collection may opt back into vector embedding by flag. To bring data into vectors, copy it to a non-staging collection and let normal sync apply.

These narrowness rules prevent silent re-classification.

---

5. Acceptance criterion for this matrix

The matrix is accepted as a design artifact iff:

• Every "same" cell has a named existing mechanism (column / table / fn / DOT / event).
• Every "different" cell is traceable to Rule N1.
• No cell is "different" along an axis other than the vector axis.

The current matrix satisfies all three. The matrix's machinery is detailed in the next four docs:

• 03-sql-nosql-staging-architecture.md — substrate
• 04-vector-exclusion-contract.md — Rule N1 enforcement
• 05-birth-protocol-plan.md — birth + registry + DOT
• 06-mark-workflow-integration.md — MARK→REVIEW→CUT→VERIFY consumes this zone