Verifiable commitments instead of requests

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.

Heimdall began as a guard for an AI agent’s tool calls to external services: HTTP APIs and MCP servers. It judges each call against a declaration of the service. In the layer, the guard’s gateway and proxy act as the delegate. Once a call is allowed, they build the intent, store it, and only then send it to the executor. If the outcome is unknown, they ask the executor for a signed status. Most of our measurements come from studies designed to test that guard. Each page says what its study was designed to test, and only studies of the layer’s own objects or protocol are called layer tests. Refunds are one test domain, chosen because a duplicated or misdirected refund is easy to count; bookings, support tasks, GitHub issues, requirement tracking and document review are others. Neither the guard nor the layer is a payments product.

We publish negative, null and no-advantage results on the same footing as positive ones, each placed with the element it bounds. Several pages report that a lock, a log filter or an ordinary integration kit did as well, or that the harm we set out to measure never occurred. When we find an error in a published result, we correct it in a new version with a dated note and keep the old version readable. The layer was specified and built from mid-October 2026; the guard studies run from August to early November 2026, and the earliest appear as background.