# `StatifierBlocks.Compiled`
[🔗](https://github.com/riddler/statifier_blocks/blob/v0.44.1/lib/statifier_blocks/compiled.ex#L1)

What one successful compile produced (ADR-0004 decision 1).

Nothing in here is written back into the document. ADR-0001 decision 2
forbade storing derived data in the document and named the provenance map
specifically. A host stores this artifact beside the document or
recomputes it - both are correct, and decision 6's determinism is what
makes them equivalent.

Decision 1's five fields, and what each is for:

  * `scxml` - the generated bytes. Chart identity hashes exactly these
    (st-ADR-0052), so they are identity-bearing and the serializer that
    wrote them is identity-bearing code.
  * `provenance` - `StatifierBlocks.Provenance`, keyed by state id for
    runtime highlighting and by byte span for routing findings back to
    the block that caused them (decision 5).
  * `record` - `StatifierBlocks.CompilationRecord`, the join between
    document identity and chart identity (decision 7). Given a running
    session, look up by `chart_identity` and get the document, the
    revision, and the map.
  * `invoke_types` - the sorted set of invoke type strings appearing in
    the generated SCXML (decision 8). Published unconditionally, because
    it is a fact about the compile and nothing else. The real fix for the
    two-registry gap is the host comparing this against its
    st-ADR-0051 registration at **deploy time**, when it knows both; this
    field is what makes that a one-liner.
  * `warnings` - findings that did not fail the compile: upstream's own
    warnings (st-ADR-0033) mapped through provenance, and decision 8's
    optional invoke-type lint when the caller asked for it.

One field beside them, from ADR-0014 decision 3:

  * `accepts` - the document's own `accepts` list, exactly as written: the
    names of the external events the document declares it accepts. A
    pass-through the compile reads nothing from and judges nothing about;
    `[]` means the document declares nothing. Whether each name is one the
    chart can take is a host's publish-time question (ADR-0014 decision
    4), asked over `scxml` and this list together.

And one from ADR-0008's amendment of 2026-09-22, A5:

  * `interface` - what this document offers a parent that invokes it,
    and what it relies on from each child it invokes: see
    `t:interface/0`. Recorded on every compile, whatever the chart-use
    option, and a function of the same inputs the SCXML is. It adds
    nothing to the SCXML, so nothing to chart identity, and it is not
    carried onto `StatifierBlocks.CompilationRecord`. The package reads
    it in one place, `StatifierBlocks.Graph`, whose two checks a host's
    publish step calls.

# `child_reference`

```elixir
@type child_reference() :: %{
  :block_id =&gt; StatifierBlocks.Block.id(),
  :document_id =&gt; String.t(),
  :routes_on =&gt; [String.t()],
  :reads =&gt; [String.t()],
  :unresolved =&gt; String.t() | nil,
  optional(:unresolved_reason) =&gt; unresolved_reason(),
  optional(:expanded_from) =&gt; StatifierBlocks.Block.id()
}
```

One block of this document that names another document to run (ADR-0008's
amendment of 2026-09-22, A1's parent side).

  * `block_id` - the referencing block, which a finding about this
    reference is anchored on. For a block a composite's expansion placed,
    the outermost composite block the stored document holds (ADR-0004's
    Amendment of 2026-10-19).
  * `document_id` - the document the block names in its `chart` field.
  * `routes_on` - the child outcomes the block routes on: a
    `core.subchart`'s `outcomes` as
    `StatifierBlocks.Core.Subchart.child_outcomes/1` reads them, so
    `["done"]` when the author listed none. A `core.map` routes on none
    of its child's outcomes, so `[]`.
  * `reads` - the child done-data keys the block reads: the members a
    `core.map`'s `collect_type` marks required, when it resolves to
    members - its inline arm, or a name the compile's `:datamodel`
    declares. A `core.subchart` reads none, so `[]`.
  * `unresolved` - the `collect_type` name, trimmed, of a `core.map` whose
    `collect_type` is a name the compile could not resolve: it was given
    no `:datamodel` (ADR-0008's second amendment of 2026-09-22, U2), or
    the `:datamodel` it was given does not declare the name (ADR-0008's
    Amendment of 2026-10-19, V1). The keys it reads are then unchecked,
    not absent, and `reads` is `[]`. `nil` for the inline arm, an absent
    or blank `collect_type`, a name the supplied `:datamodel` declares and
    every `core.subchart`.
  * `unresolved_reason` - present exactly when `unresolved` is set: which
    of the two it was, `t:unresolved_reason/0`. A reference recorded
    before this key existed and carrying `unresolved` reads as
    `:no_datamodel`, the only case that set `unresolved` then.
  * `expanded_from` - present only on a reference a composite's expansion
    placed: the expanded member's block id, the one the compile emitted
    the `<invoke>` for, which the stored document does not hold. A finding
    about such a reference is anchored on the composite block's chrome
    rather than on a field.

# `interface`

```elixir
@type interface() :: %{
  declared_outcomes: [String.t()],
  declared_donedata_keys: [String.t()],
  references: [child_reference()]
}
```

The document's side of the parent/child interface (A1, A5).

  * `declared_outcomes` - the outcomes the document's root block
    declares: the set a `:child_use` compile gives one top-level
    `<final>` each.
  * `declared_donedata_keys` - the names the root block type's
    `donedata_type/1` declares, which a `:child_use` compile emits as
    `<param>`s.
  * `references` - one `t:child_reference/0` per block that names another
    document, in document pre-order.

# `t`

```elixir
@type t() :: %StatifierBlocks.Compiled{
  accepts: [String.t()],
  interface: interface(),
  invoke_types: [String.t()],
  provenance: StatifierBlocks.Provenance.t(),
  record: StatifierBlocks.CompilationRecord.t(),
  scxml: binary(),
  warnings: [StatifierBlocks.Compiler.Finding.t()]
}
```

# `unresolved_reason`

```elixir
@type unresolved_reason() :: :no_datamodel | :not_declared
```

Why a reference's `collect_type` name is `unresolved` (ADR-0008's
Amendment of 2026-10-19, V1): `:no_datamodel` when the compile was given
no `:datamodel`, `:not_declared` when the one it was given does not
declare the name.

---

*Consult [api-reference.md](api-reference.md) for complete listing*
