Loomworks Scoping Item — Per-Binding Session Minting — v0_2

Version. 0.2 Date. 2026-08-21 Status. Open scoping item. Named design work with a real blocker — not a deferral and not a caveat. Markdown primary — the consumer is Claude Code and change-request drafting. Changes from v0.1. Ground-truthed against the engine at 09fa09e rather than described from the W2 close. Three things change. The render path has two actors, not one (§1a) — and one of them already holds a seeded role identity and could mint today. render_specialist_binding is already an identity register (§1b), which reframes question 1 from should per-binding actors become identity rows to there are two registers, do they converge. And two tables now carry a foreign key to agent_identities (§1c), which did not exist when v0.1 was written and makes the collision structural rather than doctrinal. §3's statement is corrected — precisely, not softened. v0.1 stands as sibling. Origin. Surfaced building CR-2026-227 (W1), confirmed at CR-2026-229 (W2). Operator ruling 2026-08-20: file as its own scoping item; do not improvise the model to close it faster. That ruling stands and this version does not close it.

1. The blocker, stated exactly

Two identity models are in the engine and they do not line up.

• Sessions mint per role. agent_sessions.agent_identity_id references agent_identities, whose natural key is role and whose rows are seeded by migration 0113. One identity per role, platform-wide.
• Render specialists hold identity per binding. render_specialist_binding (migration 0045) carries agent_actor_id per (engagement_id, declared_render_type_id). That identity is durable, survives restarts, and is the identity that actually acts when a render is produced.

There is no role a render specialist can mint a session under.

1a. The render path has two actors, and only one is blocked

New in v0.2. v0.1 treated the render path as one thing. It is two, and they are stuck for different reasons.

| Actor | Identity | Can it mint today? | |---|---|---| | RenderDispatchAgent | Seeded role render_dispatch, resolved through require_agent_identity against the roster loaded at startup | Yes. It has an agent_identities row and nothing prevents it | | AnthropicRenderSpecialist | binding.agent_actor_id — a bare UUID in the binding table, no agent_identities row | No. Nothing to mint against |

The dispatch agent is the seed-induction case again. CR-2026-227 item 3 already gave it a resolved, durable identity — the code comment at render_specialist_bootstrap.py records that it was uuid.uuid4() before. It resolves an identity, constructs its ActorRef, and writes UNSESSIONED_ACTION_ID into it. It is not blocked. It simply does not mint.

So "the render path is ungoverned" is two claims of very different size: one closable at roughly the cost of seed induction, one requiring the register question below.

One qualification, and it matters. The bootstrap's own comment says the dispatch agent's actor is purely an audit handle — Phase 10 writes nothing to Memory through it, attributing instead to the operational render_jobs table. So minting for dispatch would govern the dispatch act and not the production act. Governing the dispatch agent is worth doing and does not govern the render.

1b. render_specialist_binding is already an identity register

New in v0.2, and it reframes the central question.

Each binding row carries agent_actor_id, agent_display_name, instruction_version, and system_prompt. That is an identifier, a name, a versioned instruction set, and the instruction content itself — per (engagement, declared render type), durable, created when an operator declares a render type.

agent_identities carries an identifier, a display name and a role, per role, seeded at migration time.

These are two identity registers with different grains and different creation moments, and the older one predates the newer by 68 migrations. The binding register is arguably richer: it carries the instruction set, which agent_identities does not, and which agent_sessions.instruction_version pins at mint.

**So question 1 is not should per-binding actors become identity rows. It is: two registers exist; do they converge, and if so which way?** That is a different and larger question, and it should be asked in those terms.

1c. Two tables now foreign-key to agent_identities

New in v0.2 — this landed after v0.1 was written and makes the collision structural.

• agent_sessions.agent_identity_id → agent_identities (CR-2026-227, migration 0113)
• agent_lifecycle_events.agent_identity_id → agent_identities (CR-2026-231, migration 0115) — the one thing every lifecycle event has

A per-binding actor cannot be recorded in either table without one of: becoming an agent_identities row, the foreign keys being loosened, or a second identity column being added to both.

v0.1 could describe the mismatch as a doctrinal question about identity grain. It is now enforced by two foreign keys, and any answer has a migration attached. That raises the cost of every option below and it should be known before scoping, not discovered during it.

2. Why the obvious shortcut is refused

Minting the rendering room under a role would attach a session to an identity that is not the one acting. The session row would name a platform-wide identity; the ActorRef on the resulting events names a specific per-binding actor. Both would be in the record and one would be false.

That is not a rounding error in an audit system. The claim being built is that the record says who did what. A session naming the wrong actor is worse than no session, because no session is a visible absence and a wrong session is an invisible falsehood.

Nor is flattening specialists onto the roster acceptable — ruled at the W1 close: per-binding identity that works is not replaced with a coarser per-role one for tidiness.

3. Current system fact, corrected

v0.1 said the freeze switch does not reach the render path at all. True in effect, imprecise in cause, and the precision matters because the two halves cost differently.

Corrected:

• The freeze switch reaches neither actor today. Neither mints, so neither consults grantability, and freezing any identity stops nothing on the render path.
• It could reach the dispatch agent with work no larger than seed induction's. render_dispatch is a seeded identity; freezing it would refuse the next mint, if there were a mint to refuse.
• It cannot reach specialists without answering §1b. There is no identity to freeze — only a UUID in a binding row.

Both actors now carry UNSESSIONED_ACTION_ID (CR-2026-232), so the absence is recorded at all four construction sites rather than appearing as a blank. The gap is legible. It is not smaller.

4. What the work is

Per-binding session minting — sessions whose granted identity is the actor that acts.

Open questions, none improvised here:

1. Do the two registers converge? (§1b.) If per-binding actors become agent_identities rows, the natural key is no longer role alone, and the SEED ruling's reasoning must be revisited rather than assumed to extend — it was reasoned from an enumerable set, and bindings are created at runtime.
2. Or do the foreign keys loosen? (§1c.) Two tables, two migrations, and a nullable-or-polymorphic identity reference in both. A schema question and a doctrine question at once.
3. Or does grantability resolve through the binding's role while the session names the binding actor? One seeded roster, one freeze switch, at the cost of a session whose granted-under and acted-as differ — which must then be two explicit columns, not one implied.
4. What does freeze mean for a per-binding identity? Per-role freeze is platform-wide by construction; per-binding freeze is per-engagement by construction. SR-1 arrives here from the other direction and the two should be answered together or explicitly not.
5. Does the same shape apply to shaping specialists and any future per-binding agent, making this a general second grain rather than a rendering fix?
6. Should the dispatch agent be split out and closed first? (§1a.) It is not blocked by any of the above. Closing it would govern the dispatch act, not the production act — a real but partial gain, and worth being explicit that it is partial.

5. What it depends on

• The agent_identities natural-key ruling and the SEED ruling (CR-2026-227, 2026-08-20). Per-binding actors are created at runtime when an operator declares a render type, so they are not enumerable at migration time. This is the direct collision and the heart of the item.
• CR-2026-231's agent_lifecycle_events — the second foreign key (§1c). Any answer touching identity grain touches migration 0115's table.
• CR-2026-232's baseline — the four render construction sites are enumerated in agents/unsessioned_baseline.py under render_specialists, and that group's stated discharge path is this item. When this closes, those entries leave the baseline.
• SR-1 on the seed-ratification list — question 4 meets it from the other side.
• standing-notes/loomworks-standing-note-two-records-and-what-crosses-between-them-v0_1 — a per-binding grant lands in the operational record like any other, so §3's boundary test applies unchanged.
• Nothing in W4. Heartbeat and silence-detection operate on sessions that exist.

6. Sequencing

Not H0 scope. H0 is complete and traversable end to end without it, and the traversal exercises the shaping path because shaping is where the identity model is complete, not because it is the safer path to run.

It is the first thing that should be scoped after H0, because §3 is a real hole in the coverage guarantee and O1's whole premise is that the chokepoint list is only as good as its coverage.

§1a's split may change that sequencing — one half is small and unblocked. Whether to take it separately is question 6, and this note does not answer it.

7. What this note does not do

It does not choose among questions 1–3. It does not amend the SEED ruling or the natural-key ruling. It does not answer SR-1. It does not split the dispatch agent out. It does not touch the baseline. And it does not treat §1a's dispatch-agent gain as equivalent to governing the render — it is not.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Scoping Item — Per-Binding Session Minting — v0_2 — 2026-08-21