Version. 0.2 · Date. 2026-08-10 · Author. Claude Code.
Baseline read. Engine 5857f52, surface 40319a1. Read-only — nothing built, nothing changed.
Item. standing-notes/dunin7-build-list-v0_51 (B-67), READY to scope.
Changes from v0.1. §7 is answered rather than flagged: the derivation path was read, and this is a Kind B contact point — with the concrete consequence traced (§7.2). §4's shape decision and §5's two open questions are now settled by Operator ruling and are marked as such; a CR drafted from this note must not re-open them.
Three rulings, recorded here so the CR inherits them rather than re-deriving them:
AnswerSource. Ruled for the reason §4 gives: a retrieved note and standing context are not the same kind of thing, and one channel with a discriminator flattens a real distinction into a type tag.B-67 says: "the organized view is a real object with its own identity and version — a remedy could cite it rather than trying to cite the notes underneath. That is the first thing whoever scopes it should check."
Confirmed. Manifestation subclasses MemoryObject (so it carries a durable id and an object version) and adds engagement_version_at_derivation, derived_by, derived_at, and a current / superseded lifecycle. It is canonical in memory_events with a typed projection in manifestation_view.
So there is a thing to point at, and it is more citable than an assertion is — an assertion's identity plus a version, plus the engagement-version it was derived at, which is exactly what makes an organized view checkable: it says which state of Memory this arrangement was an arrangement of.
_format_manifestation_block (orchestration/prompt.py:281) emits, under the heading ORGANIZED VIEW:
Individual assertion content is deliberately omitted (D5). No identifier of any kind is emitted. Not the Manifestation id, not its version, not the engagement-version it was derived at.
And it is in every turn of an engagement that has one. _choose_tier returns the manifestation tier whenever a current Manifestation exists, so this block is standing context, not retrieval-triggered.
This confirms the item's framing precisely. The model is not reading unsourced note content — it is reading a summary it cannot attribute, on every turn, including the rationale, which is itself a generated claim.
CR-2026-183 (B-61) built the channel: AnswerSource, carried on a turn as answer_sources structured data and rendered by the surface as a compact read-only reference row.
Its philosophy fits B-67 exactly. Its own docstring: "a record of what the model was given, not a claim about what it used. This is what makes an answer checkable rather than what makes it true." That is the right posture for the organized view too.
Its shape does not fit. AnswerSource is assertion-shaped:
item_id: UUID # "the retrieved assertion's durable identifier"
display_number: int # "the number the responder was instructed to reference this record by"
Two mismatches, and they are the substance of this item:
display_number presumes a numbered list. Sources are rows the responder was told to cite as #N. The organized view is one standing object, not a row in a retrieved set, and the responder is given no number for it.AnswerSource has no discriminator; it is the assertion case.
The extension point already exists, which is what makes this cheap. A turn's structured_data is a kind-discriminated union (AnswerSourcesStructuredData carries kind: Literal["answer_sources"], and the surface validates the raw JSONB against the union). Adding a new kind is the established move here, not a new mechanism.
Option A — a new structured-data kind. organized_view_source, carrying the Manifestation id, its version, and engagement_version_at_derivation. Leaves answer_sources untouched.
Option B — widen AnswerSource into a discriminated union of assertion-source and organized-view-source, so a turn has one sources channel with two member kinds.
A is smaller; B is tidier. The question that decides it is not size — it is **whether the organized view is the same kind of thing as a retrieved note.** It is not: notes are retrieved for this question, whereas the organized view is standing context present on every turn regardless. Two channels would say that honestly; one channel with a discriminator would flatten a real distinction into a type tag.
> Ruled: Option A, on that reasoning. (Operator, 2026-08-10 — see §0. Settled; the CR does not re-open it.)
| Repo | What |
|---|---|
| Engine | Emit an identifier alongside the ORGANIZED VIEW block, and populate the new structured-data kind from the same Manifestation the block was rendered from — the same object, not a re-read, or the citation could name a different version than the one the model saw. |
| Surface | Render the new kind in the existing reference row. The row exists; this is a second member, not a new surface. |
Size: genuinely small, and smaller than B-61 — the object exists, the channel exists, the surface row exists.
Both questions v0.1 raised are now settled (§0): the rationale gets no separate treatment here, and the citation records the object as rendered rather than re-reading it. The second ruling also disposes of the superseded-Manifestation case for free: if the organized view changes mid-conversation, older turns cited the older id and version, which is correct without further work — provided the version recorded is the one seen, which is exactly what the ruling requires.
Checked on the derivation path, read-only. This is a contact point, and it is Kind B.
The worked example keeps Kind C honest: ShapeEvent.seed_version_at_production is seed-aware but not seed-dependent, because nothing reads it and nothing about it changes if the seed moves. This fails that test in both halves.
manifestation_organization.py puts the seed into the prompt that produces the grouping, and instructs the model in as many words:
> "Use the seed's purpose as your organizing principle." > "[State] what organizing principle you followed (derived from the seed's purpose)."
So the rationale is not a field that happens to sit near a seed version. It is a generated claim whose subject is the seed's purpose. Something reads the seed (the organiser), and something changes in meaning if the seed moves (the rationale).
Traced; not inferred.
superseded in exactly one circumstance — a new derivation replacing it. A seed change is not one. It stays current.seed_version stays correct as a historical stamp: it records the seed version in force at derivation, which remains true.seed_block + manifest_block, where the seed block is get_current_seed(...) — the current seed — and the manifestation block is the rationale derived from the older one. They are adjacent in the same prompt, about different documents, with nothing distinguishing them. On every turn.
> The sharpest part: the system already computes exactly the comparison that would detect this. preview_manifestation emits seed_version_changed (manifestation.py:449) by comparing the current seed version against the prior Manifestation's, and CR-2026-189 carried it to the surface as usedNewSeed in the Manifestation room. **But it is only ever asked about a would-be next derivation.** Nothing asks it of the Manifestation currently in force — which is the one in every prompt.
So this is not "nobody thought about seed drift here." The drift is detected, surfaced, and acted on at the one moment the Operator is already considering re-deriving. The gap is that an existing organized view is never re-examined against a seed that moved under it.
Per the standing instruction: the contact point is recorded and nothing here is built around it. No invalidation, no staleness flag, no recomputation is proposed — that is precisely what B-69 has to settle, and Kind B is not closeable before it.
> One thing worth naming, because it costs nothing and is not designing for the open question. B-67's own remedy makes this consequence visible without deciding anything. If a turn cites the Manifestation it was given, by id and version, then the cited object already carries seed_version — so an Operator following the citation can discover that the arrangement was organised under a seed that has since moved. B-67 does not fix B-69 and must not try. But citing the object, which B-67 wants for its own reasons, happens to turn an invisible drift into a discoverable one.
The item asks: what breaks if a seed changes? This site answers with something more specific than a broken read. Nothing breaks. No exception, no wrong number, no failed query. What degrades is the truthfulness of a stored sentence that is injected into every turn — and it degrades silently, while the same system displays a correct seed alongside it.
That is a different failure shape from the inventory's earlier entries, which were signals stopping at a boundary. This one is a generated claim outliving its premise — and it is, notably, the same shape as the pattern recorded in descriptions of state are not state, arriving this time inside the product rather than inside the record.
DUNIN7 — Done In Seven LLC — Miami, Florida B-67 organized-view citability — scoping note — v0.2 — 2026-08-10