The fourth arrow of the parser pipeline: a validated %Statifier.Document{} in, {:ok, %Statifier.Machine{}} | {:error, [Statifier.Compiler.Error.t()]} out (docs/architecture.md:47-51). Nothing downstream of this pass ever sees a %Statifier.Document{} again - the interpreter accepts only a Machine (docs/architecture.md principle 4).

This phase interns every state to a flat, document-order tuple with parent pointers and self-inclusive descendant ranges (ADR-0005), resolves every initial to indexes, compiles every <transition> element - including an <initial> element's own transition and a :history state's default - into Statifier.Machine.Transition via its own transition pass, and compiles every executable-content node reachable through onentry, onexit, or a transition's own content into Statifier.Machine.Content, plus every :final state's <donedata> into Statifier.Machine.Donedata, via its own executable-content pass.

One walk, not two (states); a real second pass (transitions, content,

donedata)

The "numbering walk" and "reference resolution" are, for initial specifically, one traversal rather than two: a state's initial can only legally name a descendant of that state (validator checks 3 and 7), and descendants are always finished - numbered, and their own ids entered into id_to_index - before their ancestor is, because this walk is post-order on the way out of each subtree. So id_to_index already holds every id resolve_initial/3 could legally need by the time it runs, and resolving inline avoids threading the raw Statifier.Document.State tree through a second pass just to re-ask questions the first pass already had the answer to.

Transition target resolution cannot make the same move: a transition's target is not constrained to be a descendant of its source, so it can be a forward reference to a state the walk has not reached yet (id_to_index incomplete at the point the transition is visited). t_index and c_index assignment themselves are done inline, in the same walk that numbers states - each state's own <onentry>/<onexit> content, then its own transitions (its plain transitions, then its <initial> element's transition, in that order - :history's own transitions are its default) and each transition's own content, are assigned dense index values the moment the state itself is visited, before the walk descends into that state's children - mirroring how the state's own index is assigned before its children are numbered, and matching the source's own onentry*, onexit*, transition*, initial? element order (spec 3.3-3.9). That is enough to keep every t_index/c_index dense and correctly interleaved in document order without a second walk. What genuinely waits for the whole walk to finish is turning each transition's raw target id list into resolved indexes and compiling every expression (a transition's cond, a <log expr=...>, a <content>'s folded value) - all of that needs either the complete id_to_index or nothing but the raw node itself, so build_transitions/3, build_contents/2, build_donedata_map/1, and build_data_elements/2 each run once, after walk_siblings/4 returns. The first three's errors accumulate together, sorted by location.start_offset, mirroring Statifier.Lowering.finalize/2 (lib/statifier/lowering.ex:137-141) - a document with a bad cond on one transition and a bad <log expr=...> elsewhere reports both. build_data_elements/2 never joins that merge - a <data expr> that fails to compile is captured onto the compiled Statifier.Machine.Data node as {:invalid, error} rather than failing compile/1, so a document with a bad cond and a bad <data expr> reports only the cond's error.

<data> gets its own dense index space, d_index, assigned the same way t_index/c_index are: a state's own <datamodel>'s <data> children are assigned the moment the state itself is visited, before the walk descends into its children (assign_data/3). The root's own top-level <datamodel> is assigned before walk_siblings/4 is first called, so top-level <data> occupy d_index 0..n-1, preceding every state-scoped one.

All of the walk's mutable state - id_to_index, the states accumulator, the next unused t_index/c_index/d_index, the transitions/contents/donedata/data accumulators - travels together as one acc() map, rather than as seven-plus positional arguments: Credo.Check.Refactor.FunctionArity's limit is 8, and a numbering walk that also assigns c_index and d_index genuinely needs more independent pieces of state than that once each is its own argument.