The commitment layer
Verifiable commitments instead of requests. Independent systems check signed grants, facts and outcomes of earlier actions, instead of trusting what an agent says it was allowed to do or what it says happened.
- Principal. Signs a grant: what is allowed.
- Source. Signs a fact: what is true.
- Delegate. Cites the grant and the fact, and sends one intent.
- Executor. Makes the effect at most once, and answers with a signed outcome or an honest unknown.
- Next executor. Acts on that outcome.
- Log. Keeps outcomes and withdrawals in order.
- Watcher. Finds actions that rest on a withdrawn grant or fact.
What it checks
| Check | Studies |
|---|---|
| Signed statements anyone can check | 2 published |
| Executors that act on each other's outcomes | 1 not yet published |
| Withdrawal through a log | 2 not yet published |
| Showing a record without revealing it | 1 published |
| Against ordinary integration | 6 not yet published |
| Guard and layer together | 1 published, 1 not yet published |
Heimdall Research examines one idea: that independent parties can act on verifiable commitments instead of requests. Each commitment is signed and cites what it rests on, so anyone holding the records can check who allowed an action, what it rested on and what happened. A principal states what is allowed in a signed grant, and a source states what is true in a signed fact. A delegate asks one executor to act and cites both. The executor alone makes the effect, keeps at most one effect per intent, and answers with a signed outcome. When it cannot tell whether the effect happened, it says so in a signed status rather than reporting that nothing happened. If the principal or the source later withdraws the grant or the fact, the withdrawal goes into a log. An executor that follows the log refuses new actions that rest on it. An effect already made is never undone, but anyone who reads the log can find it and check it again.
The parties may be persons or programs, and the layer does not ask which. Conversation between them stays free; only the step where words become actions is formal. Software agents, AI agents among them, make that step frequent and fast, which is why the question is pressing now. We put it this way in October 2026: is there a universal layer whose unit is a verifiable commitment instead of a request?
The layer exists as a reference implementation with written contracts. Its statement format, the executor’s contract, chains of executors that act on each other’s outcomes, and withdrawal through a log are built and tested. So is a steward that signs one reserve per intent, so that one limit holds across several executors under a shared anchor. A second checker, written inside the project by an agent working from the English contract alone, accepted and refused the same bytes as the reference on every reviewed case. A chain across three simulated domains held five injected faults without a second effect. Tested means, here and throughout, tested in code on one machine against simulated services: two in-memory services, for bookings and support tasks, and a payment-provider simulator. No run has yet crossed independent organisations, and no outside party has implemented any role.
Signed statements anyone can check
Grants, facts, intents and outcomes share one signed format, and a checker accepts or refuses each statement from its bytes, a key map and a trust policy.
2 published: 1 prediction held, 1 measurement; 1 re-checked.
Executors that act on each other's outcomes
An executor makes an effect at most once per intent and answers with a signed outcome or an honest unknown; the next executor acts on that outcome.
1 study, not yet published.
Withdrawal through a log
When a grant or a fact is withdrawn, the log carries it to every executor that follows it: new actions resting on it are refused, and effects already made can be found.
2 studies, not yet published.
Showing a record without revealing it
A proof that a sealed record rests on a withdrawn premise, without revealing which premise.
1 published: 1 measurement; 1 re-checked.
Against ordinary integration
The layer compared with an ordinary integration kit on standard primitives, a shared topic of signed withdrawals, a hub, and the best integration existing standards allow.
6 studies, not yet published.
Guard and layer together
The guard acting as the layer's delegate, and both running as one mechanism across organisations.
1 published: 1 mixed result; 1 re-checked.
And 1 more study, not yet published.
Next tests
- An executor written from the contract alone by someone who did not write the layer, checked against the reference over HTTP.
- What the same-action fence adds on its own, against simple keys, a lock and an ordinary integration kit.
- A tool for principals to sign grants, and a chain of grants across two organisations.
- Signed observations from real services in test mode, instead of the executor standing in as the source.
- Cosigned log heads, and how far a withdrawal reaches when timing is random.
- Joins between systems by people who did not write the layer, then a pair of outside adopters.
- One limit shared by several executors, against a limit service.
- Key rotation, and facts that state a key's status.
- An honest unknown at the agent-protocol boundary, when the answer to a tool call is lost.
- Whether an action should have to cite a current requirement, or a complete set of them.
- Showing only what a check needs, and nothing else from the record.
- What the principal meant, when an agent is misled about its task, with and without a signed grant.