How we work

We examine whether independent parties, persons or programs in any domain, can act on each other’s words through signed commitments and check authority, basis and outcome from the records alone. For each element of the layer we ask what a node must verify, test it in code where it is built, and measure on the state of the target system what it prevents and what lawful work it costs. We compare each element with the simplest mechanism that could do the same job, from a lock or an idempotency key to an ordinary integration on existing standards, and report where that mechanism did as well. We state what each study was designed to test before saying what it shows about the layer, report every result whatever its direction, and correct our own record in public.

How sure we are

Every study page says how far its numbers are checked. A working note reports numbers from the study’s own records that no one else has re-opened yet. Re-checked means a second reader inside the project re-opened every number against the primary records. No study has yet been replicated by an outside party, and every page says so. Separately, each part of what Heimdall claims is marked as measured with agents, built and tested in code, or a hypothesis.

What a study was designed to test, and what it bears on

Every page states, in the words of its design, what its study was built to test. Most of our studies were designed to test the single-agent guard; their pages say so and may add one sentence on which element of the layer the result bears on. They are never described as tests of the layer, including the studies in which the layer’s executor ran behind the guard. Only studies that tested the layer’s own objects or protocol are called layer tests. They include the chain test across three executors, the contract-only second checker, the comparison of joining systems through the layer and through ordinary integration, a census of executed work left standing on withdrawn grounds, and a replay of withdrawal on one public dependency graph. The specification itself is published as a design record, and a zero-knowledge cost study as a prototype. The map that links each study to a layer element was drawn after the studies, in November 2026, and was not preregistered.

Kinds of evidence

Each page names its kind; a page that holds two names both, the weightier first. A layer test exercises the layer’s objects or protocol, in its code or, for one replay, on a public dependency graph. A guard study runs live or scripted agents through the guard. A paper comparison scores properties or decisions without running code; the outputs of a cost model are labelled computed, not measured. A documentation reading records what a standard or product documents, dated to the day of reading. A prototype measures one mechanism in code that is not wired to the layer. A design record is a specification or design note with no measurement of its own. A synthesis reads across other pages and has no data of its own; the overview page is one. Method pages cover our instruments, oracles and records.

States of the layer’s elements

Each element of the layer is reported in one of four states, never higher than its evidence. Built and tested: code in the reference implementation with named tests or studies; tested always means tests on simulated services on one machine, never a run between independent organisations. Built: code without its own test for that element, or a research prototype. Specified: normative or informative text, a mapping or a paper comparison, with no code run. Idea: named as later work, with no code. A claim on the overview page also names its basis: measured (a number on system state, from a released page), built, specified or idea.

Preregistration, where used

For the main live series, the hypotheses, measures, sample sizes, exclusion rules and decision rule were written down and committed to the project’s git repository before any counted episode. There is no external registry or timestamp: the authors wrote and accepted their own preregistrations, and some of those commits reached the shared repository only after the series had run. The layer’s own test was written into its specification before any of its code: five criteria under which the layer would count as wrong. A revision loosened two of them, still before the code; the page reports the criteria as revised, and the one that failed. Each page says how its preregistration was made, lists amendments with their dates, and reports deviations. Studies that were not preregistered say so, and post hoc analyses are labelled as such.

Baselines

Comparisons of the guard include an unguarded arm or an ordinary platform. Where we could, we also ran the simplest alternative a reader would propose: a prompt instruction, an idempotency key, a per-object lock, an If-Match precondition, a hand-written wrapper, a declared-dependency check, or a filter applied to the logs after the run. For the layer as a whole, the comparators are an ordinary integration kit written in code on standard primitives (signatures, an idempotency key recorded with the claim of the effect, webhooks with an outbox, a limit service), which also adopts the layer’s conventions for signed status and premises; a shared topic of signed withdrawals built from that kit; a hub, modelled at its best case rather than built; and the best ordinary integration on existing standards, compared on paper. The control in the layer’s chain test bypassed the whole layer, so it isolates no single rule, and the page says so. Where a simple alternative matched the guard or the layer, that is the result. Where none was run, the page names it as a limitation. Comparisons with existing standards and products are documentation readings, dated to the day of reading; we have not run head-to-head comparisons against other products.

Measurement on system state

Harm, completion and correctness are counted from the state of the target system: the provider’s ledger or effect journal, the repository’s git history, a structural checker, or hidden tests. What an agent says it did is not counted as what it did. Measures of agent text (reply coding, judge verdicts) are reported only with their reliability, and keyword screens are not reported as results. In layer tests, effects are counted at the simulated provider’s ledger and, for toy services whose state would hide a repeat, from the executor’s attempts.

By-construction results

Where the guard’s rule forbids an outcome, a zero in the guarded arm follows from the design. We report it as a check that the implementation held under real agents. The empirical findings are the unguarded base rate and the guard’s cost. Scripted agents and scripted acceptors create harm by construction, and the pages say so wherever they appear. The same applies to layer tests: a number that a test asserts, such as the count of agreements per edge, describes the setup and is not reported as a measurement.

Blind judging, where used

When the correctness of written findings is judged, a language-model judge reads only the sources, with the arm and the model hidden. So far these judges come from one model family and have not been calibrated against human experts; the pages state this.

Statistics and scope

Counts are given with their denominators. We use Wilson intervals, Fisher’s exact test and sign tests, and we say when samples are small or when a live condition ran once. A controlled comparison holds “in this setup”: for the stand, models, build and day of that study. The layer’s code tests are deterministic, report pass or fail per case, and ran on one machine, mostly once per configuration.

Records

Each page lists the scripts, manifests and checksums behind its numbers. Run records are published only through an export that removes credentials, tokens and local paths. Where raw data were lost or live outside the repository, the page says so. The layer’s conformance corpora, its second checker and its example network tests can be rerun from the repository at a pinned commit.

Disclosures

The authors build the layer and the guard they measure. Much of the engineering, running and analysis was carried out by AI agents under the authors’ direction; for the layer, AI agents working under that direction wrote the test criteria, the code, the tests, the comparators and the reviews. No outside party has implemented any role of the layer or reviewed it. Reviews of our texts by language-model agents are internal reviews, not independent ones.