An agent thatworks the thread.
The agent reads the ledger, works one stage at a time against a recipe and emits a single typed item per step. What it cannot do is push past a review gate on its own — it stops at every gate until a human has validated the evidence upstream, enforced server-side on every step.
AI is an accelerant, never a dependency
The agent wraps @earendil-works/pi-agent-core and drives the ledger through the ISO/IEC/IEEE 15288 lifecycle stage by stage. It proposes; a human validates every gate regardless of how far its autonomy is dialled. The loop needs no autonomy to be safe — turn every tool class to deny and the same human review still closes the same gates. Nothing load-bearing sits behind the model.
What actually happens between a spec and a data package
- 01
Frame
The mission need is grounded first: what the system must do and the conditions it must do it in. From it the agent derives singular, verifiable requirements and assigns a verification method to each — nothing enters the thread that cannot later be closed against evidence.
- 02
Model
Candidate concepts are traded, an architecture is chosen, and the sizing loop runs until it converges with positive margin against every hard constraint. The result is captured as one machine-checkable ELANG model, checked against its well-formedness rules.
- 03
Prove
Requirements are closed against evidence, never assertion. Nothing closes a requirement on JUDGMENT when its verification method demands MEASURED, and an UNKNOWN class blocks closure outright. Verification runs, and the digital replica is correlated against the models it claims to represent.
- 04
Gate
A human reviews the proposal and the evidence behind it, then validates or rejects. Only user_validated items count as fulfilled contracts — the agent cannot carry an unreviewed baseline past a gate, and one revision upstream marks everything downstream stale until it is proven again.
One policy, one thing it can never buy
Autonomy is a policy over tool classes: read, write and browser, each set independently to ask, allow or deny. The default is ask — a call that needs approval routes to a human queue. What no setting can buy is the gate: a human validates every gate regardless of how the dials are set. Both are enforced server-side, on every step.
Autonomy · the policy per tool class
- read
- ask · allow · deny — default ask
- write
- ask · allow · deny — default ask
- browser
- ask · allow · deny — default ask
What holds whatever the policy says
- Gates
- A human validates every gate, whatever the policy.
- Supersede
- Replacing a validated item requires a written reason.
- Approval queue
- A call awaiting approval auto-rejects after 5 min.
The seeded agents run with every class at ask: each read, write or browser call surfaces in the approval queue before it happens, and nothing an agent produces closes a gate — only a human validating the evidence does.
Six things that stand between an agent and a closed gate
None of these are advisory. Each is enforced on the server, on every step, whatever an agent's autonomy is set to.
Human-validated gates
An autonomous run cannot design on an unreviewed baseline. Only user_validated items count as fulfilled contracts, so the agent stops at each of the five review gates until a human has validated the evidence upstream.
Evidence-class enforcement
Every item carries an evidence class across eight ranks. An UNKNOWN class blocks any requirement that depends on it, and nothing closes a requirement below the class its verification method demands.
Downstream staleness
Changing an item's content marks everything reachable forward along produces-edges as stale. A stale item stops counting as a valid contract fulfilment until it is proven again.
Supersede with a reason
An item is never quietly overwritten. Superseding one requires a written reason, kept on the thread — the revision history is an argument, not a diff.
The approval queue
Any tool call the policy sends to ask routes to a human approval queue before it runs. Nothing waits forever: a call left unapproved auto-rejects after five minutes.
Scoped tokens and roles
Every capability is a REST endpoint behind scoped, long-lived API tokens and three roles — admin, user, viewer. An agent reaches only what its token and role allow.
A requirement's proof is kept, not remembered
Every item carries its artifact type, its evidence class, its revision and its validation state on the thread. Six months later the question 'what closed this, and how strong was it' has an answer.
Decide how much autonomy your agent gets.
We will walk the policy model against your own program: what read, write and browser mean for your recipes, where the gates fall, and why a human validates every one of them whatever the dials say.