Version. 0.1
Date. 2026-08-21
Status. Read-only inspection findings, answering inspection-briefs/loomworks-w6-step-0-inspection-brief-v0_1.md. Nothing was fixed, designed, or drafted.
Engine. main at 22bec5d, alembic head 0114. Dev database inspected live.
The brief's central hypothesis is confirmed, and it makes W6 smaller than expected. The capability-reference seam exists, is persisted on every event, and is empty. W6 fills a seam rather than cutting one.
The accrual argument in §2 is currently theoretical, and by a wider margin than expected. Not "a handful of test runs" — zero. No agent action has ever run through the spend chokepoint since sessions existed.
One claim in the brief's §3 is refuted on two of six entries. They are not drift, but they are not all W6's.
Answered first because it changes the shape of the work.
It exists in the domain type. memory/base.py:200 — capability_ref: UUID | None = None on ActorRef, documented at :170 as "the assertion id of the delegation that authorized the action."
It is persisted, on every event. ActorRef serializes whole into memory_events.provenance.wasAttributedTo. 472 rows in the dev database carry the capability_ref key.
It is empty in every one of them. provenance #>> '{wasAttributedTo,capability_ref}' IS NOT NULL returns 0. A live agent-kind provenance reads:
{'wasAttributedTo': {'id': 'aed20d96…', 'kind': 'agent',
'display_name': 'agent-specification specialist',
'approval_mode': None, 'capability_ref': None, 'instruction_ver…
It is populated in code, but only on the Companion delegation path — delegation/action_dispatch.py:266 and notifications/service.py:719, both passing a delegation assertion id. No agent write populates it. The 0 count means no delegation-flow write exists in dev either.
So: the field is present and unwritten, exactly as the brief hypothesised. W6 may be filling an existing seam. No migration is needed to carry a reference on an agent action — provenance is JSONB and the key already serializes.
One fact the CR must weigh, reported not resolved. The field's documented meaning is "the assertion id of the delegation that authorized the action." A session id is not an assertion id. Whether a session is the right thing to put in capability_ref, or whether it needs a sibling field, is a design question this brief forbids answering. The seam exists; whether it is the right seam is the CR's to settle.
Correction to the brief's premise. §5 describes the accountability note as "a 2026-06-14 document describing code," and the instruction to run this called it fourteen months old. It is dated 2026-06-14 and today is 2026-08-21 — it is two months old, not fourteen. And on this point it had not drifted at all: it describes the schema accurately. The arc's twice-burned instinct was right to check and wrong about the result.
Answered second because it bears on sequencing.
Metered calls through the spend chokepoint, by room, from credit.flows (event_kind='consumption_token', distinct transaction_id):
| Room | Calls | First | Last |
|---|---|---|---|
| classify | 31 | 2026-07-03 | 2026-08-14 |
| respond | 31 | 2026-07-03 | 2026-08-14 |
| shaping | 3 | 2026-08-10 | 2026-08-16 |
| rendering | 1 | 2026-08-16 | 2026-08-16 |
Total 35 distinct metered transactions over 44 days — a mean of 0.80/day. 26 in the last 30 days, 4 in the last 7.
The number that matters is not 35. classify and respond are Companion rooms; the Companion is not an agent identity and mints no session. The agent rooms are shaping and rendering, and they account for 4 calls in total, ever.
And all four predate sessions existing. The latest is 2026-08-16; W1 landed 2026-08-20. Zero agent actions have run through the spend chokepoint since there was a session to attribute them to.
Zero flows carry a session or agent in metadata — extra_metadata::text ILIKE '%session%' OR '%agent%' returns 0.
Sequencing read, stated as a fact rather than a recommendation: the §2 accrual argument is sound in principle and currently costing nothing. At 4 agent-room calls in the engine's lifetime and 0.80 metered calls/day across all rooms, the permanently-unattributable set is empty today and grows slowly. **The accrual argument is a reason W6 cannot be deferred indefinitely; it is not, on this evidence, a reason it must precede other queued work.** That is the Operator's call and this brief does not make it.
AgentDecision
Defined: engagement/types.py:397-404. A Pydantic model, member of the DecidedBy discriminated union.
Present and unwritten. session_id: UUID | None = None exists (added CR-2026-227 item 8). Constructed in exactly one place in src/ — agents/retrieval.py:136, decided_by_override=AgentDecision(actor=self.agent_actor) — which does not pass session_id.
Persisted, not a row of its own. It is nested inside BoundaryRecord.decided_by, which serializes into memory_events.payload as part of the boundary record. There is no agent_decisions table.
Readers: engagement/boundary.py accepts it as decided_by_override (:109) and stores it (:127); nothing reads session_id off it. The field is present, unwritten, and unread.
In scope at the moment of the act (RoomSpendContext, credit/room_gate.py:34-70): person_id, engagement_id, actor_kind, key_source, secret_key, turn_event_id, spend_pause_approved, actor_id, session_id, agent_actor_id.
What reaches a persisted row. gated_room_complete calls write_room_consumption_flows(person_id, credit_asset_id, model, prompt_tokens, completion_tokens, engagement_id, turn_event_id, room, db).
agent_actor_id and session_id are not passed. They are used at the gate — for the labelling invariant — and then dropped. The spend record names the person who paid and the turn, never the agent that worked nor the run it worked under.
A seam worth reporting. The flow rows are CreditFlowRow(... extra_metadata={"engagement_id": …, "pipeline_stage": room}) — extra_metadata is JSONB, so carrying more requires no migration. Whether that is the right home is a design question; the fact is that a home exists.
And on the own-key path, nothing is written at all. gated_room_complete returns the completion without calling write_room_consumption_flows. Own-key agent actions leave no record — the gate now sees them (CR-2026-228), but no row records that they happened.
Confirmed: none of the four transitions writes to the record.
grep -c append_event returns 0 for agents/sessions.py, agents/grantability.py, and agents/presence.py.
Where each transition happens, for the CR to name:
| Transition | Location |
|---|---|
| mint | agents/sessions.py::mint_session — raw INSERT INTO agent_sessions |
| close / end | agents/sessions.py::close_session, ::end_session — conditional UPDATE |
| refuse | agents/sessions.py::mint_session returns SessionRefusal; no row is written at all |
| freeze cascade | agents/grantability.py::freeze_agent_identity → ::end_sessions_for_identity |
| silent | agents/presence.py::sweep_silent_sessions → end_session(reason="abandoned") |
The refusal case is the sharpest. A refused grant writes nothing anywhere — it returns a citable verdict object and logs. A refusal is currently the least recorded event in the system, and it is the one an audit most wants.
Stronger than the state report inferred. In the dev database there are 0 rows in agent_sessions.
The state report said a session's story reads grant → sign-out with nothing between. In dev there is no story at all: not one session has ever been recorded. The traversal test runs against the test database inside a rolled-back transaction and leaves nothing behind.
Consistent with Q7: the last agent-room call was 2026-08-16 and W1 landed 2026-08-20, so nothing has exercised the shaping path in dev since minting existed.
Cross-checks, all zero: memory_events.payload, memory_events.provenance, and credit.flows.extra_metadata mentioning session_id — 0, 0, 0.
agent_identities holds the four seeded roles, all active: render_dispatch, rendering, seed_induction, shaping.
What exists:
memory_events via append_event (memory/events.py:144). Signature: engagement_id, object: MemoryObject, event_kind, actor: ActorRef, event_id, db. It does not accommodate a session id today. It takes an ActorRef, which does carry capability_ref — so a session reference could travel inside the actor without widening the signature. Widening it instead would touch 55 files that call append_event.agent_sessions rows read as a log. Every transition is already durable there — mint writes a row, ends stamp ended_at + end_reason. Except refusals, which write nothing (Q4).credit.flows.extra_metadata, JSONB, no migration needed (Q3).
Reported, not chosen. Note the tension for the CR: append_event requires a MemoryObject and an engagement_id, and a session refusal has neither an object nor, necessarily, a settled engagement context.
> The six anchor-priority entries … are not drift; they are W6's output, registered ahead of it.
Not drift — confirmed. All six were registered by this arc: five by CR-2026-227 (W1, item 11) and agent_session_silent by CR-2026-230 (W4). Every one was pre-registered under O7 deliberately. The FORAY R-2 note's "do not clean them up" holds.
W6's output — refuted for two.
Four are W6's, unambiguously — agent_session_minted, agent_session_closed, agent_session_refused, agent_session_silent. All four are session lifecycle events with a real runtime act behind them and no writer.
agent_identity_frozen belongs to a different change. It has a real runtime act — grantability.py::freeze_agent_identity, CR-2026-229 (W2) — but freezing an identity is not a session event. It is a W2-lane act that W2 did not record. Giving it a writer is legitimate work; calling it W6's output miscounts which change owns it.
agent_identity_minted has no runtime act at all, and W6 cannot give it one. Agent identities are seeded by migration 0113 and never minted at runtime — that is the 2026-08-20 SEED ruling, and grep confirms no INSERT INTO agent_identities or AgentIdentityRow(...) construction exists anywhere in src/. There is no moment in the running system at which this event could be emitted. It is not drift and it is not W6's; it is an entry pre-registered for an act the design forbids. Emitting it would require either a migration-time emission or a change to seeded-not-minted.
Consistent with the record: CR-2026-227 v0_6 §3 item 11 already flagged the two identity entries "for W6's priority review rather than silently ranked here." This inspection turns that flag into a finding: the correct count is four W6 entries, one W2-lane entry, and one entry with no possible runtime writer.