KB-760C

11 — Technical Addendum SCAFFOLD: Registries-Pivot Integration (2026-06-01)

4 min read Revision 1
one-roof-governancescaffoldregistries-pivot-integrationcount-gt-1-dual-sensegrouping-axisorphan-island-channelpin-class-0track-t9design-only2026-06-01

11 — Technical Addendum SCAFFOLD: Registries-Pivot Integration

SCAFFOLD only. No UI/API/route/view change. Frames future T9.

Purpose

Frame the future design that binds the live Registries-Pivot surface to the governance concepts — without re-shipping the surface and without letting the surface become a second governance roof.

Controlling inputs

  • Concept canon doc 01 (count>1 rule M-DEF-10 dual-sense; coverage; governed-exception) and doc 02 (open-axis: grouping is a governed axis).
  • Patched Registries-Pivot docs 00 (master, count>1=candidacy not mandate), 04 (drill, non-hiding inherit), 06 (orphan-vs-anarchic, 12 gap types, island dual-channel), 07 (grouping=governed axis, Axis Registry, SB-3 caveat), 08 (pin scope user→Class-0, global→governed), 12 (4-phase gate, §0-GOV, owner-per-scope). These are CURRENT_CONTROLLING surface docs.
  • This package doc 04 (T9).

Current blocker status

Concept-aligned; build-gated. The surface is live; its governance binding is not built. The integration design depends on the apply path (SB-1/SB-2) for owner edges and on T6/T7 for coverage/events. The critique prompt specifically tests whether the count>1 dual-sense leaks governance obligations onto the UI drill sense — guard this.

Exact scope of the future design (T9)

  • Bind the count>1 dual-sense correctly: the UI-drill sense (a parent with >1 children gets a child layer) must not import governance obligations; the governance sense (count>1 = axis candidacy, not mandate) stays separate. Prove no leak.
  • Bind grouping as a governed axis (M-DEF-8/9) to the Axis Registry — carry the SB-3 caveat (axis store not yet generic at substrate).
  • Bind the orphan/island dual-channel to the coverage scanner (T6) and event taxonomy (T7).
  • Bind pin scope: user-scope pin → Class-0 (governed at export/share per C-6); global/role/team pin → governed.
  • Reuse the shipped views / Nitro endpoints / route; do not re-ship or mutate them.

Dependencies

  • Reads patched Registries-Pivot docs + concept canon. Consumes T6 (coverage), T7 (events), SB-2 (owner edge), T8 (render). Carries SB-3 caveat.

Known constraints

  • No second governance roof: the Registries-Pivot surface references the canon, never restates/forks governance.
  • count>1 dual-sense must not leak (the explicit red-team / critique concern).
  • No-hardcode (the surface had real prior violations — see Registries-Pivot ship reports).

Forbidden implementation shortcuts

  • ❌ UI/API/route/view change; ❌ re-shipping the surface.
  • ❌ Letting the drill UI sense carry governance obligations.
  • ❌ A surface-local governance store/island.

Acceptance criteria for the future detailed design

Integration designed with count>1 dual-sense proven non-leaking; grouping-axis bound to Axis Registry with SB-3 caveat; orphan/island channel bound to T6/T7; pin scope bound to Class-0/governed; reuse of live surface; no surface change; no-island attestation.

Where future detailed docs must be added

This package (e.g. 11a-registries-pivot-integration-design.md). Pointer added here.

What old docs must NOT be used as controlling input

  • Un-patched Registries-Pivot docs (01/02/03/05/09/10/11/13) as current governance truth (TECHNICAL_REFERENCE_ONLY).
  • Registries-Pivot ship/macro reports as a governance-binding spec (reference for live surface only).
Back to Knowledge Hub knowledge/dev/reports/architecture/one-roof-governance-technical-addendum-and-implementation-index-2026-06-01/11-technical-addendum-registries-pivot-integration-scaffold.md