Block pool activation until a freeholder acts on the realized mapping #34

New issue

Closed

opened 2026-09-03 18:24:22 +00:00 by larandar · 0 comments

larandar commented

2026-09-03 18:24:22 +00:00

Owner

Proposal

Hold the provisioned pool inert until a person has looked at what was actually created and said yes.

Delivery class

agent-unit — the gate and its refusal path, with the presentation surface named but not itself built here.

Design

The realized name / UUID / grant-ID / version / digest mapping is presented before activation. Until a freeholder acts on it, the pool is not active and no slot may be allocated.

Ratification is presence, not channel — ruled on Ting/Ting#2 Q4. Any surface qualifies so long as a freeholder is demonstrably at a keyboard and acting; none qualifies on delivery alone. So the gate's condition is a recorded act, never a send: a notice posted to a channel, a message delivered to an absent human, or an alert raised into a plane nobody is obliged to read all leave this gate closed. The alert plane may carry the notice and cannot satisfy the gate.

What is presented is the realized mapping, not the intended one. The point of the gate is to show what the directory actually returned — names, UUIDs, grant identities and digests — so a divergence between what was asked for and what exists is caught by a person before ten principals become live.

Tasks

Present the realized name/UUID/grant-ID/version/digest mapping.
Refuse allocation while unratified, and say why.
Record the ratifying act — who, when, over which exact mapping digest.
Prove a delivered notice with no act leaves the gate closed.
Prove a mapping that changed after ratification requires a fresh act.

Specification Delta

Requirement: activation waits for a person

Scenario: the mapping is realized but unratified

GIVEN a realized name/UUID/grant mapping
WHEN no freeholder has acted on it
THEN the pool is not active and no slot may be allocated
AND delivery of a notice does not by itself satisfy this

Scenario: the mapping changes after ratification

GIVEN a ratified mapping
WHEN the realized mapping no longer matches the ratified digest
THEN the pool returns to unratified and allocation is refused

OpenSpec

OpenSpec 30

Structural parent

Vedanta#30

## Proposal Hold the provisioned pool inert until a person has looked at what was actually created and said yes. ## Delivery class `agent-unit` — the gate and its refusal path, with the presentation surface named but not itself built here. ## Design The realized **name / UUID / grant-ID / version / digest** mapping is presented before activation. Until a freeholder acts on it, the pool is not active and no slot may be allocated. **Ratification is presence, not channel** — ruled on [Ting/Ting#2](https://jo.et0.pw/Ting/Ting/issues/2#issuecomment-15365) Q4. Any surface qualifies so long as a freeholder is demonstrably at a keyboard and acting; none qualifies on delivery alone. So the gate's condition is a recorded **act**, never a send: a notice posted to a channel, a message delivered to an absent human, or an alert raised into a plane nobody is obliged to read all leave this gate closed. The [alert plane](https://jo.et0.pw/lar.ad/flake-ops/issues/470) may carry the notice and cannot satisfy the gate. What is presented is the *realized* mapping, not the intended one. The point of the gate is to show what the directory actually returned — names, UUIDs, grant identities and digests — so a divergence between what was asked for and what exists is caught by a person before ten principals become live. ## Tasks - [ ] Present the realized name/UUID/grant-ID/version/digest mapping. - [ ] Refuse allocation while unratified, and say why. - [ ] Record the ratifying act — who, when, over which exact mapping digest. - [ ] Prove a delivered notice with no act leaves the gate closed. - [ ] Prove a mapping that changed after ratification requires a fresh act. ## Specification Delta ### Requirement: activation waits for a person #### Scenario: the mapping is realized but unratified - **GIVEN** a realized name/UUID/grant mapping - **WHEN** no freeholder has acted on it - **THEN** the pool is not active and no slot may be allocated - **AND** delivery of a notice does not by itself satisfy this #### Scenario: the mapping changes after ratification - **GIVEN** a ratified mapping - **WHEN** the realized mapping no longer matches the ratified digest - **THEN** the pool returns to unratified and allocation is refused ## OpenSpec [OpenSpec 30](https://jo.et0.pw/Ting/Vedanta/wiki/OpenSpec-30-agent-identity-pool-lifecycle) ## Structural parent [Vedanta#30](https://jo.et0.pw/Ting/Vedanta/issues/30)

larandar added the

Kind/Feature

Kind/Security

labels

2026-09-03 18:25:21 +00:00

larandar added a new dependency

2026-09-03 18:25:29 +00:00

#30 Session: pool bring-up — ten pinned principals and their grants, ratified before activation

larandar referenced this issue from a commit

2026-09-03 22:24:59 +00:00

pool: bring-up — reserve, provision, and wait for a person (#32, #33, #34)

larandar referenced this issue from a pull request that will close it,