KB-B087
FIX7 N-Node Gap & Contradiction Report (2026-06-11)
7 min read Revision 1
tool-kiem-thufix7n-nodecontradictiongap2026-06-11
FIX7 N-Node Authority Model — Gap & Contradiction Report
- Date: 2026-06-11 · Host: T1 · Codex consulted: NO · Production mutation: NO
- Authority: provisional-non-authority, clarification only. Sources cited as S1..S17 from
fix7-n-node-source-map-report-2026-06-11.md.
1. Headline
The N-node engineering edges are consistent and acyclic across every surface (has_cycle(EDGES)=False, verified in S1/S4/S8). What is inconsistent is the labelling: the same DAG node numbers carry different values on the blueprint surface (S2/S14) vs the authority-seal surface (S3/S5), and N9 is named on one surface and unnamed/absent on the others. No binding is missing or wrong — the seal still binds membership, canonicalizer hash, corpus, etc. — but the numbering is not a single coherent SSOT, which is precisely why directing the seal/N6 lane is currently unsafe.
2. Material contradiction MC-1 — N1 / N2 value reassignment
| DAG node | Blueprint S2/S14 (prose) | Canonicalizer code S1 (EDGES + comments) |
Authority encoder S3/S5 (rosters) |
|---|---|---|---|
| N1 | normalized_active_content_sha256[d] (per-doc) |
per-doc normalized_active_content_sha256 (comment) |
membership_sha256 ("N1 doc-set anchor"); per-doc content bound transitively via N6 |
| N2 | active_corpus_membership_sha256 (doc_id set) |
un-labelled leaf (no comment) | canonicalizer_sha256 (rev3 49c386a9…) |
| N6 | active_corpus_sha256 |
active_corpus_sha256 (comment) |
active_corpus_sha256 |
- Severity: MATERIAL but NON-EXPLOITABLE. The authority N7 roster (S3/S5) binds both
membership_sha256(field 3) andcanonicalizer_sha256(field 4), so nothing the blueprint required is dropped. The defect is that the N-number → value map is not stable between surfaces: a reader who trusts the blueprint thinks "N2 = membership"; a reader who trusts the encoder thinks "N2 = canonicalizer hash, N1 = membership." - Resolution authority: S1's precedence rule ("this artifact wins; other descriptions are NON_AUTHORITY_EXPLANATION") makes the canonicalizer authoritative — but the canonicalizer code itself does not number N2, so it cannot, on its own, adjudicate "N2 = canonicalizer hash vs membership." The authority encoder (S3) made that call unilaterally and is provisional-non-authority. → The numbering needs an explicit ratification, not just precedence.
- Owner of the fix: documentation reconciliation by T1 (propose) + Codex/owner (ratify the canonical numbering at, or before, the seal). Does not require code change — only a single agreed N-number→value table.
3. Material contradiction MC-2 — N9 identity
| Surface | N9 |
|---|---|
| Blueprint S2/S14 | codex_checkpoint_content_sha256_excluding_seal = NON_AUTHORITY_DIAGNOSTIC, a sink consumed by nothing |
| Canonicalizer code S1 | "N9_DIAG":[] — no semantic name, not in LOAD_BEARING, consumed by nothing |
| Authority encoder S3 | absent — the authority DAG is N1..N8 + P7; N9 is not carried |
- Severity: LOW. All three agree N9 is diagnostic / non-load-bearing / consumed by nothing. They disagree only on whether it has a name (
codex_checkpoint_content_sha256_excluding_seal) and whether it is carried at all in the authority layer. This is a documentation gap, not a contract defect: dropping a never-consumed diagnostic sink from the authority DAG is safe. - Resolution: record in the SSOT addendum that N9 = a non-load-bearing diagnostic sink (checkpoint-content hash excluding the seal), intentionally NOT carried into the authority seal. No actor blocked.
4. Contradiction CC-1 — historical N7↔N8 cycle (RESOLVED)
S11 (Codex approval-lane) flagged that early packet prose (n7…envelope rev1 A4) made N7 bind N8 while the DAG makes N8 bind N7 — a 2-cycle. S8 confirms this was removed: rev2 §6.1 deletes A4; CYCLE_FORBIDDEN rejects feeding detached_seal_sha256/authority_seal_pin_sha256 into N7. Status: CLOSED, no residual. Recorded for lineage only.
5. Gap classification
| Gap ID | Description | Class | Actor | Blocks final seal? |
|---|---|---|---|---|
| G-DOC-1 | No single canonical N-number→value table; blueprint vs encoder disagree on N1/N2 (MC-1) | documentation gap | T1 propose + Codex/owner ratify | NO directly, but blocks safe direction of the seal lane (the reason for this macro) |
| G-DOC-2 | N9 named on blueprint, unnamed/absent elsewhere (MC-2) | documentation gap | T1 (record in addendum) | NO |
| G-DOC-3 | Canonicalizer code does not comment N2's value, leaving N2 ambiguous at the SSOT itself | documentation gap (in the SSOT) | T1 propose + Codex ratify (SSOT is load-bearing → change needs seal-level care) | NO directly; feeds G-DOC-1 |
| G-IMPL-1 | FIX7_GUARD_SET_V1 tag is reserved but --produce sets N5 = the per-doc content digest of doc 06 (cdig), not a distinct FIX7_GUARD_SET_V1 digest |
implementation/documentation mismatch (cosmetic; value is well-defined) | T1 (note in addendum) | NO |
| G-AUTH-1 | SEAL_REAL_N6_NOT_AVAILABLE — no real non-rehearsal N1..N6 chain produced/classed/sealed in this lane |
authority/provenance gap | owner/operator + Codex (ratify); T1 can materialize the candidate | YES |
| G-AUTH-2 | A1/A2/A3/A5 approval-event inputs + N8 signer/report + P7 report/checkpoint ids not supplied | authority gap | Codex + owner | YES |
| G-OWNER-1 | OWN-1 standing "do not approve construction blueprint" | owner gap | owner | YES |
| G-CONTRACT-0 | (none) — the value-grammar/report-set/provenance contract defects Codex raised (FINAL-AS-*) are CLOSED at engineering level (S9/S13) |
— | — | — |
6. Severity summary
- No contract defect remains in the encoder (value grammar, report-set, provenance, cycle guard all closed per S9/S13 and the Codex reject S10 that drove them).
- The only seal-blocking gaps are authority/provenance/owner (G-AUTH-1/2, G-OWNER-1) — exactly the standing blockers in the ledger S13.
- The documentation contradictions (G-DOC-1/2/3) do not block the seal math but block the team's ability to direct it confidently — which is the stated reason for pausing the N6 macro. They are cheap to fix (one ratified table) and require no code or production change.
7. Recommended resolution order (no work performed here)
- Ratify a single canonical N-number→value table (the addendum proposes one as a PROPOSED CORRECTION, clearly marked) — closes G-DOC-1/2/3.
- Then run the real-N6-provenance macro (materialize candidate N1..N6 over the 10 real docs + first-hand evidence + provenance class) — addresses G-AUTH-1's engineering half.
- Codex/owner authority event ratifies the candidate + supplies A1/A2/A3/A5 + authors N7→N8→P7 — closes G-AUTH-1/2; owner disposes OWN-1.