12 — Impact on Phase-1 Build (Branch K)

Branch K. Can the Phase-1 foundation build proceed safely (kept inactive/empty), or must it wait for this addendum? Precise per-item classification. Verdict: The Phase-1 substrate spine can build after the authorization-model change is ratified (then per-step L3-authorized, kept empty/inactive). T6/T7, backfill, topic/IU operational activation, and the axis content layer wait for (a) this axis model's detailed-design acceptance and (b) C-7 input-trust rulings. Aligns with GPT direction.

---

12.0 The gating realization

The prior blocker was never "engineering not ready" — implementation-index docs 87–92 show the spine rehearsed-green (entry==exit, F-83-1 fix found). The blocker was authorization (M-1 = a human e-sign an agent can't write). Therefore:

The single thing that unblocks Phase-1 controlled build is the authorization-model change (doc 02): redefine M-1, create governance_build_authorization, add build-auth action types, reserve os_proposal_approvals for L4. That change is itself a governance decision (council L2 + sovereign ratification, because it alters the authority model), not a large engineering task.

Once that lands, each spine step builds under a per-step L3 build-authorization — no President e-sign per step.

12.1 Classification

Class 1 — Build now is still NO-GO; needs the authorization-model decision first (the gate)

Item	Why	Authority needed
Authorization-model change: redefine M-1; create governance_build_authorization + v_build_auth_valid; add apr_action_types rows (authorize_build_step, activate_event_type, register_axis, register_topic_node); reserve os_proposal_approvals=L4-only	It changes the authority model itself → sovereignty threshold (doc 02 §02.6)	L2 council decision + L4 sovereign ratification (one-time, constitutional). After this, M-1 is per-step build-auth.

This is the critical path. It is a decision, recorded in the approval spine + an e-sign for the model change — not a refusal point for routine builds thereafter.

Class 2 — Build after the authorization model lands (then L3-authorized, empty/inactive)

Item	State	Notes
SB-12 governance_ruleset (+ snapshot reuse)	rehearsed-green	draft row, NOT activated
SB-13 gov_worker_cursor family (+ queue_heartbeat reuse)	rehearsed-green	F-57-1 fold-in
SB-10 governance_candidate_state (+ scan run)	rehearsed-green	decaying verdict; no checked-forever boolean
SB-11 governance event domain (register-before-emit)	rehearsed-green	rows active=false (no emit) — F-57-2/3/4 fold-ins
SB-2 governance_responsibility_scope + governance_object_ownership + resolution view	rehearsed-green	enables axis owners (doc 03/09); 5 neg tests passed
SB-1 APR action-types (Phase-A handler_ref='unimplemented')	rehearsed-green	F-83-1 birth-trigger fix mandatory before the 4 INSERTs

These are additive, reversible, kept empty/inactive; each builds under its own L3 build-auth (doc 02 §02.3) with the implementation-index rollback runbook (doc 71). No T6/T7, no backfill, no activation, no UI (Phase-1 scope, implementation-index doc 93).

Class 3 — Build after this axis model's detailed design is accepted

Item	Depends on
axis_registry (M-DEF-9 nine attributes; generalizes taxonomy_facets)	doc 03 accepted; SB-2 owners built (Class 2)
axis_assignment (semantic confidence/evidence/zone)	doc 04 accepted
SB-3 generalization (envelope → projection of axis_registry; remove hardcoded-3)	axis_registry exists
FAC-08 topic activation (max_labels_per_entity > 0; cardinality decision)	council L2 decision; axis model accepted
pre-register AX-RECON / AX-CONTAINMENT / AX-TOPIC rows	axis_registry exists

Class 4 — Defer (need both models + C-7 rulings + Điều 38/39 reconcile)

Item	Blocker
T6 governance coverage scanner activation (DOTs live)	axis model + SB-10/11 active; C-7 input-trust ruling
T7 issue/event emit (active=true)	event domain activated (register-before-emit complete); materiality threshold set
Backfill seed (existing objects → governance onboarding)	C-7 backfill-ruleset; 60-day legacy cut-over ruling
Topic promotion to official UI	FAC-08 active; axis_assignment live; coverage live
KG-assisted dynamic topic activation	Điều 39 KG + NĐ-36-01 soft-relation substrate (entity_relations) built (currently unbuilt — doc 01)
IU island dissolution (owner, central APR migration)	OP-B/SB-2 owner ratification; C-4 review_decision adapter ruling
Mutating apply DOT (dot_governance_assignment_apply)	A-9 (H-1/H-2/SB-6) — forbidden until then (implementation-index doc 72)

12.2 Build order implication

1. Decision: ratify the authorization-model change (Class 1) — council + sovereign, one time.
2. Spine: build SB-12 → SB-13 → SB-10 → SB-11(inactive) → SB-2 → SB-1 (Class 2), each per-step L3-authorized, empty/inactive (implementation-index doc 94 order; SB-12 before SB-10 FK; SB-1 last by risk).
3. Axis content: accept docs 03/04 detailed design → build axis_registry + axis_assignment + SB-3 generalization (Class 3).
4. Activation: C-7 rulings → T6/T7/backfill/topic-UI (Class 4).

12.3 Can the spine build "empty/inactive" safely before the axis model? — Yes

Class-2 items are governance substrate (rulesets, cursors, candidate-state, event domain inactive, ownership, action-types) — they hold no axis content and emit nothing. They are safe to build empty/inactive under L3 authorization, independent of the axis content layer (Class 3). This matches GPT's guidance exactly: "Phase 1 foundation substrate can still proceed after the authorization issue is solved if it remains empty/inactive, but T6/T7/backfill/topic/IU operational activation must wait for this addendum."

12.4 Verdict

Phase-1 is unblocked by a decision, not by engineering. Ratify the authorization-model change (Class 1) → the rehearsed-green spine builds under per-step L3 authorization, empty/inactive (Class 2). The axis content layer (Class 3) follows this package's detailed-design acceptance; operational activation (Class 4) waits for C-7 rulings and the Điều 38/39 reconcile. No build or COMMIT is performed or authorized here.