DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path change-requests/cr-2026-169-answer-sources-v0_1.md

DUNIN7-M4 — CHANGE REQUEST

CR-2026-169 — B-11: the unstable answer — v0.1

Version. v0.1 Date. 2026-08-05 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-engine at main afe8507; /Users/dunin7/loomworks at main c12a1ad. Two repositories, separate branches, separate merges and tags. Baselines. Both repositories pass their gated commands. The criterion is no new failure, against sets recorded at Step 0. Build-list item. B-11. B-12 does not merge into it — see D-6. CR number. CR-2026-169. Highest confirmed is CR-2026-168. [EXECUTING SESSION: verify; advance if taken.] Grounding. inspection-briefs/loomworks-b11-step-0-findings-v0_1every anchor below was read there. Status. Pre-execution.


1. What this fixes

Asked the same question three times, the system answered correctly, disowned its own correct answer, then answered correctly with a source. The answer was never wrong. One of the three states was a false statement about the system's own reliability — which is worse than a wrong answer, because a wrong answer can be checked and this teaches a reader to distrust the right ones.

The read found four mechanisms, three of them nothing to do with retrieval:

The system already does the honest thing elsewhere. Several intents bypass the model entirely and compose their replies server-side; one carries the comment that its reply cannot name a memory not in the set. This path is not one of them.


2. Construction decisions

D-1 — the responder call is pinned to temperature=0.

One line, and it makes the engine's language-model seams consistent for the first time. The classifier was pinned deliberately, with a comment naming the incident that prompted it. The seam that produces the text a person actually reads was left at the API default.

This is the cheapest of the four fixes and the most likely to be the main cause.

D-2 — carried conversation turns stay. The feedback loop is named instead.

Reading the last several turns is correct behaviour, not a defect — it is what makes a conversation one.

But it has a consequence worth stating: a false confession, once emitted, is in the model's view on every subsequent turn in that conversation. The instability can therefore sustain itself. D-1 addresses the origin; nothing needs to change here, and a session tempted to "fix" the history-carrying should not.

[EXECUTING SESSION: confirm the turn history is scoped per person and engagement, so one conversation's confession cannot reach another's. The read says it is; verify.]

D-3 — the response carries the sources the system actually retrieved, as a field.

This is the change that matters, and it is the same move the provenance walk made.

Today the model is handed real retrieved material and instructed to reference it by display number. A reference it produces is usually grounded and nothing enforces that — and the response schema has no channel through which the system could attach a source even if it wanted to.

Add one. The response carries the identifiers of exactly the records that were retrieved and put in front of the model — not what the model says it used, and not a claim about which ones it drew on. A list of what it was given.

> What that buys, precisely. It does not make the prose true. It makes the prose checkable, which is the only thing available — and it is what turns a confession from an unanswerable claim into something a reader can evaluate against what the system actually had.

[EXECUTING SESSION: the faithful, server-composed intents already exist and their pattern is the reference. Do not build a second mechanism where one is already right; establish whether their approach can be reused before writing a new one.]

D-4 — the answer states what it was answered from.

The retrieval is the fifty most recent contributions, ordered by recency, with no relation to what was asked. The path's own documentation says so, deliberately, as a current-scope limit.

A reader has no way to know that, and an answer that omits the relevant material because it fell outside fifty is indistinguishable from one where nothing relevant exists. That is the governing rule: a surface states only what it has read back, and this one has read back a bounded window it does not mention.

The answer says what it looked at. Wording is the change request's to settle at build time; the requirement is that the boundary is visible, not that a particular sentence is used.

D-5 — the uncertainty instruction stays, untouched.

The system can answer beyond what it retrieved — nothing constrains the output to the material handed over. So a confession is sometimes true, and removing the instruction that produces it would trade an occasional false alarm for occasional silent fabrication.

That is the wrong trade and this change request does not make it. D-3 is the answer: make confessions checkable rather than rarer.

D-6 — B-12 does not merge into this. The retrieval layer is separate work.

The Step 0 read established that no real retrieval exists — a recency-ordered fetch with a fixed cap, no query term, no ranking. By that read's framing, B-11 and B-12 are the same job.

They are not, and the reason is that three of the four mechanisms have nothing to do with retrieval. A pinned temperature, a carried history, a varying model — none touches what is fetched. And D-3's channel is orthogonal to what fills it: the system attaches what was retrieved, whatever retrieved it. B-12 changes what goes into that set; it does not change the channel.

What B-12 would change here is one sentence — D-4's statement of scope, which becomes the notes matching your question rather than your fifty most recent. That is not a rebuild.

Recorded, because the read reasoned the other way and its reasoning was sound on its own terms. The Operator may still merge them; this change request is buildable and useful either way, and nothing in it is wasted if they are.

D-7 — whether the responder model is pinned per conversation is a Step 0 determination.

The model can differ between calls by credit tier. So the same question three times may not have reached the same model, and D-1's pinning does not address it.

[EXECUTING SESSION: establish whether the model can change mid-conversation for one person in one engagement, and what pinning it would cost. Report before deciding.] Pinning has a real cost — it could hold a conversation on a tier the Operator has stopped paying for. Do not pin it without reporting the cost; if the answer is unclear, halt.


3. In scope

3.1 Engine — the responder temperature. D-1.

3.2 Engine — the sources field, populated from what was retrieved. D-3.

3.3 Engine — the scope statement. D-4.

3.4 Surface — rendering the sources, so the field is visible rather than merely present. A citation nobody sees is not a citation.

3.5 Engine — the model-pinning determination's outcome, per D-7, if it settles cleanly.


4. Out of scope


5. Order of operations

Per-step commits. Two repositories, two branches. Never one commit spanning both. Check the current branch before the first commit in each.

Step 0 — pre-flight, baselines, and two determinations. Verify both HEADs and trees, the CR number. Record every gated command's baseline. Re-confirm the findings' anchors.

Then settle and report:

  1. Whether the server-composed intents' pattern can be reused for D-3, or a new mechanism is needed.
  2. D-7's model-pinning question, with its cost.

Step 1 — engine, D-1. The pin. Verify by two runs of any test exercising the responder, or by reading the call — a pinned temperature is not observable from output alone.

Step 2 — engine, D-3. The sources field.

Step 3 — engine, D-4. The scope statement.

Step 4 — surface, §3.4. Rendering.

Step 5 — tests. A test that fails if the sources field ever contains an identifier that was not retrieved — the field's entire value is that it cannot. Assert specific conditions, never a bare exception.

CHECKPOINT A — report, then proceed. Baselines; both determinations; the tests. And a live pass showing an answer with its sources attached and its scope stated. [EXECUTING SESSION: if the live pass needs model calls, report the count and cost and proceed — this one is authorized, unlike the Step 0 read's. Keep it to the minimum that demonstrates the behaviour.] No Operator confirmation. Halt and queue on: either determination coming back unclear; any new failure; any charter §6 anomaly.

Step 6 — implementation notes in each repository.

CHECKPOINT B — merge and tag, separately per repository. --no-ff in each; tag the engine answer-sources-v0_1 and the surface answer-sources-surface-v0_1. Push both. Authorized under R-2 including the pushes. Both repositories now gate on push — report each first run's outcome.

Deployment is never autonomous (F-1).


6. Acceptance gate

  1. No new failure in either repository against the Step 0 baselines. Both gates pass.
  2. The responder call pins its temperature, matching every other language-model seam in the engine.
  3. The response carries the identifiers of exactly what was retrieved — not what the model claims it used.
  4. A test fails if that field can contain anything not retrieved.
  5. The surface renders the sources.
  6. The answer states the boundary of what it looked at.
  7. The uncertainty instruction is unchanged, and the carried conversation history is unchanged.
  8. No retrieval mechanism is built or changed.
  9. D-7's determination is recorded with its cost, whether or not it was acted on.
  10. Implementation notes in both repositories carry both determinations and the live pass.
  11. The status brief is appended, per charter §7.

7. Claude Code kickoff


CR-2026-169 — B-11, the unstable answer. Execution session.

CR: loomworks-record/change-requests/cr-2026-169-answer-sources-v0_1.md
Confirm it exists, and that it is the highest version present — numeric sort.

Grounding, read before the CR:
  inspection-briefs/loomworks-b11-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; this
block repeats none of it. 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

TWO REPOSITORIES — the CR's header names both targets. Separate branches,
separate commit series, separate merges and tags.

Section 2's D-5 and D-2 forbid changes that will look like improvements: do not
weaken the uncertainty instruction, and do not touch the carried conversation
history. Both are correct as they stand.

Model calls are authorized for the live pass at Checkpoint A only, at the
minimum that demonstrates the behaviour. Report the count.

Standing fences, true regardless of this CR:
  playground_dev and playground_test are live databases and are not touched.
  If a database is needed, use a throwaway, dropped after.
  Commit to a branch; check the current branch before the first commit in each.
  Deployment is never yours.
  Append the outcome to current-status/dunin7-status-brief at close.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-169 — B-11: the unstable answer — v0.1 — 2026-08-05 It cannot make the prose true. It makes the prose checkable, which is the thing that was missing.