Skip to main content
A soak asks one question, and it is not a performance question: does an AMBIGUOUS outcome ever appear that the harness did not cause? Everything in the run exists to make an unattributed ambiguity visible rather than rare. Here is the one published run. The table is research/soak/results/2026-09-05-postgres-20m.json, rendered.

What that is evidence of

Across 889,735 attempts, every AMBIGUOUS the store held at the end had a ledger entry written before the failure that produced it. Nothing became ambiguous that the harness did not make ambiguous. The positive control fired, so the run was capable of saying otherwise: a short control phase injects an ambiguity it deliberately does not record, and the classifier has to report it. A run whose control did not fire is not a result, and the table says which happened. Unexplained is defined before the run starts, or the question is unfalsifiable. An AMBIGUOUS whose attempt has a recorded injection is explained; one with no corresponding injection is unattributed. It is keyed on the attempt and never on the effect key alone, because one key may be attempted more than once and an injection against the first attempt says nothing about the second.

What it is not evidence of

ROADMAP.md’s exit criterion, which is a soak of at least one week. This ran for 20m 0s. A week of calendar time does not compress, and a larger action count is not a substitute for it: a ten-hour run would meet the criterion no better, it would put a bigger number beside something still unmet. The criterion is recorded in the roadmap as not met, and that is the honest state of it. exit_criterion_met: true in the results file is about the ambiguity count and nothing else. That is all the harness is allowed to decide; the clock is reported and left to a person to read.

What this does not do

  • It is not a load test. The throughput is a by-product, nothing here is tuned for it, and no number on this page is a performance claim.
  • It is not a throughput figure you can plan against. A policy denial writes a receipt like any other outcome, so nearly every attempt above went through the one-row chain head — but on one host, with four threads, against a database on the same machine. Postgres describes that ceiling; this run does not size it for your hardware.
  • It does not exercise a partition or a second host. That is the cross-host suite, and how reservation works says which of those were actually run.
  • It says nothing about the receipt chain’s integrity. Receipt integrity is that.

Run it yourself

Worker threads share one schema, created for the run and dropped after it, and each attempt is drawn from a fixed injection mix — mostly clean, the rest a timeout, an unknown exception, a stated non-execution, or a lease short enough to lapse mid-execution. The mix and the thread count live in the harness rather than here, because a page that restated them would be a second copy nothing compares against: research/soak/README.md has both. Verified by the soak harness’s own suite: an injected ambiguity is explained, one with no injection is a finding, an injection against another attempt explains nothing, and the control cause never explains anything — four tests, and the fourth is what stops the control from absorbing a real finding. T160 covers what an expired lease does and does not free.

Next