# `Runic.Workflow.Definition`
[🔗](https://github.com/zblanco/runic/blob/main/lib/workflow/definition.ex#L1)

Durable construction data for a workflow used as a nested component.

A nested workflow cannot be reconstructed from its name and component
registry alone. Its boundary ports and ordered build events are required to
recreate both the internal graph and the boundary lowering. This struct is
stored inside the parent workflow's `%Runic.Workflow.ComponentAdded{}` event
and can itself contain nested workflow definitions recursively.

Runtime facts, run context, hooks, and runnable state are intentionally not
part of this construction definition.

A workflow is treated as an authored nested boundary when it declares
`input_ports`, `output_ports`, or both. Internal compiler workflows without
boundary ports retain their existing composition behavior.

Output ports with `from: component_name` retain the ownership needed for a
parent to resolve downstream named connections after replay. Contract-only
outputs without `:from` are preserved but are not resolved by inference.

See the [Cheatsheet](cheatsheet.html#nested-workflow-components) and
[Usage Rules](usage-rules.html#prefer-explicit-boundaries-for-reusable-workflows)
for the public construction API. This definition is an internal persistence
contract and is not normally constructed directly.

# `t`

```elixir
@type t() :: %Runic.Workflow.Definition{
  build_log: [struct()],
  hash: term(),
  input_ports: keyword() | nil,
  name: String.t() | atom(),
  output_ports: keyword() | nil,
  version: pos_integer()
}
```

---

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