Finding — resolution is not authorization — v0.1

Version: v0.1 Date: 2026-08-24 Status: Finding. States a limit of what shipped. Rules nothing, fixes nothing. No code was changed. Occasion: Test 8 of the operator test set, 2026-08-24, where the specified actor could not reach the test engagement. Cites: CR-2026-234 (v0.3, shipped 7136e34).

1. The finding

CR-2026-234's gate proves that a person exists. It does not prove they are the right person.

That is not a defect in the CR — it is exactly and only what the CR claimed to do, and its §5 said so. It is worth recording as a standing limit because the gate's name, assert_human_commit_authority, reads like an authorization check, and this arc has now produced four instances of a contract whose name is broader than its scan. This is the same shape, in the fix rather than in the thing fixed.

2. The concrete instance: two principals named Marvin

The dev database holds **42 principals, three of which are named Marvin***:

| id | display name | created | engagement memberships | org memberships | |---|---|---|---|---| | b1df6f2e-3dcf-49d5-be76-9831765def3a | Marvin | 2026-08-05 | 0 | 0 | | 6d867b23-655a-440a-b377-e6bf4fb3882b | Marvin Percival | 2026-04-26 | 14 | 1 | | fdf32c3f-720a-418c-aab6-edce2b68e8bc | Marvin - Test2 | — | — | — |

b1df6f2e-… belongs to nothing. It is a principal row with no memberships of any kind, and it cannot reach any engagement: POST /engagements/11a11db7-…/renders under its session returns 403, "No membership on this engagement."

6d867b23-…, "Marvin Percival", is the operating identity — creator of the test engagement and a member of fourteen.

3. Where the gate sits relative to that

Both ids resolve. CR-2026-234's gate passes either, because both are real rows in principals and the gate asks exactly one question: does this id name a real human in either identity space.

So on Test 8:

• The freeze and unfreeze ran as b1df6f2e-… — identity-level acts, not engagement-scoped, so nothing stopped them, and the gate correctly saw a real person.
• The render calls could not run as b1df6f2e-… at all. They ran as 6d867b23-…, because the HTTP membership check — a different check, at a different layer — refused the first.

The gate and the membership check are answering different questions and neither is a substitute for the other. Resolution is a floor, not a ceiling: it excludes actors that name nobody, which is precisely the defect that occasioned the CR, and it excludes nothing else.

4. The scaffold's description was incomplete

The hands-on readiness scaffold, filed earlier in this arc, introduced b1df6f2e-… as "a real principal id from the dev database (Marvin)" and used it to construct the human ActorRef.

True, and insufficient. It is a real principal id. It is also an id that belongs to no engagement, is not the operating identity, and cannot perform any engagement-scoped act. Nothing in the scaffold said so, and the phrase "a real principal" invites the reading that it is the Marvin. It is not.

The lesson generalises past this one id: "a real row" and "the right actor" are different claims, and test scaffolding that supplies the first while sounding like the second will be believed. Anyone reaching for a principal id from that scaffold should check its memberships before using it for anything engagement-scoped.

5. What this is not

• Not a claim the gate should check membership. Authorization is engagement-scoped, per-act, and already lives at the HTTP boundary and in the room logic. Pushing it into a substrate-level identity gate would be a widening of that gate's remit and is not proposed here.
• Not a claim the wrong actor was used in Test 8. The freeze and unfreeze ran as the id the instruction named; the renders ran as the only principal that can reach the engagement. Both choices are recorded in the durable record — agent_lifecycle_events names b1df6f2e-…, the two render_jobs rows name 6d867b23-….
• Not a data cleanup request. Whether b1df6f2e-… should exist at all is a separate question this note does not open.

DUNIN7 — Done In Seven LLC — Miami, Florida Finding — resolution is not authorization — v0.1 — 2026-08-24