Runs a corpus case that carries a host object (ADR-0070 decision 5): the host registers the case's send_types (ADR-0069), and the sends handed to it must be the case's expect_sends.

Statifier.Testing.Case.test_scxml/4 starts its session with no registration, so a host case runs here instead, through the same public session API: Statifier.start_session/2 with :send_types naming Mix.Statifier.Corpus.HostCase.Processor for every registered type, Statifier.Session.send_event/2 for each step, with the step's event data, when it gives one, as the injected event's payload, and Statifier.Session.status/1 and Statifier.Session.snapshot/1 to wait for the chart to settle and read its active leaf states. The waiting follows test_scxml/4's: a pending library timer is given a short window to fire before the next event, and a configuration is read once the session has had nothing queued and no timer pending on two consecutive polls, or the chart has left the running status, or a deadline passed.

A case agrees when the active leaf states after initialization and after every step are the ones it expects, and the sends handed to the processor over the whole run, in order, are exactly its expect_sends. Each handed send is written in the case's language-neutral item shape: type, target, event with its name and, when the send carries a payload, its data; delay_ms for a delayed send; and send_id only when the author named the send, which is when the delivered event carries one. A registered delayed send is the host's timer, and this host never fires one.

An expect_sends item may carry an outcome the runner performs or observes for that send (ADR-0070's 2026-09-23 Amendment). With "fail", the runner reports the send handed at that item's position through Statifier.Session.failed_send/3 as soon as it reads the processor's message, before it reads the next configuration, so the step that led to the send is the one whose configuration shows what the sender made of the error.communication it got. With "cancelled", a <cancel> naming the send must reach the processor after it was handed the send: when a cancel reaches the processor, the runner writes "outcome": "cancelled" on each delayed send handed before it under the cancel's send id, generated or not, whose item asks for it, so the comparison above refuses a marked item no cancel reached. An item with no outcome claims nothing about a cancel: a cancel naming its send is not compared.

A host object may also carry declared_events and expect_accepts, present together or not at all (ADR-0071 decision 7). Before it starts the session, the runner calls Statifier.Chart.check_accepts/2 on the compiled chart with declared_events, and the case agrees only when both lists it answers are exactly expect_accepts' unreachable and undeclared, order included. Either key without the other is a disagreement.

A host object may carry a diff pair as well - to_source and expect_diff, with an optional mapping and expect_compatible_at (ADR-0072, conformance/schema/case.json) - and this runner compares none of them: it runs such a case like any other host case. Nothing in lib/ calls the chart diff or the position predicate (ADR-0072 decision 6), so the test suite compares those four keys (test/corpus/diff_cases_test.exs), through run/2's :after_steps option for the position the steps leave.

A step may carry an expect_position (ADR-0076). Once that step's configuration agrees, the runner reads the session's state with Statifier.Session.snapshot/1, renders its export with Mix.Statifier.Corpus.PositionExpectation.render/1, and the case agrees only when the rendering is exactly the step's expect_position. A case that carries one on any step needs every state of its document to carry an id, and disagrees before it starts a session when one has none. The runner hands such a case here even when it carries no host object, as a host that registers nothing.

A host object may carry event_io_processors, the one host key a w3c case may carry (ADR-0075 decision 7): the Event I/O Processor URIs the host runs with a location that reaches the running session. For each one the runner starts a loopback front (Mix.Statifier.BasicHTTPFront) and registers the processor under its URI and its short form with the front's base URL, beside the case's send_types, so every send to it is delivered through the front and none is handed to the recording processor (with_event_io_processors/2). The front is stopped when the case ends. The item set is closed; its one member is the Basic HTTP Event I/O Processor, Statifier.Send.BasicHTTP.

Every wait above is bounded by the wall clock, on purpose. A configuration is read at most four seconds after the step that led to it (@configuration_deadline_ms), a pending library timer gets a window of 100 milliseconds to fire before the next event (@settle_window_ms), and each Statifier.Session.status/1 and Statifier.Session.snapshot/1 call the wait makes carries GenServer.call/2's default timeout of five seconds. The reason is that every case must end with a verdict: a chart that keeps running, or a session that does not answer, would otherwise hold the corpus stage open, so the runner bounds the wait by the clock rather than waiting on the session, and the bounds sit far above what a committed case takes on an idle machine. The cost is that a session held longer than a bound makes the case fail whatever its document does: a session inside a Basic HTTP POST, which the default transport bounds at five seconds of its own (Statifier.Send.BasicHTTP.Transport.Httpc), can outlast the deadline and leave a stale configuration to compare, or outlast a call's timeout and exit the runner. Such a failure under heavy load is the machine's, not the case's; running the case again on an idle machine tells the two apart.