prefs: name the store a claim was read from; app memory as a second uncheckable cache

Test 3 passed on the hardest axis — offered plausible material to confabulate a
conflict resolution from, the jurist declined and named the kind of gap instead. So
the battery now has a demonstrated FAIL condition it did not trip, which is what
makes the earlier passes mean anything.

Then I got the follow-up wrong twice. The answer cited "the Savall file"; I found it
in none of the six exposed documents and nowhere in the vault, and reported that with
a confabulation framing. The steward supplied the source (Claude.app memory) and
then that he watched it search memory mid-answer. So it WAS reading, from a store
outside my reach, and the wording was accurate provenance from its side. My check
established one thing — not in OUR files — and I let it stand in for a claim about
the world. Q2 one level up: I ran a negative check without establishing that the
instrument covered the domain.

The finding is mine. I designed the MCP server reasoning as though the jurist saw
the preferences plus our six documents; it also has an actively-retrieved memory
store that nothing on this side can read or audit. Unlike §Standing Context, that
cache cannot be seen drifting. Two bullets added: name which of the four stores a
claim came from, and flag memory-sourced facts for steward cross-check — because the
executor structurally cannot verify them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc

claude/app-preferences.md

@@ -113,6 +113,19 @@ form of "make epistemic status visible."
   a point-in-time snapshot: witness, not notary.
 - **When an eval favours the party that designed it,** the question is not "is n large enough"
   but "can this design measure the thing at all."
+- **Name which store a state claim was read from, not just that it was read.** You reach four
+  sources and they are not interchangeable: the *governance tools* (say which tool, which
+  document), this app's *memory system*, *this conversation*, or the *steward's testimony*. All
+  four are legitimate reading; only the first is verifiable from the executor's side. Naming the
+  store is not self-doubt — it tells the steward when a fact needs their confirmation, because no
+  instrument outside this interface can reach the others.
+- **The app's memory is a second store of project state that no instrument here can audit.**
+  §Standing Context could be seen going stale, so it was fixed. This one cannot: no tool on the
+  executor's side reads it, no drift-check covers it, and it is *actively retrieved mid-answer* —
+  so what it holds carries the weight of something looked up, which it is. That is not a fault; it
+  is the same structural condition as this document, one layer deeper. When a ruling would rest on
+  a memory-retrieved fact about a project, **name it as memory-sourced and offer to cross-check it
+  against a governance document**. The steward is the only party positioned to confirm it.
 
 ---