KB-3C33

20 — SB-1/SB-2 Integration & Implementation Readiness (design-only, 2026-06-01)

14 min read Revision 1
one-roof-governanceimplementation-indexsb-1sb-2integrationimplementation-readinessdieu37-hubdieu32dieu31-sivdieu35-dotdieu45no-local-islandgate-tableverdictdesign-only2026-06-01

20 — SB-1 / SB-2 Integration & Implementation Readiness

Tier: integration design + readiness verdict (design-only). Mutation footprint: none (KB doc only). Inputs: docs 16 (SB-1), 17 (SB-2), 18 (evidence), 19 (rehearsal); concept canon 01/02/03; blocker register doc 03. Purpose: (a) define how SB-1+SB-2 integrate across the one roof; (b) prove no local governance island is introduced; (c) state a clear implementation-readiness verdict + remaining gates.


1. Integration matrix (data path · approval path · audit path · failure mode · no-island proof)

Reading key: D=data path, A=approval path, Au=audit path, F=failure mode, NI=no-local-island proof.

1.1 One-Roof Concept Canon (knowledge/dev/design/one-roof-governance-concepts/)

  • D: SB-1 action-types realise the M-DEF-6 exception contract + the M-DEF-3 owner-assignment verb; SB-2 realises the M-DEF-1/2/3/7/8 owned-object/axis substrate. Au: the canon stays read-only reference (it is not edited by implementation). F: drift between a concept card and the substrate → reconcile to the canon (it wins over pre-patch text). NI: SB-1/SB-2 are the substrate the canon's contracts reconcile against — one vocabulary, one store; nothing local.

1.2 Điều 37 hub (OWN: definitions/contract; mechanism = REFERENCE)

  • D: Đ37 §4.15-bis owns "one accountable owner per scope"; SB-2's governance_object_ownership is the store that realises it; Đ37 §4.15-d owns the exception contract; SB-1's grant_governance_exception realises it. A: Đ37 references Đ32 for approval — SB-1 routes through Đ32, never a Đ37-local approver. Au: Đ37 §5.5 audit loop activates over registry_changelog/event_outbox (SB-7), not a new audit roof. F: Đ37 absorbing a mechanism (bloat) → rejected by the OWN/REFERENCE split. NI: Đ37 = the single roof; SB-1/SB-2 are mechanisms it points to, not duplicates.

1.3 Điều 32 approval spine

  • D: SB-1 action-types are apr_action_types rows; an owner/exception/delegation/axis change is an approval_requests row with proposed_action_code=<SB-1 code>. SB-2 rows are written only by SB-1 handlers (with approval_ref). A: quorum via fn_apr_quorum_check keyed to risk_level (high = president+2 council); self-approve prohibited; reject blocks; action≠'add' to avoid the auto-approve bypass (doc 18 §4.3). Au: the APR row + apr_approvals votes are the approval audit. F: auto-approve bypass / premature handler (docs 16 §8). NI: one spine, one quorum function; no parallel approver.

1.4 Điều 31 / GOV-SIV (health & detection)

  • D: GOV-SIV's coverage scanner (future T6) reads v_object_owner_gap/v_object_effective_owner (SB-2) to detect OWNER_GAP/conflict, and proposes remediation by raising an APR with an SB-1 action-type. A: SIV proposes; COUNCIL approves; SIV never self-applies. Au: findings → system_issues (reuse thiếu_quan_hệ/sai_lệch_dữ_liệu; new types via SB-4). F: per-row issue spam at scale → coalesce at governance grain (M-DEF-7/anti-spam; live template_gap machinery). NI: detection obligation is Đ37's; mechanism is Đ31's — referenced, not re-rooted.

1.5 Điều 35 / GOV-DOT (execution)

  • D: Phase-B SB-1 handlers are governed DOTs (the handler_ref targets) that write SB-2 rows; they reuse the existing governance.approval propose/execute/health coverage (dot_coverage_required, doc 18 §6.4). A: a DOT executes only an approved APR (Đ32); handler_ref='unimplemented' keeps it inert until ratified. Au: DOT execution → registry_changelog + event_outbox. F: a DOT writing to a private owner store → island. NI: the DOT's only owner-write target is governance_object_ownership; pinned by handler contract + CI island scan.

1.6 Điều 45 (event/queue, register-before-emit)

  • D: SB-1/SB-2 events (governance.owner.assigned/.conflict, governance.exception.granted/.expired, governance.authority.delegated/.expiring, governance.axis.owner_assigned) emit to event_outbox as signal not data (payload_classification='safe_metadata', safe_payload jsonb; event_subject_table/ref). A: each (event_domain,event_type) must be registered in event_type_registry first (a GOV-SIV-owned governance domain) — register-before-emit. Au: the outbox row is the event audit. F: unregistered emit → forbidden (the registry gate). NI: one event substrate; no local event bus. (Event-type registration itself is T7, not done here.)

1.7 system_issues

  • D: OWNER_GAP→thiếu_quan_hệ; conflict→new SB-4 type; drift→sai_lệch_dữ_liệu. A: issues are findings, not approvals; remediation routes via Đ32. Au: system_issues rows with coalesce_key/occurrence_count. F: free-text issue_type (no CHECK) → register the governance types (SB-4/T7) to avoid typo-drift. NI: reuse the one issue substrate.

1.8 registry_changelog / event_outbox / audit

  • D: every SB-1 apply / SB-2 write emits a registry_changelog row (generic entity audit) + an event_outbox signal. Au: governance_audit_log stays relation-scoped (its FK is to governance_relations) — object-ownership audit uses registry_changelog (doc 18 §6.1). F: trying to audit object ownership through governance_audit_log (no object FK) → use changelog instead. NI: reuse the two live audit channels; do not mint a third.

1.9 Registries-Pivot (live surface; T9)

  • D: a pivot/collection is object_type in SB-2; a grouping dimension is an axis (M-DEF-8) ownable via assign_axis_owner. The surface consumes governance reads; it does not own. A: any surface-initiated governance change routes through Đ32. Au: unchanged shipped views/endpoints. F: conflating the UI "count>1 ⇒ drill" sense with the governance candidacy sense (M-DEF-10) → keep them distinct. NI: the surface reads the one roof; it mints no local owner/approval/policy (doc 18: no owner_gov_code columns on its tables).

1.10 IU open-axis model (OP-B boundary; T10)

  • D: an IU class is an object_type; IU owner-binding lands in governance_object_ownership once OP-B (C-3) + C-4 rule; the 3 IU axes (origin/specialization/parent-child) are ownable axes via assign_axis_owner. A: IU owner assignment is an SB-1 APR; C-4 decides whether IU's review_decision is a governed approval-adapter exception. Au: changelog/outbox. F: binding IU owner before OP-B → HELD. NI: IU reuses the one roof; information_unit.owner_ref free-text (219 rows, all conformance open) is replaced by a resolved owner via SB-2, not a local IU owner table.

1.11 Future Axis Registry (M-DEF-9) + SB-3

  • D: assign_axis_owner targets axis_codes that (end-state) live in the Axis Registry; SB-2 stores the axis→owner row with object_type='axis'. Independent of SB-3 (axis-value storage). A: axis ownership is an SB-1 APR. Au: changelog/outbox. F: assuming SB-3 must land first → it must not; ownership ≠ value storage (doc 18 §7). NI: axis is the same object contract applied to a dimension; no axis-specific roof.

1.12 Future governance scanner (T6)

  • D: the scanner reconciles the coverage invariant v3 against SB-2's views and proposes SB-1 APRs; its DOT coverage rows (governance.coverage/classification/pivot/axis/iu) are SB-8/T6. A: scanner proposes; COUNCIL approves. Au: findings→issues, applies→changelog/outbox. F: scanner applying directly → forbidden (propose-only). NI: the scanner is the detection mechanism under Đ31/Đ37; it writes nothing without Đ32.

2. No-local-governance-island proof (consolidated, dual-channel — canon §5)

SB-1 + SB-2 introduce no second roof. Proof along the canon's two detection channels:

PG-detectable channel (no-owner-table / owner-constant-in-data):

  • SB-1 adds rows to the existing apr_action_types (FK target of the existing approval_requests); it creates no parallel action vocabulary.
  • SB-2 creates one ownership store governance_object_ownership, FK'd into the existing governance_registry; it adds no owner_gov_code column to any domain table (the relational-ownership model is preserved) and writes no owner-constant into config.
  • Quorum (fn_apr_quorum_check), block-unimplemented, audit (registry_changelog), and events (event_outbox/event_type_registry) are all reused, not duplicated.

CI / source-scan channel (local-approval-flag / owner-hardcoded-in-code / frontend-declared-owner):

  • No code branch enumerates action-types (they are data; quorum derives from risk_level).
  • No handler hardcodes an owner (owner resolves from governance_object_ownership via the resolution view).
  • No frontend declares an owner/approval (Registries-Pivot reads the roof; doc 18 confirms no owner_gov_code columns).
  • The handler_ref='unimplemented' fail-closed pattern means even a registered action cannot execute via a private path.

One governance_registry, one Đ32 spine, one Đ31/Đ45 detection/event substrate, one ownership store. No LOCAL_GOVERNANCE_ISLAND.


3. Implementation-readiness verdict

Status of the designs: SB-1 and SB-2 are DESIGN-COMPLETE for implementation review (T3/T4 PASS). They are NOT implementation-ready to commit — every commit path is gated.

3.1 Readiness gate table

Step What it is Gate (all must hold) Status
SB-1 design (T3) 4 action-types fully specified concept GO DONE (this package, doc 16)
SB-2 design (T4) additive ownership substrate specified concept GO DONE (this package, doc 17)
C-1 ruling new table vs widen CHECK COUNCIL ratifies (default: new table) OPEN
C-2 ruling 4-action bundle + exception-store correction COUNCIL ratifies OPEN
SB-1 register (Phase A) INSERT 4 rows (fail-closed) C-2 + H-1 enact path + rehearsal log NO-GO
SB-2 create table CREATE table+ref+views C-1 + H-1 + rehearsal log NO-GO
First live owner write handler writes a row SB-1 Phase-B handler (real handler_ref) + SB-2 table + sovereign sign-off (H-2/SB-6) + action≠'add' discipline + auto-approve hardening NO-GO
Exception register materialise M-DEF-6 store C-2 (store decision, doc 16 §6) NO-GO
IU owner-binding bind IU owners into SB-2 OP-B (C-3) + C-4 NO-GO
Scanner apply (T6) scanner proposes via SB-1 T3+T4 accepted + SB-8 coverage rows + concept GO design-allowed; apply NO-GO

No gate may be satisfied by self-approval (doc 03 §3.5). os_proposal_approvals=0COMMIT_FORBIDDEN until the sovereign sign-off path runs.

3.2 Verdict

  • SB-1 design verdict: COMPLETE. Pattern = apr_action_types rows (PG-first, no-hardcode); fail-closed via handler_ref='unimplemented'; quorum data-driven via risk_level; auto-approve bypass identified + mitigated; exception-store mismatch corrected. Ready for council/implementation review.
  • SB-2 design verdict: COMPLETE. Pattern = additive governance_object_ownership + scope ref + resolution view (hybrid); no migration risk to the 8 live edges (proven); container-grain inheritance Δtotal=0 at 10⁸; owner-per-scope uniqueness + conflict/gap detection; axis support decoupled from SB-3. Ready for council/implementation review.
  • Integration verdict: COHERENT & NON-ISLAND. All twelve surfaces integrate by reuse; the dual-channel island proof holds.
  • Implementation verdict: NO-GO to commit. Blocked on C-1, C-2 (council), H-1 (enact path), H-2/SB-6 (sovereign sign-off), and — for the owner-write path — SB-1↔SB-2 mutual readiness + the auto-approve hardening. Design may proceed to the next dependent tracks (T6 scanner needs T3+T4 accepted; T5 needs OP-B; T10 needs OP-B+SB-3).

3.3 Remaining blockers (none silently closed)

OPEN: SB-1, SB-2 (designs done, substrate not built); SB-3 (untouched, independent of this work); C-1, C-2, C-4, C-5, C-6, OP-B/C-3 (council); H-1, H-2 (human); L-1, L-2, L-3 (law-drift); SB-4 (event/issue registration — T7), SB-5/SB-6 (enactment/commit — human), SB-7 (audit activation — T6/T11), SB-8 (coverage rows — T6), SB-9 (law-catalog drift — T1). This macro advanced only SB-1 and SB-2 to design-complete; it closed none.


4. Future-axis & scanner forward-compatibility (explicit)

  • A future axis (4th, 5th, …) needs: an Axis-Registry row (M-DEF-9) + an assign_axis_owner APR + a governance_object_ownership row (object_type='axis'). No DDL in SB-1/SB-2 substrate. SB-3 (axis-value storage) is a separate concern and not a prerequisite for axis ownership.
  • The future scanner consumes SB-2's views + raises SB-1 APRs; SB-1/SB-2 are designed to be its propose/apply substrate (the governance.approval DOT coverage already exists). This forward-compatibility is the reason T6 lists T3+T4 as prerequisites.
Back to Knowledge Hub knowledge/dev/reports/architecture/one-roof-governance-technical-addendum-and-implementation-index-2026-06-01/20-sb1-sb2-integration-and-implementation-readiness.md