DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path change-requests/cr-2026-164-provenance-walk-v0_3.md

DUNIN7-M4 — OPERATOR LAYER CHANGE REQUEST

CR-2026-164 — B-9: the provenance walk — v0.3

Version. v0.3 Date. 2026-08-03 Supersedes. v0.2 and v0.1, both drafted and never filed — each halted at pre-flight. The record holds neither. Changes from v0.2. The self-describing claim is deleted rather than corrected a third time. v0.1 claimed the kickoff "restates nothing the body carries" and restated nine things. v0.2 corrected the rule to drift and still restated four — including one sentence the correction pass had edited, removing half of it and leaving the defect in the half it kept. The recurring failure was the claim, not the block: a rule re-asserted inside every change request is a rule broken inside every change request, and no session behaves differently because a paragraph says the block is disciplined. The rule moves to the standing note, where it governs all change requests and is swept once. The four surviving restatements are fixed, and the entry-point question the executing session raised is settled there rather than left ambiguous: naming what must be read before the CR — the grounding document and the charter — is the entry point, not a restatement.

Changes from v0.1, superseded but recorded. §7 only; no decision, scope or gate changed. The kickoff claimed it "restates nothing the body carries" and then restated nine things, two of them verbatim. The block failed its own stated contract — caught by testing the claim rather than reading it. The rule was wrong as written: no workable kickoff restates nothing, because some fences belong in both places. The rule is drift — the block now restates no count, path, identifier, scope boundary, step content or argument, and carries standing fences explicitly labelled as such. Author. Claude.ai (drafting session). Approving: Marvin Percival. Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. No session executes a change request it drafted (§1). Target. /Users/dunin7/loomworks at main f477c87, tag shaping-room-v0_1. One repository. No engine change. Baseline. Not green. 652 passed, 0 failed, exit code 1, twelve unhandled fetchPlatformLevel rejections. The criterion is no new failure and no new unhandled rejection, against sets recorded at Step 0. Exit 0 is not reachable and is not the criterion. Build-list item. B-9 — change request E. CR number. CR-2026-164. Highest confirmed is CR-2026-163. [EXECUTING SESSION: verify; advance if taken.] Grounding. inspection-briefs/loomworks-b9-step-0-findings-v0_1every anchor below comes from it. Status. Pre-execution.


1. What this builds, and what it does not

The render-level provenance walk. From a finished document, walk backward: this document was built from this Shape, from this Manifestation at this version, from these assertions, by these people.

What it is not. B-9's build-list wording is click any statement in a finished report and walk back to the person who said it. That is not buildable and this CR does not attempt it — see D-1.

Why it is worth building anyway. Every hop is the same hop either way. Per-statement linkage, if it is ever built, changes where the walk is entered, not the walk. Nothing here is wasted work.


2. Construction decisions

D-1 — the render-level walk is built; per-statement linkage becomes an investigation, not a change request. (Queue entry Q-15, put to the Operator with a lean.)

Per-statement linkage does not exist and is not derivable. A render's stored content is one opaque string — every in-tree specialist writes {"text": <model output>}. Nothing inside references anything: no marker, no anchor, no index, and RenderEvent has no field for one. Neither model is ever shown an identifier — the render prompt carries the Shape's prose alone, and the shaping prompt lists assertions as - (grammar/force) content. Neither specialist could cite a source if instructed to. The Shape does name its assertions, version-pinned, but the render's only tie to the Shape is one whole-Shape reference.

So B-9 as promised is a pipeline and substrate change.

> The lean, and the hazard that makes it a lean rather than a plan. The obvious route — show the specialist the identifiers and ask it to cite — makes the citations model output. A model that fabricates a citation produces a walk that leads confidently to the wrong person. That is strictly worse than no walk, and it is face 2 at statement level, inside the feature built to demonstrate that the record can be trusted. > > A per-statement walk therefore needs a mechanism that does not depend on the model being honest — structural emission, post-hoc matching with a confidence floor, or a rendering path that assembles from cited fragments rather than generating prose. Each is a design problem, not an implementation task. It wants an investigation arc, and it touches the seed's render-types. > > Recorded so the alternative is not lost: the Operator may decide the per-statement walk is the point of B-9 and the render-level walk is a consolation. This CR is buildable either way and blocks neither.

D-2 — hop 5 is two reads and two sentences: who committed it, and who said it first.

The walk's terminus is the committer, not the contributor. Commit re-attributes on the new version, and the engine's own comment calls this a known imprecision. B-9 asks for the originator, which is version 1, reachable via /history.

The walk shows both, labelled distinctly. Said by X and committed by Y are different facts, and a walk that shows only the second while promising the first is wrong in the most damaging available way — it names a real person who did not say the thing.

[EXECUTING SESSION: where the committer and the originator are the same actor, establish at Step 0 whether the walk shows one line or two. Both are acceptable; showing two identical lines is noise, and showing one without establishing they match is the defect.]

D-3 — the legacy sentinel is never rendered as a person.

LEGACY_UNRESOLVED_ACTOR_ID reads as an ordinary contributor. It was introduced by CR-2026-161 to say a human acted on the bearer-token path and the engine does not know which — deliberately, in place of a fabrication.

A walk that renders it as a contributor names a person where the engine recorded an unknown. That is the exact defect B-25 existed to remove, reintroduced by the feature built to display B-25's results.

The walk special-cases it and says what it means: the record does not identify who did this. A test fails if the sentinel ever renders as a named actor.

D-4 — the four actor kinds render distinctly.

contributor, person, companion, agent carry different authority — that is what CR-2026-161 established, and collapsing two of them would have made the Companion's own draft committable as a human act.

**A walk that renders all four as the person who said this repeats exactly the mistake B-25 avoided.** Each kind reads as what it is.

On companion specifically: W-6 is not closed by B-25. What B-25 makes usable is that kind="companion" carries the person's own identifier — so a walk never dead-ends there, and can say the Companion, acting for X.

D-5 — the surface stops discarding what it already receives.

Three of the five hops are already served over the wire and thrown away at the adapter boundary. compose.ts reads the version-pinned assertion references and collapses them to a count.

The largest part of this build is not fetching; it is keeping. The adapters preserve what they are given.

D-6 — ReadState needs nothing added.

A walk is a sequence of reads, each of which can fail or return nothing. Each hop is a read, and the contract already models a read. (This is B-6's answer a second time: the contract answers did the read land; the item answers everything else.)


3. In scope

3.1 The adapters — preserve the version-pinned references currently collapsed, per D-5. [EXECUTING SESSION: name every adapter that discards data it receives on the walk's path, and report them before editing. The findings establish compose.ts; establish whether it is alone.]

3.2 The walk itself — from a render, through Shape, Manifestation-at-version, assertions-at-version, to actors. Each hop is a ReadState, and a failed hop says the hop failed, never that the chain is empty.

3.3 The actor presentation — per D-2, D-3 and D-4.

3.4 The affordance — where a walk is opened from. [EXECUTING SESSION: the findings note two forward routes already exist — a confirmed-shape filter and a dependents route. Establish at Step 0 whether the walk should also run forward, and report it. This CR builds backward only; forward is recorded if it is cheap.]


4. Out of scope


5. Order of operations

Per-step commits, npm test at each against the Step 0 baseline sets. Check the current branch before the first commit.

Step 0 — pre-flight and three determinations. Verify HEAD, tree, CR number. Record the baseline failure set, the unhandled-rejection set, and the exit code. Re-confirm the findings' anchors.

Then settle and report, before any code changes:

  1. Every adapter on the walk's path that discards data it receives. Per §3.1.
  2. Whether the walk shows one actor line or two when committer and originator match. Per D-2.
  3. Whether the forward walk is cheap enough to include. Per §3.4. A "no" is a fine answer.

Step 1 — the adapters, §3.1.

Step 2 — the walk, §3.2.

Step 3 — the actor presentation, §3.3.

Step 4 — the affordance, §3.4.

Step 5 — tests. Each hop's states; a test that fails if the sentinel renders as a named actor; a test that each actor kind renders distinctly; a test that a failed hop says so rather than reading as an empty chain. Assert specific conditions, never a bare Exception.

CHECKPOINT A — report, then proceed. Baseline comparisons; the tests; a live pass showing a completed walk from a real render to real actors, a walk touching the sentinel, and a walk with one hop deliberately failed. No Operator confirmation. Halt and queue on: any new failure or rejection; any determination coming back ambiguous; any charter §6 anomaly.

Step 6 — implementation notes, carrying all three determinations.

CHECKPOINT B — merge and tag. --no-ff to main, tag provenance-walk-v0_1, push. Authorized under R-2 including the push. Deployment is never autonomous (F-1).


6. Acceptance gate

  1. No new failure and no new unhandled rejection against the Step 0 baseline sets. The vocabulary wall passes.
  2. A walk runs from a render to its actors, every hop version-pinned.
  3. The originator and the committer are distinguishable, and the walk never presents a committer as the person who said it.
  4. The legacy sentinel never renders as a named actor, and a test enforces it.
  5. Each of the four actor kinds renders as what it is; none is presented as another.
  6. A failed hop says the hop failed and never that the chain is empty.
  7. No adapter on the walk's path discards a reference it receives.
  8. No engine change. No file outside /Users/dunin7/loomworks is edited.
  9. Implementation notes carry all three determinations.
  10. The status brief is appended, per charter §7.

7. Claude Code kickoff

The drafting rule this block follows lives at standing-notes/loomworks-standing-note-executable-document-versions, not here. v0.1 and v0.2 each carried a paragraph asserting what the block does and each broke it — the claim was the recurring defect, not the block. A rule re-asserted in every change request is a rule broken in every change request.


CR-2026-164 — B-9, the provenance walk. Execution session.

CR: loomworks-record/change-requests/cr-2026-164-provenance-walk-v0_3.md
Confirm it exists, and that it is the highest version present — numeric sort.

Grounding, read before the CR:
  inspection-briefs/loomworks-b9-step-0-findings-v0_1.md

Charter dunin7-standing-authorization-charter-v0_1 governs.
Read the CR in full. It is the authority on what changes, where, and why.
Where this block and the CR appear to differ, the CR is right and you halt
rather than choosing.

  Section 2 — the construction decisions and their reasoning
  Section 3 — what changes
  Section 4 — what is out of scope
  Section 5 — the step sequence and both checkpoints
  Section 6 — the acceptance gate

The CR's header names the target, the baseline and the scope. If anything
outside that scope appears to need changing, halt.

Section 5's Step 0 comes before any code changes. Follow it there.

Section 2's decisions about how actors are presented are the boundary this
feature lives or dies on. Read the reasoning there; it is not summarised here.

Do not resolve an ambiguous determination by choosing.

Standing fences, true regardless of this CR:
  playground_dev is the live production database and is not touched.
  Commit to a branch; check the current branch before the first commit.
  Deployment is never yours.
  Append the outcome to current-status/dunin7-status-brief at close.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-164 — B-9: the provenance walk — v0.3 — 2026-08-03 The walk between records, built. The walk inside a document, put to the Operator.