Version. 0.1
Date. 2026-08-05
Author. Claude.ai (drafting session). Operator: Marvin Percival.
Executed by. Claude Code on DUNIN7-M4, one session.
Target. /Users/dunin7/loomworks-engine at main bd60cec, tag answer-sources-v0_1; /Users/dunin7/loomworks at main 1245f1c, tag answer-sources-surface-v0_1. Both read-only. [EXECUTING SESSION: confirm both; report if either has moved.]
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. R-5 inspection run.
Build-list item. B-12.
Status. Read-only. Establishes ground for a scoping note, not for a change request — this item is a design space, and the sequence is inspection, then options put to the Operator, then a build.
What B-12 is. Asked about their own past notes, the Operator gets an answer built from the fifty most recent contributions, ordered by recency, with no relation to what was asked. The model picks out what looks relevant from that dump. A note outside the window is invisible, and the answer cannot say so because it does not know.
What changed underneath it. B-11 attached the actual retrieved records to every answer and made the window visible. So the channel exists and the boundary is honest. B-12 changes what fills the set.
Grounding. inspection-briefs/loomworks-b11-step-0-findings-v0_1 — which established the current retrieval and named it as a deliberate current-scope limit.
Both repositories read-only. No fixes, no branches, no commits, no dependency changes, and nothing is installed — not an extension, not a package, not an index.
No model call, and no embedding call. [EXECUTING SESSION: if establishing a fact would need either, report what it would cost and halt rather than spending.]
Database. playground_dev and playground_test are never touched. A throwaway is permitted for reading capability — what a database engine supports is a fact about the engine, not about production data.
No dev server, no perimeter call.
A failure is a result.
State only what you have read or run, plus the disciplines at standing-notes/loomworks-standing-note-executable-document-versions-v0_8:
unread or unrun rather than closing a gap with a plausible reading.Any search design rests on this and nobody has measured it.
3.1 Volume. How many committed assertions exist per engagement — the distribution, not an average. [EXECUTING SESSION: if this needs production data, report it as unread rather than querying playground_dev. A throwaway will not have it.] A window of fifty is a severe limit against ten thousand notes and no limit at all against forty.
3.2 Shape. What a single assertion's content actually is — a sentence, a paragraph, a document, structured fields. Read real examples if any non-production source has them; report the field definitions either way.
3.3 What else is searchable in principle. Assertions are one kind of record. Manifestations, shapes, renders, files, conversation turns — establish which carry text a person might reasonably want to find, and which are already reachable by other means.
3.4 What is already indexed. Any index on any text column, anywhere. Whether the schema anticipated search and nobody used it, or never did.
Postgres has capabilities that need no new infrastructure, and whether they are available here is unread.
4.1 Full-text search. Whether the Postgres version in use supports it, whether any configuration exists, and what it would take to use it — a generated column, an index, a query change.
4.2 Trigram or fuzzy matching. Whether the extension is present or installable in the deployment.
4.3 Vector search. Whether any vector extension is installed, referenced in the schema, or listed as a dependency. Report presence or absence; do not evaluate whether it should be used.
4.4 What the deployment permits. [EXECUTING SESSION: installing a Postgres extension may need privileges the application's role lacks — the stand-up work established the role cannot create databases. Establish what it can and cannot do.] This constrains the options more than any preference will.
B-11 built the channel. Establish exactly where a different filler would plug in.
5.1 The seam. The function that currently fetches by recency, its signature, and every caller. How many places would change if it returned a different set?
5.2 What the answer's sources field is populated from, precisely — whether it takes whatever that function returned, or something narrower. If it is coupled to the recency query specifically, that coupling is a finding.
5.3 The scope statement. B-11 made the answer say what it looked at. Establish where that sentence is composed — it must change with the retrieval, and if it is hardcoded rather than derived, that is a finding too.
5.4 Anything else that fetches for the model. The read found a second always-attached context block of recent assertions, separate from the intent's own retrieval. Establish whether it exists, what it does, and whether B-12 touches it.
Two constraints, both established elsewhere and both binding here.
6.1 Authority. Every read in this system is fenced by membership, and the non-member contribution work turned on that fence being structural rather than a rule. Establish how the current retrieval is scoped — by engagement, by person, by membership — and what a search would have to reproduce. A search that reaches across an engagement boundary would be the most serious defect this project could ship.
6.2 Honesty. The answer states what it looked at. A search makes that harder, not easier: the notes matching your question is a claim about relevance, and relevance is a judgement. Establish what the system could truthfully say about a searched set — how many matched, what was excluded, whether anything was cut off by a limit. Report what is knowable; the scoping note decides what to say.
playground_dev. Volume may therefore be unread, and that is acceptable.One findings document, Markdown primary.
Path. inspection-briefs/loomworks-b12-step-0-findings-v0_1.md. Copy to ~/Downloads.
Structure: environment (both SHAs, both tree states, which databases, and an explicit statement that nothing was installed and no model or embedding call was made) · question two first — what the database can already do and what the deployment permits, because that constrains everything else · question one's data facts, with volume marked unread if it is · question three's seam · question four's two constraints · corrections preserved · unread and unrun, with what each would cost.
Filing. Charter R-1: commit and push on clean pre-flight. Append the outcome to current-status/dunin7-status-brief.
B-12 Step 0 inspection. Read-only.
Brief: loomworks-record/inspection-briefs/loomworks-b12-step-0-inspection-brief-v0_1.md
Confirm it exists, and that it is the highest version present — numeric sort.
Read the brief in full. Charter dunin7-standing-authorization-charter-v0_1 governs.
Two repositories, both READ-ONLY — the brief's header names them and their SHAs.
Confirm both; report if either has moved.
NOTHING IS INSTALLED — not a package, not a Postgres extension, not an index,
not even in a throwaway. Establishing what is available is the job; making
something available is not.
No model call and no embedding call. If a fact would need one, report the cost
and halt.
playground_dev and playground_test are live databases and neither is touched. A
throwaway is permitted for reading what the database engine supports.
This brief establishes what exists and does NOT design. Where a finding suggests
an approach, report the finding and not the approach — the scoping note is where
options go, and an inspection arriving with a preferred answer has stopped
inspecting.
Answer Section 4 FIRST: what the database can already do, and what the
deployment's privileges permit. That constrains every option more than any
preference will.
File findings per section 8. Append the outcome to the status brief.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — B-12 Step 0 inspection brief — v0.1 — 2026-08-05 The channel is built and the boundary is honest. This establishes what could fill it.