Incomex AI Portal
KB-1FAB

FIX7 N-Node Source-Map Report (2026-06-11)

9 min read Revision 1
tool-kiem-thufix7n-nodeauthority-modelsource-map2026-06-11

FIX7 N-Node Authority Model — Source-Map Report

  • 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, evidence/clarification only. It documents what already exists; it seals/approves/invents nothing.
  • Companion deliverables: designs/fix7-n-node-authority-model-design-addendum-2026-06-11.md (+.json), reports/fix7-n6-special-analysis-report-2026-06-11.md, reports/fix7-n-node-gap-contradiction-report-2026-06-11.md, reports/fix7-n-node-next-macro-recommendation-2026-06-11.md.

0. Method

Every source below was live-read from governed KB this pass (full content unless noted). Each row records whether the source defines the N-node model, merely uses it, implies a dependency, defines provenance, and whether it conflicts with another source. Authority level uses the project ladder: SSOT (one load-bearing artifact) > packet (routing/contract, provisional-non-authority) > report (evidence/explanation) > rehearsal (NOT-A-SEAL fixtures) > proposal/review-derived.

1. Source-discovery table

# Source path Rev / hash Defines N1..N9? Uses N1..N9? Implies dependency? Defines provenance? Conflicts? Authority level
S1 …/t1-fix7-…-blueprint-2026-06-08/canonicalizer-fix7-canon-v1-ssot.md rev3 · 49c386a9…b734d0 · 38756 B YES (engineering EDGES, executable) — EDGES={N1..N6,N7,N8,N9_DIAG} yes yes (EDGES + has_cycle) NO YES vs S2 (N2 identity), vs S3 (N1/N2 labels) SSOT (engineering)
S2 …/blueprint-2026-06-08/00-readme-first.md §"Seal hash dependency graph" (blueprint) YES (prose node/edge list N1..N9) yes yes NO YES vs S1/S3 (N2=membership; N9 named) report / NON_AUTHORITY_EXPLANATION (so declared by S1)
S3 …/fix7-authority-closure-2026-06-10/authority-seal-encoder-spec.md (+.json) rev2 · encoder 13344f92…957144b8 YES (authority DAG N1..N8 + P7, rosters, value grammar) yes yes (P7→N2,N7,N8) YES (6 classes, §8) YES vs S1/S2 (relabels N1=membership, N2=canonicalizer) packet (provisional-non-authority engineering contract)
S4 …/fix7-authority-closure-2026-06-10/authority_seal_encoder.py 13344f92…957144b8 IMPLEMENTATION_DERIVED — EDGES copied from S1 + adds P7; CYCLE_FORBIDDEN; encode_real_n7/n8/p7; provenance gate yes yes YES (executable gate) inherits S3 labels packet / IMPLEMENTATION_DERIVED
S5 …/fix7-authority-closure-2026-06-10/n7-approval-event-input-envelope.md rev3 defines N7 roster (13 fields) yes (N1..N7) yes references S3 labels membership_sha256=N1, canonicalizer_sha256=N2 (same as S3) packet
S6 …/fix7-authority-closure-2026-06-10/n8-detached-seal-request.md rev3 defines N8 roster (11 fields) yes (N2,N5,N6,N7,N8) yes (N8→…N7) references S3 none new packet
S7 …/fix7-authority-closure-2026-06-10/p7-codex-reseal-request.md rev3 defines P7 roster (13 fields) yes (P7,N2,N7,N8) yes (P7→N2,N7,N8) references S3 none new packet
S8 …/tool-kiem-thu/reports/fix7-authority-seal-acyclic-dag-report-2026-06-10.md rev1 restates S1 EDGES + P7; cycle proof yes yes NO confirms S1; cites N9_DIAG report
S9 …/tool-kiem-thu/reports/fix7-final-authority-seal-provenance-validation-report-2026-06-11.md — defines the 6 provenance classes + 2 allow-lists; N6 standing blocker uses N6/N1..N6 implies via gate YES (authoritative description) none report
S10 …/codex-fix7-final-authority-seal-n7-n8-p7-2026-06-10/00-readme-first.md rev1 REVIEW_DERIVED — adjudicates AS-P1..P4; fail-open + N6-REHEARSAL reject uses N6,N7,N8,P7 yes confirms provenance gap none (it caused the patch) review-derived
S11 …/codex-fix7-authority-seal-approval-lane-2026-06-10/00-readme-first.md rev1 REVIEW_DERIVED — cites S1 DAG as decisive authority; flags old N7↔N8 cycle uses N7,N8,P7 yes (N7→…, N8→N7) NO flags packet-language cycle (now removed) review-derived
S12 …/codex-fix7-blueprint-recheck-9-v3-…/00-readme-first.md rev1 REVIEW_DERIVED — engineering PASS, N7/N8/P7 AUTHORITY BLOCKED uses N7,N8,P7 yes NO none review-derived
S13 …/tool-kiem-thu/checkpoints/fix7-recheck9-remaining-authority-blocker-ledger-2026-06-10.md rev7 lists blockers FINAL-AS-N6-PROVENANCE/N7-INPUTS/N8-AUTH/P7-PIN/OWN-1 uses N6,N7,N8,P7 yes references S3/S9 none report (evidence-only)
S14 …/t1-fix7-blueprint-patch-after-codex-recheck-6-…/05-seal-hash-graph-dag.md (recheck-6 lineage) YES (explicit N1..N9 node/edge list — the load-bearing copy of S2) yes yes NO same model as S2 (N2=membership, N9=checkpoint diag) report (load-bearing copy per its own header)
S15 …/codex-fix7-blueprint-recheck-7-byte-exact-seal-2026-06-09/05-seal-hash-graph-dag-recheck.md (recheck-7) REVIEW_DERIVED — SEAL_HASH_GRAPH_DAG_ACCEPTED for "N1–N9 content-hash graph" uses N1..N9 yes NO accepts S2/S14 numbering review-derived
S16 …/fix7-authority-closure-2026-06-10/fix7-implementation-precondition-checklist.md rev2 uses N6/N7/N8/P7 (hard gate) yes yes (real N6 → N7 → N8 → P7) references S3 none packet
S17 …/fix7-authority-closure-2026-06-10/rehearsal/* (n7/n8/p7-rehearsal-artifact.json, rehearsal-summary.json, …) rev2/3 uses N7/N8/P7 — REHEARSAL, NOT-A-SEAL fixture digests 6225f265…/b1f001b6…/3599f663… yes yes corpus classed REHEARSAL none rehearsal (NOT-A-SEAL)

2. Authority-precedence reading (which source wins)

  1. S1 (canonicalizer SSOT rev3) is the single load-bearing engineering authority. It states verbatim: "Every other description of canonicalization … is NON_AUTHORITY_EXPLANATION … If any other description conflicts, this artifact wins." That demotes S2/S14 prose to explanation.
  2. S3/S4 (authority-seal encoder) is a provisional-non-authority engineering contract that copies S1's EDGES byte-for-byte (verified EDGES engineering subset identical: True, S8) and adds exactly one node, P7. It does not change engineering edges, but it re-labels which value each N-number carries (see §3).
  3. S10/S11/S12/S15 (Codex) are review-derived: they adjudicate readiness and treat S1 as decisive, but they do not themselves define the node model.

3. The cross-surface label drift (verbatim extracts)

Three surfaces number the same DAG nodes but bind different values to N1 and N2, and disagree on N9:

  • S2 / S14 (blueprint, prose):
    • N1 normalized_active_content_sha256[d] (per active doc)
    • N2 active_corpus_membership_sha256 (document_id set)
    • N9 codex_checkpoint_content_sha256_excluding_seal = NON_AUTHORITY_DIAGNOSTIC; sink
  • S1 (canonicalizer code): EDGES={"N1":[],…,"N6":["N1"],"N7":[…],"N8":[…],"N9_DIAG":[]}; code comments label N1=per-doc content, N6=active_corpus, but DO NOT label N2; canonicalizer_sha256 and membership are computed but un-numbered in code. N9_DIAG carries no semantic name and is not in LOAD_BEARING.
  • S3 / S5 (authority encoder spec, N7 roster):
    • field 3 membership_sha256 → "N1 doc-set anchor (per-doc N1 via N6)"
    • field 4 canonicalizer_sha256 → "N2 (rev3 49c386a9…)"
    • field 8 active_corpus_sha256 → "N6"
    • N9 absent from the authority DAG entirely.

→ Net: N1 means per-doc content in S1/S2 but membership/doc-set anchor in S3/S5; N2 means membership in S2 but canonicalizer hash in S3/S5 and is un-numbered in S1; N9 is a named checkpoint-diagnostic sink in S2/S14 but an unnamed N9_DIAG leaf in S1 and absent in S3. Full analysis: gap/contradiction report.

4. Confidence ledger

  • S1, S2 (§graph), S3, S5, S6, S7, S8, S9, S10, S11, S12, S13, S16, S17: confirmed (full text read this pass).
  • S14, S15: inferred (read via governed-KB search snippet only — node list and Codex acceptance quoted; not full-text this pass).

5. What is NOT a source for the N-node model

  • The native auto-birth/governance PG system (birth_registry etc.) does not define N-nodes — it was not queried and is out of scope for this clarification.
  • No production/Directus/registry object encodes the N-node model; it lives entirely in the KB design/packet surfaces above.