Branch A — Human / Council Ratification Packet (MOW Design Registry Phase 1)

For: GOV-COUNCIL (Hội đồng Kiến trúc) + MOW owner sign-off · Decision instrument: Điều 32 approval + cross-sign ≥ 2 in apr_approvals. Prepared by: automated agent (proposal only — no self-approval).

---

0. Prior-artifact classification

A live scan was performed for an existing valid approval artifact authorizing the additive EXTEND commit:

• approval_requests (211 rows) — request_type vocabulary present: accuracy_drift, birth_orphan, fix_repair_dot, new_dot, reclassify, schema_add, schema_modify. No row with entity_type/entity_code referencing the MOWD additive EXTEND or its FKs in approved/applied state.
• apr_approvals (42 rows) — no cross-signed approval bound to a MOWD design-extend request.
• workflow_change_requests (3 rows) — all scoped to per-workflow step edits on WF-001 (add_step/add_block), not schema-level.

Verdict: NO valid approval artifact exists. Therefore this packet is the request; the agent does not self-approve. Commit (doc 02) is gated on the human/council decision recorded here.

1. What is being approved (scope)

A single additive, nullable-only schema extension to three existing tables, plus 8 NOT VALID foreign keys and 2 read-only views — exactly as dress-rehearsed GREEN (twice: prior campaign + this session).

workflows                +8 nullable columns
workflow_steps           +7 nullable columns
workflow_step_relations  +1 nullable column
+ 8 FK constraints created NOT VALID (no scan, no rewrite)
+ 2 read-only views (v_mow_design_workflow, v_mow_design_step)

Columns (all NULLable, no default that rewrites):

• workflows: owner_gov_code, design_iu_ref, active_design_version, freeze_active, freeze_reason, freeze_at, freeze_by, design_health
• workflow_steps: step_iu_ref, guide_iu_ref, dot_ref, output_table_ref, event_domain_ref, event_type_ref, step_version
• workflow_step_relations: condition_iu_ref

Not in scope of this approval: any data backfill, any IU binding, any DOT execution, any UI, any runtime, any VALIDATE CONSTRAINT (that is a separate off-peak step, see doc 02 §7).

2. Why it is safe

1. Additive & nullable-only — no existing column changed, no NOT NULL, no DEFAULT that triggers a table rewrite. Existing rows are untouched (no data rewrite guarantee, doc 02 §11).
2. FK = NOT VALID — Postgres adds the constraint metadata without scanning existing rows; no AccessExclusiveLock-held full scan. Future rows are checked; legacy rows validated later off-peak.
3. Rehearsed twice, GREEN — BASE 17/20/8 → 25/27/9 → ROLLBACK → 17/20/8, 0 leftover views, 0 idle-tx. Smoke queries on both views returned (2 wf rows, 70 step rows).
4. Views are security_invoker-style read models — no SoT duplication, no write path.
5. Gates unaffected — fn_iu_gate_verify_closed() all_safe=true before and after; no governable gate flipped; never_flip intact.

3. Why this creates no second source-of-truth

The design bodies (narrative, step guides, conditions) are not copied into new tables. They are moved to information_unit (the canonical IU SoT) and referenced by uuid (design_iu_ref, step_iu_ref, guide_iu_ref, condition_iu_ref). The new columns are pointers, not payload. The 2 views are projections, not stores. The legacy inline columns (bpmn_xml, narrative, description, trigger_*_text) remain as the migration source and are retired forward-only (doc 05), never duplicated.

4. Why MOW remains owner (no fifth Mother)

owner_gov_code points to governance_registry(code); for workflows it resolves to GOV-MOW. There is no GOV-MOWD row and none is proposed. "MOWD" names a subdomain of MOW's design responsibility, governed under MOW's existing capability (can_create:[workflows]). No new factory, no new can_create family, no ownership transfer.

5. What is deferred (explicitly NOT Phase 1)

• Workflow/task runtime generation; MOIT/MOUT production form/report generation.
• workflow_trigger_design, assignee_policy, the 6 tbl_* hierarchy tables, scanner/detector — Phase 2 (new design-only tables via birth contract under Điều 36/37).
• VALIDATE CONSTRAINT on the 8 FKs — separate off-peak operation after legacy rows are clean.
• Nuxt UI implementation (Điều 28).

6. What is forbidden (binding on the executor)

No committed DDL without this approval; no Directus/Qdrant/vector write; no event delivery/job execution; no agent self-approval; no MOWD as fifth Mother; no inline long-text where an IU ref applies; no open idle transaction; no client-timeout-kill of an open psql.

7. Rollback (Điều 30)

Single reversal script (doc 02 §6): DROP VIEW ×2, ALTER TABLE … DROP CONSTRAINT ×8, ALTER TABLE … DROP COLUMN ×16. Because all additions are nullable and unpopulated at commit time, rollback is byte-clean. Preferred long-term reversal is forward-only soft-retire (version-pin + freeze) per Điều 30; hard DROP is available pre-population.

8. Evidence the dress rehearsal is GREEN

Stage	workflows cols	steps cols	rel cols	FK NOT VALID	views	idle-tx
BASE	17	20	8	0	0	0
IN_TX	25	27	9	8	2	—
POST-ROLLBACK	17	20	8	0	0	0

Smoke: v_mow_design_workflow → 2 rows; v_mow_design_step → 70 rows. Run under server-side statement_timeout=30s, lock_timeout=5s, idle_in_transaction_session_timeout=20s.

9. Exact approval wording (to be recorded by a human)

MOWD-PHASE1-EXTEND-APPROVAL. The Architecture Council and the MOW owner approve the additive, nullable-only EXTEND of workflows (+8), workflow_steps (+7), and workflow_step_relations (+1), with 8 NOT VALID foreign keys and 2 read-only views, exactly as specified in commit-readiness pack doc 02 of mow-design-registry-phase1-...-2026-05-29. This approval authorizes the additive DDL commit only; it does NOT authorize constraint validation, data backfill, IU binding, DOT execution, UI, or runtime, each of which requires its own approval. MOW remains sole owner; no fifth Mother is created. Reversal is the script in doc 02 §6 (preferred: forward-only soft-retire). Cross-signed by ≥2 council members below.

Recording (human action):

1. Insert one approval_requests row: request_type='schema_add', entity_type='schema.mowd', entity_code='MOWD-PHASE1-EXTEND', proposed_action = JSON pointer to doc 02, status='approved', reviewed_by=<council>.
2. Insert ≥2 apr_approvals rows (apr_id=above, distinct approver, approver_type='human', decision='approve', rationale).
3. Only then execute doc 02 in the off-peak window.

10. Ratification readiness verdict

READY. Packet is self-contained and human-executable. No valid prior artifact exists; agent has not self-approved. The single human decision required is the recorded Điều 32 approval above.