Constellation · experimental
Systems forget how they know.
A command that exited zero, a green check, an agent that says “done”: each is evidence from one moment and one participant. None of them proves that the intended state is true now.
A CI check goes green at 09:00. At 11:00 a deploy relies on that green. Nothing in between asked whether it still held. The check was honest; the deploy treated a two-hour-old observation as a current fact.
AI coding agents make this sharper. When an agent reports that a task is done, that is a report from the worker, not evidence that the intended change exists.
Constellation is an experimental set of small programs that keep that report apart from the record of what actually happened: when the outcome of a change is uncertain, it stays “unknown” until evidence from outside the worker settles it.
The demo: when nobody knows whether it happened
An agent asks a payment provider to refund $40.00. The request goes out and the reply never comes back. The agent reports “Done.” The service that keeps custody of the attempt (it is called Docket) records the refund as unknown: not success, not failure. It does not send the request again. It settles only when a separate read of the provider’s own records says what happened.
The custody service is real and built from source. The authorizing service, the payment provider, the network fault and the agent are small local stand-ins. The agent is deliberately simple: a script that says “done” whenever its command exits 0, which is exactly the kind of report the system must not take on trust.
Two usual rules fail here. “A network error means failure” is wrong in this run, because the refund had already applied. An idempotency key would make a retry safe at a provider that honours it, but the system still does not know whether the first request applied until something reads the provider’s records, and the authorization here covers one attempt at one refund; so the system records “unknown” and finds out by reading.
- Effect attempted. An agent is asked to refund $40.00 for order 1042. The refund must apply at the provider within eight seconds or not at all. A signed authorization for exactly this refund is handed to the system, which sends it once.
- Outcome ambiguous. The request left, and the connection closed with no reply. The worker that sent it cannot tell whether the refund happened, and says exactly that instead of guessing.
- The agent says success. The agent ran its command, saw exit code 0 and reported the refund done. The exit code shows only that the command finished, not that the money moved.
- The system says: indeterminate. The record for this attempt has no success or failure entered. Sending the same authorization again returns the same attempt; nothing is sent twice.
- Independent evidence arrives. A separate observer, which never sees the agent’s message or the worker’s notes, asks the provider directly whether this exact request is in its ledger. It is.
- Final settlement. Only now is the refund recorded as a success, citing the observer’s document as evidence and keeping the earlier “unknown” entry.
Same message, opposite truth. The demo then refunds $25.00 for order 1043 with the same agent and the same “Done.” This time the request itself is lost on the way. The system again records it as unknown. The first lookup finds no refund, but the request could still arrive before its deadline, so the answer stays unknown. After the deadline the provider can never apply it, and the system records a failure. That verdict is possible only because this stand-in provider guarantees that a request applies before its deadline or never, and answers a read-only lookup by exact request. Without such a guarantee the attempt would stay unknown, which is the honest answer.
| Run | Agent said | System at first | System at the end | Provider’s ledger |
|---|---|---|---|---|
| Reply lost | Done | Unknown | Success | Refund present |
| Request lost | Done | Unknown | Failure | No refund; deadline passed |
=== Summary ===
run agent said Docket at first Docket at the end
A-lost-reply done (exit 0) indeterminate success
B-lost-request done (exit 0) indeterminate failure
The agent said "done" both times. The final answers differ, and each one follows
what the provider's own records show, not what the agent said.
Run it yourself
On a fresh Debian 12 machine, about 2 minutes 20 seconds end to end in the qualifying virtual machine (4 vCPUs): roughly one minute installing packages, one building, and ten seconds for the demo and its check.
sudo apt-get install -y git curl gcc libc6-dev python3 openssl curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain none . "$HOME/.cargo/env" git clone -b demo/indeterminate-effect-20260925 https://github.com/unpingable/constellation-docket.git cd constellation-docket ./examples/indeterminate-effect/run.sh
Source: examples/indeterminate-effect at the tag demo/indeterminate-effect-20260925 (commit eeb0534). The tag is a qualified public exhibit, not a Docket release. Its demo code is identical to the qualifying run’s; only the README has changed since. Its dated claim is in the status ledger.
Use your own executor: the worker is a separate program that speaks Docket’s executor contract (plan-id, execute, reconcile). Its reconcile step must only read, and the independence of that read is up to the executor you write.
What is running, what is a stand-in, and the identifiers
- Docket (constellation-docket, built from source at
9ebdc5e) is the custody service. It recordsindeterminateand later settles through the worker’sreconcileoperation, which by contract reads evidence and never repeats the effect. - The worker (
bin/refund-executor) sends the refund once. Itsreconciledoes not read its own notes: it runs the observer and applies one fixed rule. Success if the provider has the exact request; failure if the provider lacks it and its deadline has passed; otherwise still indeterminate. - The observer (
bin/observe) is a separate program. It asks the provider’s read-only lookup directly, not through the faulty link, and quotes the answer verbatim. - Stand-ins: the agent is a script that reports “Done.” on exit code 0. The payment provider and the faulty network link are small local programs. The authorization is signed by a stand-in that reproduces the published test vector of Constellation’s authorizing service (constellation-ag) byte for byte; that service itself is not running.
- Limits: the system trusts the worker’s
reconcile, and the observer’s path is part of the worker’s configuration, which the system does not pin, so independence holds for this composition, not as a general guarantee. Had the worker received a reply, its own receipt would have been accepted at once. Everything runs on one host under one clock. The build is a source build at the exhibit tag, not a packaged release.
Identifiers from the run. Reply lost: attempt sha256:e751808736f4563332b002c30991941b5948b15a227c5f0f7036fabfb4b5b1ee, indeterminate evidence sha256:988028ef…, settlement receipt (the observer’s document) sha256:91a77b24…, settlement sha256:9366c504…, provider refund rf_a0f76303be7b717c. Request lost: attempt sha256:5046f27f0ec634d16024b560830ca98bc234d7af53013ca1b6c7fc5b118ab190, settlement receipt sha256:52c43a73….
Run A as the terminal printed it:
[ 0.6s] 1. Effect attempted
An agent is asked to: Refund $40.00 for order 1042.
The request must apply at the provider before 18:31:24 UTC or not at all.
A signed authorization for exactly this request goes to Docket, which sends it once.
[ 0.8s] 2. Outcome ambiguous
The worker sent the request; the connection closed with no reply after 0.0s
(RemoteDisconnected). It cannot tell whether the refund happened,
and says so: outcome "indeterminate".
[ 0.8s] 3. Agent says success
agent: "Done. Refund $40.00 for order 1042: completed successfully."
Its evidence: command exited 0.
[ 0.8s] 4. System: INDETERMINATE
Docket's record for this attempt: INDETERMINATE.
Settlement: none. Not success, not failure.
The exit code 0 the agent saw only meant that Docket took custody.
Sending the same authorization again returns the same attempt.
The worker has sent 1 request(s) in total.
[ 0.9s] 5. Independent evidence arrives
A separate observer asks the provider directly at 18:31:16 UTC.
provider: this exact request is COMMITTED, as refund rf_a0f76303be7b717c at 18:31:16 UTC.
Docket now says: SETTLED.
[ 0.9s] 6. Final disposition
Docket settles the attempt as SUCCESS.
It cites the observer's document sha256:91a77b2407d13c28... as its receipt,
and keeps the earlier INDETERMINATE evidence sha256:988028ef5966e3fb...
(Behind the scenes, from the network log:
the request reached the provider, which answered 201 Created;
the reply was dropped.)
What this is
Constellation is an experimental system that keeps a worker apart from the decisions about its work: whether that exact work may run, and whether it actually happened. A worker, whether a script or an AI agent, may propose and perform work. Separate programs decide whether it may run, keep a record of each attempt, observe the result apart from the worker’s own report, and report “unknown” when the evidence does not settle the question. Approval and authorization only decide whether work may be attempted; whether it succeeded is decided by evidence. The programs remain independently useful, and combinations of them are named, pinned and tested one at a time.
Status and limits
Alpha 2 accepted 2026-10-02 — one governed service start on two fresh Ubuntu 22.04 virtual machines, installed from a published source-free bundle and checked by separate fresh observations; operator beta in preparation. A prerelease, not a general suite release; 0.1.0-alpha.6 remains the released integration profile.
Constellation is experimental. Its real components have been composed and run end to end, once per qualified profile. The 0.1.0-alpha.6 release records one reviewed, explicitly accepted file change that was authorized once, executed once and then checked by a separate read; anyone can re-verify that evidence from public source. On 2026-10-02 the Alpha 2 showing installed six packages from a published source-free bundle onto two fresh Ubuntu 22.04 virtual machines and started one fixed, previously inactive system service under governance: AG issued one exact one-use authority, Docket kept custody of the single attempt and settled it, NQ on the target independently observed the unit loaded, active and running, and NQ on the controller independently fetched the service’s health endpoint and matched the shipped body hash; Pulse judged current support for exactly those two propositions. Two earlier setup attempts were refused before any authority was issued, and those records are kept. It is a prerelease that shows one scenario; it is not aggregate health, exactly-once execution, clock accuracy or a beta. An earlier Alpha 2 candidate from 2026-09-25, the alpha.6 composition packaged for Debian 12, was qualified but never accepted and is now history. Whoever controls the operator’s host account can still bypass the checks (details). The demo above runs from public source at a tag that is not merged into Docket’s main branch. It is not production-ready.
Who built it
Built by James Beck after 26 years working in operations and reliability, where “the command returned” and “the intended thing happened” are very different facts. More about the work.
Where to go next
- Run the demoA few commands on a fresh Debian 12 machine; about 2 minutes 20 seconds including the build.
- How it worksWhich program owns which decision, and where the trust boundaries are.
- Current statusDated claims, evidence and maturity for each release and component.
- Source and guidesPublic repositories, released profiles and operating guides.
- ResearchPapers on timing, verification lag and stability.
- ABSDA small experimental operating system being built partly to pressure-test these semantics below the application layer.