@spec answer_parent(
  driver :: t(),
  child_execution_id :: StatifierPersistence.Executions.execution_id(),
  donedata_or_failure :: {:done, term()} | {:failed, keyword()}
) ::
  result() | :ok | :no_parent | {:error, StatifierPersistence.Storage.error()}

Answers child_execution_id's parent with its completion or permanent failure (ADR-0008 decision 3) - a separate drive under the parent's own exclusion, driver.machine must be the parent's chart.

donedata_or_failure is {:done, donedata} or {:failed, failure}. Reads child_execution_id's own linkage through parent_link/2 first: :no_parent is a no-op answering :no_parent, so this is safe to call on any execution id, linked or not.

A child of a fan-out answers no parent here. Its linkage carries a child_count, so this call settles instead - records the child's own answer and, if it is the last, assembles the invocation's dense list and answers the parent's door once - and returns :ok. The routing is here and not only on the automatic path because a host driving the doors itself must not be able to bypass a settlement by calling this function: answering a fan-out's parent with one child's donedata would complete the whole map block on the first child to finish.

Public so a host with no chart_resolver: can call it explicitly with a driver built over the parent's own chart - the same construction the automatic path (wired into create/3, send_event/4, done_invocation/5 and failed_invocation/5) uses once its chart_resolver: has resolved one. The parent's answer is done_invocation/5 or failed_invocation/5 under the parent's own exclusion: a parent that has already cancelled the invocation answers {:discarded, _} here, which is ADR-0007 decision 3's mechanism doing its job, not an error.

@spec create(
  driver :: t(),
  execution_id :: StatifierPersistence.Executions.execution_id(),
  opts :: keyword()
) :: result()

Creates the execution under execution_id and drives it to quiescence.

StatifierPersistence.Executions.create/4 with this driver's executor, then the answer loop. opts takes everything create/4 takes except executor:, which this module supplies - initialize:, metadata:, routes:, and per-call overrides of the driver's own invoke_types: and serialization:.

@spec done_invocation(
  driver :: t(),
  execution_id :: StatifierPersistence.Executions.execution_id(),
  invoke_id :: String.t(),
  donedata :: term(),
  opts :: keyword()
) :: result()

Answers a :pending invocation with donedata and drives the execution to quiescence.

Statifier.Session.done_invocation/3's door on the durable path: it builds the same done.invoke.<invoke_id> event, from the execution's own persisted _sessionid, and steps it. invoke_id is the <invoke> element's id - the invoke_id :dispatch was handed in its dispatch_context/0.

Answering an invocation the chart has since cancelled is {:discarded, execution}, spec 6.4.3's discard, decided from the loaded position inside the execution's serialization strategy (the moduledoc's cancel-versus-completion section). So is answering a terminal execution.

The answer can re-arm calls of its own; they are dispatched and driven exactly as send_event/4 drives them, :pending included.

opts takes what send_event/4 takes.

@spec failed_invocation(
  driver :: t(),
  execution_id :: StatifierPersistence.Executions.execution_id(),
  invoke_id :: String.t(),
  failure :: keyword(),
  opts :: keyword()
) :: result()

done_invocation/5's failing counterpart: answers a :pending invocation with a permanent failure and drives the execution to quiescence.

Statifier.Session.failed_invocation/3's door on the durable path, building the same error.communication.invoke.<invoke_id> event from st-ADR-0068's failure keyword list (:reason, :attempts, :detail). Permanent in that record's sense: the host's retry policy is exhausted and no done.invoke will follow. A transient failure is the host's to retry before answering, not something to report to the chart.

Discards, re-armed calls and opts are done_invocation/5's.

@spec new(
  store :: StatifierPersistence.Storage.t(),
  machine :: Statifier.Machine.t(),
  opts :: keyword()
) :: t()

Builds a driver over store and machine.

opts:

• dispatch: (required) - the dispatch/0 fun every <invoke> is performed through.
• effects: - a StatifierPersistence.Executor.t/0 handed every non-lifecycle effect before the invoke dispatch, for the effects the host observes or persists itself (a <send delay=...> becoming a durable timer, a trace becoming a feed row). Defaults to nil, "the host wants none of them"; an {:error, reason} from it re-enters the chart as error.communication exactly as it does through StatifierPersistence.Executions directly.
• invoke_types: - the Statifier.Invoke.Types.t/0 snapshot stamped on every step. A driver-level default rather than a per-call one because the registered set is fixed for a session's lifetime (st-ADR-0051); routes:, which is not, stays per call. Defaults to nil, "the built-in set only".
• serialization: - the {module, config} per-execution strategy every entry point runs inside (ADR-0004 decision 5). Defaults to whatever StatifierPersistence.Executions defaults to, the adapter's own lock_execution/3.
• chart_resolver: - chart_resolver/0, how this driver reaches a chart it does not hold: (content_hash -> {:ok, Statifier.Machine.t()} | :error). It exists for exactly one purpose - answering a durable subchart's parent, whose chart is not this driver's machine (ADR-0008 decision 3). This package cannot supply it: a stored chart_blob is opaque by ADR-0003 decision 1 and nothing here decodes one, so the host that saved the chart is the only party that can compile it. Defaults to nil, "this driver answers no parents" - a host without one calls done_invocation/5 or failed_invocation/5 itself, from parent_link/2 and the drive's own execution.donedata or execution.failure.
• child_canceller: - child_canceller/0, how a :first_error settlement reaches the scheduler holding the start jobs of a fan-out's not-yet-started children. Defaults to nil, "this driver cancels no start jobs".
• after_step: - after_step/0, called after_step.(execution_id, machine_state, effects) after every step this driver takes on a caller's behalf, so a host keeping its own record of what an execution did can append the steps it never made itself: a durable subchart child's own steps, and the parent's step on the answer path (ADR-0008 decision 3 and the driver: option on StatifierPersistence.Executions.fail/4), neither of which the drive's return value reports. The execution id is always the execution that was stepped - the parent's, on the answer path. It fires after that step's persist, in the order the steps happened, and outside the exclusion of the execution it reports; a step that was discarded, and a cascade_cancel, step nothing and fire nothing. Its return is ignored and a raise inside it propagates (the 2026-09-08 amendment's clauses 3 to 5, which also say why this is not ADR-0009's telemetry). Defaults to nil, "this driver reports no steps".
• max_turns: - the answer-fed steps one drive will take before refusing to take another. Defaults to 1000.

Every one of these except dispatch: may be overridden per call by passing the same key in a create/3 or send_event/4 opts list.

@spec parent_link(
  store :: StatifierPersistence.Storage.t(),
  execution_id :: StatifierPersistence.Executions.execution_id()
) ::
  {:ok, StatifierPersistence.Execution.Linkage.t()}
  | :no_parent
  | {:error, StatifierPersistence.Storage.error()}

The "find my parent" query: reads execution_id's own stored linkage, one key read off its fetched record (StatifierPersistence.Execution.Linkage, ADR-0008 decision 2).

:no_parent for an execution with no linkage - an ordinary execution, or a durable subchart child that has none for whatever reason - not a failure: having no parent is an ordinary property of an execution.

@spec resolve_and_answer_parent(
  driver :: t(),
  child_execution_id :: StatifierPersistence.Executions.execution_id(),
  donedata_or_failure :: {:done, term()} | {:failed, keyword()}
) :: :ok

answer_parent/3 with the parent's chart resolved first, and the same answer whatever happens: :ok.

This is the public form of what the automatic path does once a drive of the child has left it terminal - resolve the parent's chart through chart_resolver:, then answer through answer_parent/3 with a driver over that chart - and it exists because a caller outside a drive needs the same two steps. StatifierPersistence.Executions.fail/4's driver: option is that caller (ADR-0008's outside-fail note): an execution failed from outside the interpreter has no drive to hang the answer off, so it calls here.

A driver with no chart_resolver: answers through answer_parent/3 directly, on driver.machine - that function's own contract, where the driver was built over the parent's chart by the caller. The automatic path deliberately does not do this: it is entered from a drive of the child, so its driver.machine is the child's chart and answering with it would step the parent against the wrong chart. Here the caller chose the driver, so the choice is theirs to make.

Never raises for an execution with no parent and never reports a storage error: :no_parent and a failed fetch are both :ok, exactly as the automatic path treats them. A caller that needs the answer's own result calls answer_parent/3.

@spec send_event(
  driver :: t(),
  execution_id :: StatifierPersistence.Executions.execution_id(),
  event :: Statifier.Event.t(),
  opts :: keyword()
) :: result()

Delivers one external event to the execution under execution_id and drives it to quiescence.

StatifierPersistence.Executions.step/5 with this driver's executor, then the answer loop. An event delivered to a terminal execution is that function's own {:discarded, execution}, before any position decode and before any dispatch.

@spec start_child_at(
  driver :: t(),
  parent_execution_id :: StatifierPersistence.Executions.execution_id(),
  effect ::
    Statifier.Effect.Invoke.t()
    | {:start_child, Statifier.Effect.Invoke.t(),
       {:invoke, Statifier.Effect.Invoke.t()}},
  index :: non_neg_integer(),
  count :: pos_integer(),
  opts :: [{:policy, StatifierPersistence.Execution.Linkage.policy()}]
) :: :ok | {:refused, term()}

Starts child index of count for parent_execution_id's <invoke> - the public start-with-index door a scheduler drives a fan-out through (sp-t57, ruling C4; mirrors sob-q3y).

The single-child durable-subchart path creates its child from inside the parent's own step, because there is exactly one and the parent is already exclusive. A fan-out cannot: N children created inside the parent's step would hold the parent's exclusion for N creates. So the parent's step enqueues the fan-out instead, and each child is created later, from whatever job picks it up, through this function. That is the reading of statifier_blocks ADR-0008 decision 4 the fan-out needs: what happens under the parent's exclusion is the enqueue, and the children are created afterwards, idempotently and resumably.

Idempotent, and that is what makes it resumable: the child's execution id is StatifierPersistence.Execution.Linkage.child_execution_id/3 of the same three values, so a re-delivered start job finds the child it already created and adopts it rather than creating a second one - exactly as the single-child path's at-least-once re-drive does.

Arguments

• driver - any driver over the right store. Its machine is not read: the child's chart comes from effect, and the parent's comes from the chart_resolver: when the settlement answers.
• parent_execution_id - the execution whose <invoke> this fans out.
• effect - the resolved Statifier.Effect.Invoke.t/0, or the whole {:start_child, resolved, {:invoke, invoke}} instruction a subchart handler answers with. The invocation id is read off it, so a caller passes no id separately.
• index - the child's 0-based position in the list being mapped over.
• count - N, recorded on every child so a settlement knows how many to wait for.
• opts - policy: (:all, the default, or :first_error).

index outside 0..count - 1 raises ArgumentError - a caller bug, not a storage event. The check is StatifierPersistence.Execution.Linkage.new/6's, which is the one definition site of the linkage's own shape; this function does not repeat it.

Refusals

{:refused, reason}, the same shape and the same telemetry the single-child path's refusal at open uses, with three added arms. An adapter that cannot enumerate children refuses :child_listing_unsupported as it always has; one that cannot store an execution's outcome payload refuses :execution_outcome_unsupported, and one that cannot answer the indexed status projection refuses :execution_states_unsupported. All three are the same principle: a child whose invocation could never be settled is not started. A parent_execution_id naming no stored execution refuses :execution_not_found.