DUNIN7-M4 — SCOPING NOTE

B-67 — the organized view is shown to the model and cannot be pointed at (v0.1)

Version. 0.1 · 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.

1. The item's own hypothesis, checked first — it holds

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.

2. What actually reaches the model

_format_manifestation_block (orchestration/prompt.py:281) emits, under the heading ORGANIZED VIEW:

the rationale (clipped) — the AI's own account of the organising principle,
each group label, and
a note count per group.

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.

3. Whether the existing citability channel fits — the real finding

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.
There is exactly one kind today. 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.

4. The shape decision this needs, stated but not taken

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.

> The scoping recommendation is A, on that reasoning — but it is a decision, not a finding, and it is the Operator's.

5. Where the work lands

| 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. Two open questions worth settling before a CR is written, both cheap:

Does the rationale need separate treatment? It is a generated sentence sitting in standing context, attributed to nothing. Citing the Manifestation makes it checkable in principle (you can go read that Manifestation's rationale), which may be enough — or the rationale may deserve to be marked as model-written, which touches B-63's territory and should not be folded in here.
What does a superseded Manifestation cite as? If the organized view changes mid-conversation, older turns cited the older one. Citing by id + version handles it correctly and for free — but only if the citation records the version as seen, which is the reason §5's "same object, not a re-read" matters.

6. Not in scope, named so their absence is deliberate

B-61's material. Different content, different remedy; that fix does not touch this and this does not touch it.
Marking the rationale as model-written. That is B-63, and it is a seed-level question.
Changing what the organized view puts in the prompt. This item is about pointing at it, not about narrowing it.

7. Seed-mutability (B-69)

Not established — a CR must check it. The organized view's rationale is described as deriving its organising principle from the seed, so a contact point is plausible here in a way it was not for the last three change requests. Flagged rather than answered: this scoping pass read the prompt path, not the derivation path.

DUNIN7 — Done In Seven LLC — Miami, Florida B-67 organized-view citability — scoping note — v0.1 — 2026-08-10