KB-16F4

FIX7 N-Node Authority Model — Design Addendum (2026-06-11)

15 min read Revision 1
tool-kiem-thufix7n-nodeauthority-modeldesign-addendumssot-input2026-06-11

FIX7 N-Node Authority Model — Design Addendum

  • Date: 2026-06-11 · Host: T1 · Codex consulted: NO · Production mutation: NO
  • Macro: FIX7_N_NODE_AUTHORITY_MODEL_CLARIFICATION_DESIGN_ADDENDUM_MACRO_2026_06_11
  • Authority of THIS doc: provisional-non-authority clarification / SSOT-input. It reverse-documents the existing N-node model from real sources. It seals/approves/invents nothing. Where it proposes a fix, the text is explicitly marked PROPOSED CORRECTION.
  • Companion machine model: fix7-n-node-authority-model-design-addendum-2026-06-11.json.
  • Evidence chain: fix7-n-node-source-map-report-2026-06-11.md (sources S1..S17), fix7-n6-special-analysis-report-2026-06-11.md, fix7-n-node-gap-contradiction-report-2026-06-11.md, fix7-n-node-next-macro-recommendation-2026-06-11.md.

A. Scope of the N-node model (what exists, where)

Where N-node model present? Kind
Original technical design / blueprint doc 00 (S2) + recheck-6 copy (S14) YES — prose node/edge list N1..N9 existing design (but declared NON_AUTHORITY_EXPLANATION by the SSOT)
Canonicalizer SSOT rev3 (S1) YES — executable EDGES={N1..N8,N9_DIAG}, LOAD_BEARING, has_cycle existing design + derived implementation model (the load-bearing one)
Authority-seal encoder spec/code (S3/S4) YES — authority DAG N1..N8 + P7, rosters, value grammar, provenance derived implementation model (provisional-non-authority)
Codex reviews (S10/S11/S12/S15) Uses, adjudicates review-derived
T1 auxiliary tooling/reports (S8/S9/S13) Restates/uses report / implicit model

Verdict: the N-node model is an existing + derived model spread across three surfaces. It is not a single clean SSOT; the numbering drifts (see §C, MC-1/MC-2). P7 is derived-only (authority layer); N9 is diagnostic-only.

B. Node definitions (traced, with status)

Legend — Authority class: engineering (computed from corpus), approval (approval-event input), detached seal (Codex), official pin (P7), rehearsal, diagnostic, unknown. Confidence: confirmed / inferred / undefined / contradictory.

B.1 Engineering + diagnostic nodes (from canonicalizer SSOT rev3, S1 — authoritative)

Node Name (reconciled) Role Domain tag Deps (EDGES) Consumers Data type Authority class Provenance allowed (real seal) Creator T1 compute? Codex author? Usable in real N7? Status
N1 normalized_active_content_sha256[d] (per active doc) per-doc active-content digest FIX7_DOC_NORMALIZED_CONTENT_V1 (+\t+doc_id) [] (leaf; extractor output) N6, (N7 transitively) digest (per-doc) engineering ENGINEERING_VERIFIED_CANDIDATE/OFFICIAL_PIN T1/canonicalizer Yes No Yes (via N6) available (engineering); rehearsal-classed in seal lane
N2 CONTRADICTORY — blueprint: active_corpus_membership_sha256; authority encoder: canonicalizer_sha256 (49c386a9…) a bound leaf in N7/N8 (membership) FIX7_ACTIVE_AUTHORITY_MEMBERSHIP_V1 or (canonicalizer) raw SSOT-bytes sha [] (leaf) N7, N8 digest engineering ENGINEERING_VERIFIED_CANDIDATE/OFFICIAL_PIN T1/canonicalizer Yes No Yes contradictory (label); both underlying values available
N3 marker_fence_registry_sha256 registry of all markers/fences FIX7_MARKER_FENCE_REGISTRY_V1 [] (leaf) N7 digest engineering ENGINEERING_VERIFIED_CANDIDATE/OFFICIAL_PIN T1/canonicalizer Yes No Yes available (engineering); rehearsal-classed in seal lane
N4 superseded_boundary_sha256 superseded fence ranges FIX7_SUPERSEDED_BOUNDARY_V1 [] (leaf) N7 digest engineering ENGINEERING_VERIFIED_CANDIDATE/OFFICIAL_PIN T1/canonicalizer Yes No Yes available (engineering); rehearsal-classed in seal lane
N5 guard_set_sha256 ( = N1 of doc 06 ) guard-set digest reserved FIX7_GUARD_SET_V1; value = cdig of doc 06 (G-IMPL-1) [] (leaf) N7, N8 digest engineering ENGINEERING_VERIFIED_CANDIDATE/OFFICIAL_PIN T1/canonicalizer Yes No Yes available (engineering); rehearsal-classed in seal lane
N6 active_corpus_sha256 aggregate corpus proof (10 docs) FIX7_ACTIVE_AUTHORITY_CORPUS_V1 [N1] N7, N8 corpus proof (aggregate digest) engineering ENGINEERING_VERIFIED_CANDIDATE/OFFICIAL_PIN T1/canonicalizer Yes (d777e87c… on record) No Yes — but gated SEAL_REAL_N6_NOT_AVAILABLE candidate computable; REHEARSAL-classed in lane → standing true blocker
N7 envelope_manifest_sha256 binds engineering digests + approval event FIX7_ACTIVE_AUTHORITY_ENVELOPE_MANIFEST_V1 [N2,N3,N4,N5,N6,N1] N8, P7 manifest (seal) approval (engineering+approval inputs) inputs: corpus→ENGINEERING_VERIFIED_CANDIDATE; approval→AUTHORITY_INPUT Codex (real) / encoder (rehearsal) No (real); rehearsal only Yes — Codex authors n/a (it is N7) rehearsal only; real path gated (needs real N6 + A1/A2/A3/A5)
N8 detached_seal_sha256 Codex detached seal over N7 FIX7_CODEX_DETACHED_SEAL_V1 [N2,N5,N6,N7] P7 seal detached seal CODEX_AUTHORED (+corpus classes) Codex only No Yes — Codex authors n/a CODEX_ONLY; blocked on real N7
N9 blueprint: codex_checkpoint_content_sha256_excluding_seal; code: N9_DIAG (UNDEFINED_NAME in code) diagnostic sink (none) [] (leaf) NONE (sink) diagnostic digest diagnostic (NON_AUTHORITY) n/a (never a seal input) system/Codex (diag) n/a n/a No (excluded by design) diagnostic; not load-bearing; absent from authority DAG

B.2 Authority-layer node (from authority-seal encoder, S3 — derived only)

Node Name Role Domain tag Deps Consumers Data type Authority class Creator Status
P7 authority_seal_pin_sha256 final authoritative pin of canonicalizer rev3 + Packet-V3 tree FIX7_AUTHORITY_SEAL_PIN_V1 [N2,N7,N8] NONE official pin (seal doc w/ byte-exact digest) official pin Codex (encode_real_p7); prose-only pin rejected IMPLEMENTATION_DERIVED; blocked on real N7+N8

B.3 Non-node authority inputs bound by N7 (for completeness)

A1 approval_event_id · A2 approver_identity (owner+Codex) · A3 approval_event_timestamp · A5 owner_blueprint_decision · A6 = N7 itself (the output, not an input). (Old A4 = the removed cyclic field, CC-1.) These are approval-event fields, provenance AUTHORITY_INPUT, supplied by Codex/owner at the seal — not N-nodes.

B.4 The un-numbered digest that causes half the confusion

membership_sha256 (digest over the 10 document_ids, frozen pin f2bda8…fe251, tag FIX7_ACTIVE_AUTHORITY_MEMBERSHIP_V1). Blueprint calls it N2; authority encoder calls it N1 ("doc-set anchor"); canonicalizer code leaves it un-numbered. This is the locus of MC-1.

C. DAG and dependency model

Authoritative engineering edges (S1, copied byte-for-byte into S4):

N1 []                         N2 []      N3 []      N4 []      N5 []
N6 [N1]
N7 [N2,N3,N4,N5,N6,N1]
N8 [N2,N5,N6,N7]
N9_DIAG []                    (diagnostic sink; not load-bearing)

Authority layer adds exactly one node (S3/S4):

P7 [N2,N7,N8]
  • has_cycle(EDGES)False (verified S1/S4/S8). Topological seal order: N1..N6 → N7 → N8 → P7.
  • N7 never binds N8 or P7; N8 never binds P7 (cycle guard SEAL_HASH_GRAPH_CYCLE; CYCLE_FORBIDDEN).
  • N9 exists (as N9_DIAG / blueprint codex_checkpoint_content_sha256_excluding_seal) but is a sink consumed by nothing and is not carried into the authority DAG.
  • Ambiguous edge / contradiction: none in the edges; the contradiction is in what N1/N2 are (MC-1) and what N9 is named (MC-2) — labels, not topology.
  • Edge introduced only by packet language (now removed): the historical N7→N8 cycle (CC-1), deleted in rev2.

D. Provenance model (from S3 §8 / S9 — authoritative for provenance)

Six classes; two real-seal allow-lists.

Class Meaning Assigned by Evidence required Allowed uses Forbidden uses Enters real N7/N8/P7?
ENGINEERING_VERIFIED_CANDIDATE engineering digest reproduced + verified T1 propose; Codex/owner ratify first-hand reproduction (selftest/produce exit 0, hash match) corpus inputs (N1..N6) to real seal as authority/signer input Yes (corpus allow-list)
REHEARSAL fixture/NOT-A-SEAL placeholder T1 (rehearsal driver) labelled NOT-A-SEAL rehearsal/encode_node only any real seal NoSEAL_PROVENANCE_REHEARSAL_BLOCKED
AUTHORITY_INPUT approval-event value (A1/A2/A3/A5) owner + Codex authorized approval event authority/signer inputs to real seal as engineering corpus Yes (authority allow-list)
CODEX_AUTHORED Codex signer/timestamp/parent/report Codex Codex seal act N8/P7 Codex fields as engineering corpus Yes (authority allow-list)
OFFICIAL_PIN promoted, sealed value Codex + owner completed seal corpus or authority (n/a) Yes (both allow-lists)
FORBIDDEN_FOR_REAL_SEAL explicitly barred any none in real seal all real seal NoSEAL_PROVENANCE_FORBIDDEN_CLASS
  • corpus allow-list (N6 etc.): {ENGINEERING_VERIFIED_CANDIDATE, OFFICIAL_PIN}
  • authority/signer allow-list: {AUTHORITY_INPUT, CODEX_AUTHORED, OFFICIAL_PIN}
  • Missing class → SEAL_PROVENANCE_MISSING; unknown → SEAL_PROVENANCE_UNKNOWN_CLASS.
  • Even with valid classes, real path stays blocked by SEAL_REAL_N6_NOT_AVAILABLE until a real in-lane N1..N6 chain exists.

E. N6 special (summary; full analysis in the N6 report)

N6 = active_corpus_sha256, an aggregate corpus proof (input N1). It is not contradicted across sources. Its value is computable today (d777e87c… on record). It is "REHEARSAL" because the authority lane only ran fixtures and never executed real-produce→classify→encode_real_n7 in-lane; the gate SEAL_REAL_N6_NOT_AVAILABLE then stands. Making it real = T1 materializes a real candidate chain + evidence (engineering, doable) then Codex/owner ratify + seal (authority). Packet-V3 engineering PASS does not promote it (anti-laundering, S10/S12). See fix7-n6-special-analysis-report-2026-06-11.md.

F. Plain-language explanation (for a non-technical owner)

  • What N-nodes are: a chain of fingerprints (SHA-256 digests). Each "N" is one fingerprint of one part of the FIX7 blueprint — the words in each document (N1), the document list (membership), the markers (N3), the superseded regions (N4), the test-guard set (N5), and the whole active corpus (N6). N7 bundles all those fingerprints plus the approval-event facts into one "envelope" fingerprint. N8 is Codex's signature over that envelope. P7 is the final stamp that pins which canonicalizer version is official. N9 is a side-note fingerprint used only for diagnostics — nothing depends on it.
  • Why they exist: so that "approving the blueprint" is a precise, reproducible act. Anyone can recompute the fingerprints and check nothing was swapped. It makes approval checkable, not a matter of trust.
  • What is safe right now: the engineering fingerprints (N1–N6) are computed, deterministic, and fail-closed — a missing or altered document makes them refuse to produce a value. None of them claim to be "approved." The contract that would turn them into a real seal is built and tested.
  • What remains blocked: there is no real, sealed N6 chain yet — the system has only run a clearly-labelled rehearsal with fake inputs. To do a real seal we still need: (1) a real corpus fingerprint run captured in this lane, (2) the owner's approval-event facts and the owner's decision on the standing "do not approve" hold, and (3) Codex to author N7→N8→P7. No fingerprint here is an approval.
  • What must happen before a seal: fix one small bookkeeping inconsistency in how the fingerprints are numbered across documents (it does not change the math), produce a real N6 chain, then have Codex + owner perform the authority seal.

G. Machine-readable model

See fix7-n-node-authority-model-design-addendum-2026-06-11.json — nodes, edges, provenance classes, allowed creators/consumers, per-node status, contradictions, and blockers, structured for downstream agents.

H. Gap classification (pointer)

documentation gaps G-DOC-1/2/3 + cosmetic G-IMPL-1; authority/provenance gaps G-AUTH-1 (SEAL_REAL_N6_NOT_AVAILABLE), G-AUTH-2; owner gap G-OWNER-1. No remaining contract defect. Full table: fix7-n-node-gap-contradiction-report-2026-06-11.md.

I. Recommendation (pointer)

Reconcile the N-number→value table first (cheap, no code/prod), then run the real-N6-provenance macro, then the Codex/owner authority seal. Full reasoning + the precise next macro: fix7-n-node-next-macro-recommendation-2026-06-11.md.


PROPOSED CORRECTION (clearly marked, NOT adopted, NOT authority)

A single canonical N-number→value table that the team could ratify (T1 proposes; Codex/owner must ratify before it binds — the SSOT is load-bearing):

N PROPOSED canonical value Rationale
N1 normalized_active_content_sha256[d] (per-doc) matches SSOT code comment + blueprint; keep
N2 canonicalizer_sha256 (rev3) matches the executable authority encoder that N7 actually binds; fixes the un-numbered N2 in code
N3 marker_fence_registry_sha256 unanimous
N4 superseded_boundary_sha256 unanimous
N5 guard_set_sha256 (= N1[doc06]) unanimous (note value-tag G-IMPL-1)
N6 active_corpus_sha256 unanimous
N7 envelope_manifest_sha256 unanimous
N8 detached_seal_sha256 unanimous
N9 codex_checkpoint_content_sha256_excluding_seal (diagnostic sink; not in authority DAG) adopt blueprint name; record as non-load-bearing
(membership) active_corpus_membership_sha256 — keep the name "membership", stop calling it "N1" or "N2" removes MC-1 by giving it a name instead of a contested number
P7 authority_seal_pin_sha256 (authority-layer only) derived; keep

This is the minimum change that makes the model a single coherent SSOT. It changes no edges, no math, no digest — only the labels. It must be ratified, not assumed.

Back to Knowledge Hub knowledge/dev/laws/tool-kiem-thu/designs/fix7-n-node-authority-model-design-addendum-2026-06-11.md