Version: v0.1
Date: 2026-08-22
Status: Scoping note. Proposes a shape and names one thing that must be ruled before any of it is buildable. Rules nothing. Markdown primary — the consumer is Claude Code and change-request drafting.
Occasion: Operator direction, 2026-08-22, in response to the per-binding identity question: can we freeze one and alert the other.
Grounded on: agents/shaping.py and agents/shaping_bootstrap.py read at engine 143fd6b; agents/render_specialist_bootstrap.py; agents/grantability.py.
Reads with: standing-notes/loomworks-scoping-per-binding-session-minting-v0_2; standing-notes/loomworks-standing-note-h0-tightening-guarantee-and-its-scope-v0_1; standing-notes/loomworks-standing-note-two-records-and-what-crosses-between-them-v0_1 (STANDING); boundaries-record SR-1.
Today one word does three jobs. Freezing an agent identity is simultaneously the record that something went wrong, the act of stopping it, and — because identity is platform-wide — a blunt statement about every other agent doing that job.
Those are three different things. They have different lifetimes, different permissions and different reach.
What happened is evidence. It is about the past, it never changes, and nothing should be able to delete it. What is stopped is a state. It is about the present, it changes, and a human reverses it. What is at risk is an inference. It is about the future, it can be wrong, and it must never move on its own.
Under one word, unfreezing an agent erases the only trace that anything was ever wrong. Split, the evidence outlives every action taken on it.
The proposal: a finding is recorded and never amended; a freeze changes one identity's state and cites the finding; an alert points other identities at the finding and stops nothing. A human acts on an alert; an alert never acts.
The one thing that must be ruled first is at §6: this needs per-identity granularity, and the identity roster is currently fixed at install time by deliberate design. The exception wanted is narrow — an operator declaring a Shaping or a render type — but it is an exception, and it is the Operator's to make.
freeze_agent_identity takes an identity, sets its status, ends its live sessions, and refuses the next grant. One call, and it carries:
shaping stops shaping for every engagement at onceThe tightening-guarantee note already records the reach problem. This note takes the other two apart.
The property that matters most, stated plainly: unfreeze currently returns the system to a state in which nothing records that anything was ever wrong. A control whose reversal erases its own justification cannot be the evidence.
A finding is evidence: an immutable record that something was observed.
| | | |---|---| | Lifetime | Permanent. Never amended, never deleted | | Written by | Whoever observed it — a person, or the system | | Contains | What was observed, about which identity, when, by whom, and the reason in the observer's own words | | Changes | Nothing. It is a statement, not an act |
A finding exists independently of any action taken on it. This is the part that is easy to lose: a finding is written when someone looks and decides nothing here, too. "Looked, judged fine" is evidence. A record that only exists when something was stopped tells you about stoppings, not about looking.
Where it lives: the operational record. By the two-records boundary test it is a fact about what the substrate did, not knowledge about an engagement's subject — it has an actor and a timestamp and cannot be disagreed with.
Corrections, not amendments. If a finding turns out to be mistaken, a second finding says so and cites the first. The first stays. Same discipline the record already holds everywhere else.
A freeze is a state change on exactly one identity.
| | | |---|---| | Lifetime | Until a human reverses it | | Performed by | A human, always. Never automatic | | Contains | A reference to the finding that justifies it — not the reason itself | | Changes | This identity is not grantable; its live sessions end |
It cites the finding rather than containing it. That is the whole separation: unfreezing changes a state and touches no evidence. Today, unfreezing loses the reason; under this shape, the reason was never in the freeze to lose.
It is as narrow as the thing that went wrong — one identity, which under §6 means one agent on one engagement, not every agent of that role everywhere.
Freezing and unfreezing are both acts and both produce findings. An unfreeze is a human deciding something is safe again, which is exactly the kind of judgment the record should hold.
An alert is a pointer. It stops nothing.
| | | |---|---| | Lifetime | Until a human clears it | | Raised by | The system, when a finding lands on a member of a class | | Contains | A finding exists that may concern you — the finding's reference, nothing more | | Changes | Nothing. The agent keeps working |
No verdict. An alert says a finding exists nearby. It does not say the alerted agent is compromised, because nobody has looked yet.
Cleared by a human deciding, not by time passing. An alert that expires on its own has decided something. Clearing produces a finding — looked, judged fine, or looked, froze it too.
No auto-freeze, ever, and not even with a delay. The moment a finding on one agent stops another, the machine has made the judgment and the Operator is reviewing a decision already taken. That is the automatic-state-transition category error, wearing a softer name. The machine surfaces and signals; the Operator approves.
Proposed, and deliberately not fixed.
If Aldous's coaching-summary agent produced something wrong, the likely cause is its instructions. Every agent running those instructions is at risk. Every agent with role shaping is not — Warwick's client-onboarding agent shares a role and nothing else.
Role is what the system calls the agent. Instructions are what it does.
But the class should be a property of the finding, not a fixed rule. Different causes implicate different sets:
| The finding | The class it implicates | |---|---| | Bad instructions | Every identity running those instructions | | A compromised API key | Every identity resolving that key | | A model-behaviour problem | Every identity on that model | | One agent misconfigured | Nobody. No alert at all |
A finding that names no class raises no alerts, and that must be an ordinary outcome rather than an edge case.
None of this works at role grain. Freezing one and alerting the rest requires that "one" be freezable on its own, and today it is not.
What exists. The identity roster holds one row per role, seeded by migration 0113, and the SEED ruling forbids runtime minting. Meanwhile the agents that actually work are per-configuration: shaping agents are keyed (engagement_id, shaping_id) with identity on each Shaping's executor block; render specialists are keyed per (engagement, declared render type). Neither has a freezable identity.
What is being asked for. An identity row created when an operator declares a Shaping or a render type.
Why this is an exception and not a reversal. The SEED ruling exists so that no running process can invent an identity for itself — a machine minting its own governed record is authority-shaped. The case here is different in kind: a person declares a Shaping, and an identity is created because a human asked. Not a process self-registering.
Whether that distinction holds is the ruling. It is narrow, it is defensible, and it is not this note's to make. Everything above waits on it.
A live fact that bears on it, and it is not hypothetical. On the shaping path today, produce_shape mints its session against the shaping roster role while attributing the work to the per-Shaping actor. Two identities, on the same act, in production, and the record does not distinguish them. So the two grains are not a future problem — they are already both present, unlabelled. Any ruling here also decides whether that ambiguity is named or removed.
| Property | Today | Under this shape | |---|---|---| | Evidence survives unfreezing | No — the reason is lost | Yes — it was never in the freeze | | Evidence exists without an action | No | Yes — looked, judged fine is a finding | | Stopping is as narrow as the fault | No — platform-wide | Yes — one identity | | Concern reaches the right set | No — role, or nothing | The class the finding names | | A machine can stop an agent | No | Still no — and that is deliberate |
The last row is the point. Splitting the concerns widens what the system can say and widens it not at all in what the system can do.
It does not rule the roster exception at §6, which everything else waits on. It does not fix the two-identity ambiguity on the shaping path — it records it. It does not design the alert surface, or say where an alert reaches a person. It does not decide whether an existing platform-wide freeze remains available alongside per-identity freeze. It does not answer SR-1, though it arrives at the same junction from a third direction. And it does not schedule any of this against the queue.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Scoping Note: Finding, Freeze, Alert — Three Concerns in One Word — v0.1 — 2026-08-22