Finding — the render path never asks — v0.1

Version: v0.1 Date: 2026-08-24 Status: Finding. States what is known. Rules nothing, fixes nothing, commissions nothing. No code was changed. Occasion: Test 8 of the operator test set, run live 2026-08-24 — freezing the rendering identity reports success and stops nothing. It reproduces. Sits beside: loomworks-standing-note-h0-tightening-guarantee-and-its-scope-v0_1 and loomworks-scoping-per-binding-session-minting-v0_2. Neither is amended. Cites: DR-02, DR-15, DR-18.

1. The finding

The render path does not consult grantability. Not bypassed, not raced — never asked.

A freeze on the rendering identity is not defeated by a stale cache, a race against an in-flight job, or a check that fails open. There is no check. Nothing in the render path ever poses the question the freeze exists to answer.

2. What was run

Order was chosen so the control came first and the comparison is direct.

| Step | State of rendering | Result | |---|---|---| | 1 | active | POST /engagements/…/renders → 202, job e1bcbbae-… → completed | | 2 | — | freeze committed, ended=0, status reads frozen on a fresh connection | | 3 | frozen | same request → 202, job 2f40d1b9-… → completed |

Identical outcome. Both jobs ran with an agent-kind render_specialist_ref. Zero sessions were minted at any point — agent_sessions has never held a row, before, during or after.

3. The trace

All 28 files on the render production path were searched — render_dispatch, render_specialist, render_specialist_bootstrap, render_jobs, render.py, render_candidates, the composition orchestrator, the specialist store, the credit specialists, the projector, and the rest.

Zero references to check_grantability, mint_session, require_live_session, or resolve_agent_identity.

4. The governance surface has exactly three consumers

Named, because the size of the list is the finding:

• check_grantability — called only from agents/sessions.py (two sites: mint_session, and the re-check in require_live_session).
• mint_session — called only from agents/shaping.py.
• resolve_agent_identity — called only from within agents/ itself (identity_roles.py, grantability.py, identity.py).

Shaping is the only room wired to the governance runtime. Rendering is not, and neither is anything else. The H0 lane built a switch; exactly one room is on the other end of it.

5. Two registries sharing a word

agent_identities and render_specialists are unconnected. They are separate tables, separately seeded, with no foreign key, no shared id, and no lookup between them. The only thing they share is a noun.

The concrete instance, from Test 8:

• The frozen row was rendering in agent_identities, id …022702.
• The specialist that actually ran was a1375037-9ffb-461b-9fee-69a811d9250f, "Picture-book reading copy specialist", from render_specialists.

The relationship between them is the word "render". Freezing the first says nothing to the second, because nothing connects them and nothing looks.

This is why the freeze "reports success and stops nothing" — and why the success report is not a lie. freeze_agent_identity did exactly what it says: it set status='frozen' and ended every live session of that identity, of which there were none. It made no claim about rendering, and nothing in the system had ever arranged for it to.

6. Second hazard, forward-looking: the roster cache is process-local

This does not matter today. It will matter the moment the render path is wired.

The freeze in step 2 called load_agent_identity_roster — in the process that ran the freeze, not in the running API server. The roster is a module-level cache, so the server kept whatever it had. Nothing surfaced, because the server never consults the roster on the render path.

The moment rendering is wired to grantability, that changes shape:

• In tests, it will pass. The suite runs in one process, and its autouse fixture loads and resets the roster per test. A freeze and the check that follows it share a cache.
• In production, it will not. The freeze arrives through one process and the render runs in another. The second process holds a roster loaded at its own startup and has no reason to reload it.

So a correct-looking fix, with green tests, would leave the switch not working — and the failure would be intermittent, process-dependent, and invisible to the test that was written to prove it fixed. DR-18 asks for freeze to be effective at the gate immediately; a per-process cache cannot deliver that across processes without an invalidation path, and there is none.

This is the finding worth having before the wiring, not after. Recorded now, while it costs nothing, precisely because it is cheap to design around in advance and expensive to diagnose later.

7. What this is not

• Not a claim that the render path should consult grantability. That is a design question about scope, and this note does not answer it. It says only that the question is not currently asked, and that Test 8's result follows from that and needs no other explanation.
• Not a defect in freeze_agent_identity. It did what it says. DR-15 stands; freezing remains open to any actor.
• Not a contradiction of the tightening guarantee. loomworks-standing-note-h0-tightening-guarantee-and-its-scope-v0_1 is about the scope of that guarantee. This is a concrete instance of where the scope ends, observed rather than reasoned. That note is not amended.

DUNIN7 — Done In Seven LLC — Miami, Florida Finding — the render path never asks — v0.1 — 2026-08-24