DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path standing-notes/loomworks-scoping-per-binding-session-minting-v0_1.md

Loomworks Scoping Item — Per-Binding Session Minting — v0_1

Version. 0.1 Date. 2026-08-20 Status. Open scoping item. Named design work with a real blocker — not a deferral and not a caveat. Filed at the W2 close of the H0 lane per Operator direction. Origin. Surfaced building CR-2026-227 (W1) and 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.


1. The blocker, stated exactly

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

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

2. Why the obvious shortcut is refused

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

That is not a rounding error in an audit system. The entire claim being built is that the record says who did what. A session that names 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 — already 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, stated

The render path is ungoverned by sessions. A render specialist produces content without minting, without a grantability check, and without a session id on its spend-gate call.

Freezing the rendering identity does not stop a render specialist, because no specialist consults that identity. This is the sharpest form of the fact and it should not be discovered later: the freeze switch does not reach the render path at all.

Stated as a property of the runtime, not managed as an exposure.

4. What the work is

Per-binding session minting — sessions whose granted identity is the per-binding actor, not a role.

Open questions this scoping item must answer, none of them improvised here:

  1. Do per-binding actors become agent_identities rows? If so the natural key is no longer role alone, the seeded-not-minted rule needs an answer for rows that appear when a binding is created, and the SEED ruling's reasoning has to be revisited rather than assumed to extend.
  2. Or does agent_identity_id become nullable with a second identity column? Two kinds of grantable subject in one table, which is a schema question and a doctrine question at once.
  3. Or does grantability for specialists resolve through their binding's role, while the session names the binding actor? This keeps one seeded roster and 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. The blast-radius note's SR-1 question 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 identity grain rather than a rendering fix?

5. What it depends on

6. Sequencing

Not H0 scope. H0 is complete and traversable end to end without it, and the H0 end-to-end 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 standing note O1's whole premise is that the chokepoint list is only as good as its coverage.