Reliability evidence.

What it runs

Every suite runs against a real Actae instance over HTTP. The only simulation is the external "system" in the crash suite — a local file, which is an independent, durable observer of how many times an effect fired.

• crash — a worker is killed with os._exit(137) after a side effect is coordinated through the ledger. The recorded steps survive; resume reconstructs the real step count from the event log and replays the recorded result instead of re-applying the effect.
• fork — a fork replays an inherited effect (auto), refuses a new irreversible one (block, persisted boundary), and stores an intervention descriptor.
• coordination — two live consumers never double-claim an active range; acked work is not redelivered; a lapsed lease's unacked work is redelivered.
• stale_worker / atomicity — stale owners are fenced by their claim token; an atomic transition commits as one unit and replays idempotently.
• soak — an N-way concurrent fork-replay storm resolves every claim to replayed with zero errors, and recovery latency stays flat.

The run writes a machine-readable actae.reliability.v1 report (and a Markdown summary) and exits non-zero if any check fails, so it doubles as a smoke test. CI runs the suite on every push.

Proof, not a promise

Read the committed report — suites, checks, and verdict — and reproduce it on your own hardware and version:

cd actae && cargo run
ACTAE_URL=http://127.0.0.1:8002 ACTAE_API_KEY=... \
  python3 examples/reliability/runner.py

Two load-bearing claims are measured separately, with their raw JSON published: fork fidelity versus a no-fork re-run, and the crash-consistency matrix for external side effects. See benchmark evidence; the harnesses are public and re-runnable at github.com/BViganotti/actae-benchmarks.