Creates an %Accumulator{}: maintains cumulative state across individual inputs.

Unlike reduce/3 which aggregates over collections, accumulators process single values and maintain running state across multiple workflow invocations. This makes them ideal for running totals, counters, and stateful computations.

Basic Usage

iex> require Runic
iex> alias Runic.Workflow
iex> acc = Runic.accumulator(0, fn x, state -> state + x end, name: :running_sum)
iex> workflow = Workflow.new() |> Workflow.add(acc)
iex> results = workflow |> Workflow.plan_eagerly(5) |> Workflow.react_until_satisfied() |> Workflow.raw_productions()
iex> 5 in results
true

Options

• :name - Identifier for the accumulator (useful for referencing in rules)
• :inputs / :outputs - Reserved for future schema-based type compatibility

Difference from Reduce

Building State Machines

Connect rules to accumulators to create state-machine-like behavior:

require Runic
alias Runic.Workflow

counter = Runic.accumulator(0, fn x, acc -> acc + x end, name: :counter)
threshold_rule = Runic.rule(
  condition: fn {state, _input} -> state > 100 end,
  reaction: fn _ -> :threshold_exceeded end
)

Captured Variables

iex> require Runic
iex> alias Runic.Workflow
iex> multiplier = 2
iex> acc = Runic.accumulator(0, fn x, state -> state + x * ^multiplier end, name: :scaled_sum)
iex> acc.closure.bindings[:multiplier]
2

Creates an %Aggregate{}: a CQRS/ES aggregate that validates commands against current state, produces domain events, and folds events into state.

Compiles to an Accumulator (event fold) plus Rules (command handlers).

Usage

require Runic

agg = Runic.aggregate name: :counter do
  state 0

  command :increment do
    emit fn _state -> {:incremented, 1} end
  end

  command :decrement do
    where fn state -> state > 0 end
    emit fn _state -> {:decremented, 1} end
  end

  event {:incremented, n}, state do
    state + n
  end

  event {:decremented, n}, state do
    state - n
  end
end

Options

• :name - Identifier for the aggregate (required)

DSL

• state initial_value - Sets the initial aggregate state
• command :name do ... end - Defines a command handler
  • where fn state -> bool end - Optional guard on current state
  • emit fn state -> event end - Produces domain events
• event pattern, state_var do body end - Defines an event handler (reducer clause)

Returns a list of all %Fact{} structs produced by a component across all invocations.

Unlike all_values_of/1, this returns full %Fact{} structs with metadata.

Examples

require Runic

Runic.rule name: :multi_fact_check do
  given(x: x)
  where(length(all_facts_of(:events)) > 0)
  then(fn %{x: x} -> {:has_events, x} end)
end

Returns a list of all raw values produced by a component across all invocations.

Useful for aggregation in where or then clauses, e.g. summing all scores.

Examples

In a where clause:

require Runic

Runic.rule name: :sum_check do
  given(x: x)
  where(Enum.sum(all_values_of(:scores)) > 100)
  then(fn %{x: x} -> {:high_score, x} end)
end

In a then clause:

require Runic

Runic.rule name: :sum_all_scores do
  given(x: _x)
  then(fn _bindings -> Enum.sum(all_values_of(:scores)) end)
end

Creates a %Condition{}: a standalone conditional expression.

Conditions represent the left-hand side (predicate) of a rule. They can be reused across multiple rules when the same condition is expensive or shared.

Basic Usage

iex> require Runic
iex> cond = Runic.condition(fn x -> x > 10 end)
iex> cond.work.(15)
true
iex> cond.work.(5)
false

With Module Function Capture

iex> require Runic
iex> cond = Runic.condition({Kernel, :is_integer, 1})
iex> cond.work.(42)
true

With Name Option

iex> require Runic
iex> cond = Runic.condition(fn x -> x > 10 end, name: :big_number)
iex> cond.name
:big_number

Captured Variables with ^

Use the pin operator ^ to capture outer scope variables:

iex> require Runic
iex> threshold = 10
iex> cond = Runic.condition(fn x -> x > ^threshold end)
iex> cond.closure.bindings[:threshold]
10
iex> cond.work.(15)
true

Use Cases

• Expensive checks: When a condition involves costly operations (e.g., API calls, database queries), define it once and reference it in multiple rules
• Stateful conditions: Use state_of/1 to create conditions that depend on accumulator or state machine state
• Reusability: Share predicates across rules for consistency

Note: Conditions should be pure and deterministic - they should not execute side effects.

References an external runtime value by key inside Runic macros.

Used inside step, condition, rule, accumulator, map, and reduce macros to declare a dependency on a value provided via Workflow.put_run_context/2 or the :run_context option on react_until_satisfied/3.

Values are scoped by component name and resolved during the prepare phase. The _global key in run_context is merged into every component's context.

Resolves to nil when the key is not present in run_context. Use context/2 to provide a default instead.

Examples

require Runic
alias Runic.Workflow

step = Runic.step(fn _x -> context(:api_key) end, name: :call_llm)

rule =
  Runic.rule name: :gated do
    given(val: v)
    where(v > context(:threshold))
    then(fn %{val: v} -> {:ok, v} end)
  end

acc = Runic.accumulator(0, fn x, s -> s + x * context(:factor) end, name: :scaled)

workflow =
  Workflow.new()
  |> Workflow.add(step)
  |> Workflow.put_run_context(%{call_llm: %{api_key: "sk-..."}})

Dot access is supported for map-valued context keys:

Runic.step(fn x -> x + context(:config).pool_size end, name: :pooled)

References an external runtime value by key with a default fallback.

Behaves like context/1 but uses the provided default when the key is not present in run_context. The default can be a literal value or a zero-arity function that is called lazily when needed.

Keys with defaults are not reported as missing by Workflow.validate_run_context/2 and appear as {:optional, default} in Workflow.required_context_keys/1.

Defaults are embedded in the compiled closure and participate in content hashing — two components with different defaults produce different hashes.

Examples

require Runic

# Literal default
step = Runic.step(fn _x -> context(:model, default: "gpt-4") end, name: :call_llm)

# Function default — called lazily when key is missing
step = Runic.step(
  fn _x -> context(:api_key, default: fn -> System.get_env("API_KEY") end) end,
  name: :call_llm
)

# In rule where clauses
rule =
  Runic.rule name: :default_rule do
    given(val: v)
    where(v > context(:threshold, default: 100))
    then(fn %{val: v} -> {:over, v} end)
  end

# In accumulator reducers
acc = Runic.accumulator(0, fn x, s -> s + x * context(:factor, default: 1) end,
  name: :scaled
)

Returns the number of facts produced by a given component in the workflow.

Used inside where clauses of rules to gate on how many facts a component has produced.

Examples

require Runic

Runic.rule name: :batch_ready do
  given(x: x)
  where(fact_count(:items) >= 3)
  then(fn %{x: x} -> {:process_batch, x} end)
end

Creates a %FSM{}: a finite state machine with discrete states and guarded transitions.

FSMs compile to an Accumulator (holding the current state atom) plus Rules (one per transition, using state_of() to gate on current state). Entry actions are additional rules that fire on state changes.

Example

require Runic

fsm = Runic.fsm name: :traffic_light do
  initial_state :red

  state :red do
    on :timer, to: :green
    on :emergency, to: :red
    on_entry fn -> {:notify, :traffic_stopped} end
  end

  state :green do
    on :timer, to: :yellow
    on :emergency, to: :red
  end

  state :yellow do
    on :timer, to: :red
    on :emergency, to: :red
  end
end

Each transition compiles to a named Rule: :"fsm_name_from_state_on_event".

Returns the most recent %Fact{} struct produced by a component.

Unlike latest_value_of/1, this returns the full %Fact{} struct including metadata such as hash and ancestry, not just the raw value.

Examples

require Runic

Runic.rule name: :check_latest_fact do
  given(x: x)
  where(latest_fact_of(:processor) != nil)
  then(fn %{x: x} -> {:ok, x} end)
end

Returns the most recent raw value produced by a component.

Useful in where clauses to compare against the latest output, or in then clauses to incorporate another component's latest result.

Examples

In a where clause:

require Runic

Runic.rule name: :high_temp_alert do
  given(x: x)
  where(latest_value_of(:sensor) > 100)
  then(fn %{x: x} -> {:alert, x} end)
end

In a then clause:

require Runic

Runic.rule name: :echo_latest do
  given(x: x)
  then(fn %{x: x} -> {:latest, x, latest_value_of(:sensor)} end)
end

Creates a %Map{}: applies a transformation to each element of an enumerable.

Map operations fan-out an enumerable input into individual elements, apply the transformation to each, and can be followed by a reduce to fan-in results.

Basic Usage

iex> require Runic
iex> alias Runic.Workflow
iex> map_op = Runic.map(fn x -> x * 2 end, name: :double)
iex> workflow = Workflow.new() |> Workflow.add(map_op)
iex> results = workflow |> Workflow.plan_eagerly([1, 2, 3]) |> Workflow.react_until_satisfied() |> Workflow.raw_productions()
iex> Enum.sort(results)
[2, 4, 6]

Options

• :name - Identifier for referencing in reduce/3 via :map option
• :inputs / :outputs - Reserved for future schema-based type compatibility

With Pipeline

Map can contain nested pipelines:

require Runic

Runic.map(
  {Runic.step(fn x -> x * 2 end, name: :double),
   [Runic.step(fn x -> x + 1 end, name: :add_one)]}
)

Map-Reduce Pattern

Connect a reduce to collect mapped results. The reduce's :map option links it to the upstream map:

iex> require Runic
iex> alias Runic.Workflow
iex> map_op = Runic.map(fn x -> x * 2 end, name: :double)
iex> reduce_op = Runic.reduce(0, fn x, acc -> x + acc end, name: :sum, map: :double)
iex> workflow = Workflow.new()
...>   |> Workflow.add(map_op)
...>   |> Workflow.add(reduce_op, to: :double)
iex> results = workflow
...>   |> Workflow.plan_eagerly([1, 2, 3])
...>   |> Workflow.react_until_satisfied()
...>   |> Workflow.raw_productions(:sum)
iex> 12 in results
true

How It Works

Internally, map uses a FanOut component that splits the enumerable into individual facts. Each element is processed independently, enabling parallel execution with the :async option on react/2.

Creates a %ProcessManager{}: a CQRS-oriented process manager that reacts to domain events, maintains coordination state, and emits commands.

Unlike Saga, ProcessManagers are event-driven and reactive rather than sequential. They subscribe to event patterns from multiple sources and decide what commands to issue based on accumulated state.

Compiles to an Accumulator (coordination state) plus Rules (event handlers).

Example

require Runic

pm = Runic.process_manager name: :fulfillment do
  state %{order_id: nil, paid: false, shipped: false}

  on {:order_submitted, order_id} do
    update %{order_id: order_id}
    emit {:charge_payment, order_id}
  end

  on {:payment_received, _} do
    update %{paid: true}
  end

  on {:shipment_created, _} do
    update %{shipped: true}
  end

  complete? fn state -> state.shipped end
end

DSL

• state initial_value - Sets the initial process manager state
• on event_pattern do ... end - Defines an event handler
  • update map - Merges updates into the process state
  • emit value - Produces a command fact as output
• complete? fn state -> bool end - Completion check (fires when state satisfies predicate)
• timeout :name, duration do ... end - Declares a timeout (scheduling is the Runner's responsibility)

Options

• :name - Identifier for the process manager (required)

Creates a %Reduce{}: aggregates multiple facts into a single accumulated result.

Reduce operations fan-in results from a map operation or process an enumerable from a parent step. Unlike accumulator/3 which processes single values cumulatively, reduce/3 aggregates over collections.

Basic Usage

Like Enum.reduce/3, process an enumerable from a parent step:

require Runic
alias Runic.Workflow

workflow = Runic.workflow(
  name: :sum_range,
  steps: [
    {Runic.step(fn -> [1, 2, 3, 4, 5] end, name: :generate),
     [Runic.reduce(0, fn x, acc -> x + acc end, name: :sum)]}
  ]
)

Options

• :name - Identifier for the reduce component
• :map - Name of an upstream map component for fan-in (lazy evaluation)
• :inputs / :outputs - Reserved for future schema-based type compatibility

Map-Reduce Pattern (Lazy Evaluation)

When :map is specified, reduce waits for all mapped elements before aggregating. This enables lazy/parallel execution of the map phase:

iex> require Runic
iex> alias Runic.Workflow
iex> map_op = Runic.map(fn x -> x * 2 end, name: :double)
iex> reduce_op = Runic.reduce(0, fn x, acc -> x + acc end, name: :sum, map: :double)
iex> workflow = Workflow.new()
...>   |> Workflow.add(map_op)
...>   |> Workflow.add(reduce_op, to: :double)
iex> results = workflow
...>   |> Workflow.plan_eagerly([1, 2, 3])
...>   |> Workflow.react_until_satisfied()
...>   |> Workflow.raw_productions(:sum)
iex> 12 in results
true

Nested Pipeline with Reduce

Reduce can follow a pipeline after the map:

require Runic

Runic.workflow(
  steps: [
    {Runic.map(fn x -> x * 2 end, name: :double),
     [{Runic.step(fn x -> x + 1 end, name: :add_one),
       [Runic.reduce(0, fn x, acc -> x + acc end, name: :sum, map: :double)]}]}
  ]
)

Important Notes

• Reduce operations are inherently sequential and cannot be parallelized unless your reducer has CRDT (commutative) properties
• Without :map, reduce processes the enumerable eagerly in one invocation
• With :map, reduce waits for all fan-out elements before reducing

Creates a %Rule{}: a conditional reaction for pattern-matched execution.

Rules have two phases: a condition (left-hand side) that must match, and a reaction (right-hand side) that executes when matched. This separation enables efficient evaluation of many rules together.

Basic Usage

iex> require Runic
iex> alias Runic.Workflow.Rule
iex> rule = Runic.rule(fn x when is_integer(x) and x > 0 -> :positive end)
iex> Rule.check(rule, 5)
true
iex> Rule.check(rule, -1)
false
iex> Rule.run(rule, 5)
:positive

Guard Clauses

Rules support full Elixir guard expressions:

iex> require Runic
iex> alias Runic.Workflow.Rule
iex> rule = Runic.rule(fn x when is_binary(x) and byte_size(x) > 5 -> :long_string end)
iex> Rule.check(rule, "hello!")
true
iex> Rule.check(rule, "hi")
false

Pattern Matching

iex> require Runic
iex> alias Runic.Workflow.Rule
iex> rule = Runic.rule(fn %{status: :pending} -> :process end)
iex> Rule.check(rule, %{status: :pending, id: 1})
true
iex> Rule.check(rule, %{status: :done})
false

Separated Condition and Reaction

For expensive conditions shared by multiple rules, or clearer organization:

iex> require Runic
iex> alias Runic.Workflow.Rule
iex> rule = Runic.rule(
...>   name: :expensive_check,
...>   condition: fn x -> rem(x, 2) == 0 end,
...>   reaction: fn x -> x * 2 end
...> )
iex> Rule.check(rule, 4)
true
iex> Rule.run(rule, 4)
8

Also supports :if / :do aliases:

Runic.rule(
  name: :my_rule,
  if: fn x -> x > 10 end,
  do: fn x -> :large end
)

Multi-Arity Rules

Rules can require multiple inputs (provided as a list):

iex> require Runic
iex> alias Runic.Workflow.Rule
iex> rule = Runic.rule(fn a, b when is_integer(a) and is_integer(b) -> a + b end)
iex> Rule.check(rule, [3, 4])
true
iex> Rule.run(rule, [3, 4])
7

In Workflows

Rules are evaluated in the planning/match phase before execution:

iex> require Runic
iex> alias Runic.Workflow
iex> workflow = Runic.workflow(
...>   name: :classifier,
...>   rules: [
...>     Runic.rule(fn x when x > 100 -> :xlarge end, name: :xlarge),
...>     Runic.rule(fn x when x > 10 and x <= 100 -> :large end, name: :large),
...>     Runic.rule(fn x when x > 0 and x <= 10 -> :small end, name: :small)
...>   ]
...> )
iex> workflow |> Workflow.plan_eagerly(50) |> Workflow.react_until_satisfied() |> Workflow.raw_productions()
[:large]

Given/Where/Then DSL

For complex rules with pattern destructuring, use the explicit DSL with three clauses:

• given — a pattern-matching clause that destructures the input and binds variables. The binding name becomes the key in the bindings map passed to then.
• where — a boolean expression evaluated at runtime. Unlike when guards, where supports any Elixir expression including function calls like String.starts_with?/2, Enum.member?/2, etc.
• then — a function that receives the bindings map and produces a result. The bindings from given are available as keys.

Note: Use where instead of when because when is a reserved Elixir keyword.

Do/End Block Form

require Runic

Runic.rule do
  given(order: %{status: status, total: total})
  where(status == :pending and total > 100)
  then(fn %{order: order, total: total} -> {:apply_discount, order, total * 0.9} end)
end

Named Do/End Block Form

Pass options before the do block to name the rule:

require Runic

Runic.rule name: :premium_discount do
  given(order: %{customer: %{tier: tier}, total: total})
  where(tier == :premium and total > 50)
  then(fn %{order: order} -> {:apply_discount, order} end)
end

Keyword Form

The same rule can be written as a keyword list:

require Runic

Runic.rule(
  name: :threshold_check,
  given: [value: v],
  where: v > 100,
  then: fn %{value: v} -> {:over_threshold, v} end
)

Direct map patterns are also supported in the keyword form:

Runic.rule(
  name: :map_pattern,
  given: %{x: x, y: y},
  where: x + y > 10,
  then: fn %{x: x, y: y} -> {:sum, x + y} end
)

Non-Guard Expressions in where

Unlike when guards, where supports any boolean expression:

require Runic

Runic.rule do
  given(name: name)
  where(String.starts_with?(name, "prefix_"))
  then(fn %{name: n} -> {:matched, n} end)
end

Capturing External Variables with ^

Use the pin operator ^ to capture variables from the surrounding scope. This is essential when dynamically constructing rules in loops or functions:

require Runic
alias Runic.Workflow

threshold = 100

rule =
  Runic.rule do
    given(value: v)
    where(v > ^threshold)
    then(fn %{value: v} -> {:over_threshold, v} end)
  end

Workflow.new()
|> Workflow.add(rule)
|> Workflow.react_until_satisfied(150)
|> Workflow.raw_productions()
# => [{:over_threshold, 150}]

The ^ pin also works in the keyword form and in condition/reaction style:

some_values = [:potato, :ham, :tomato]

Runic.rule(
  name: "escaped rule",
  condition: fn val when is_atom(val) -> true end,
  reaction: fn val ->
    Enum.map(^some_values, fn x -> {val, x} end)
  end
)

Creates a %Saga{}: a sequence of transaction steps with compensating actions.

Sagas are explicit forward-then-compensate pipelines. Each transaction step must have a corresponding compensate block. On failure, completed steps are compensated in reverse order.

Compiles to an Accumulator (tracking saga state), forward Rules (one per transaction step), and compensation Rules (one per compensate block).

Usage

require Runic

saga = Runic.saga name: :fulfillment do
  transaction :reserve_inventory do
    fn _input -> {:ok, :reserved} end
  end
  compensate :reserve_inventory do
    fn %{reserve_inventory: _} -> :released end
  end

  transaction :charge_payment do
    fn %{reserve_inventory: _} -> {:ok, :charged} end
  end
  compensate :charge_payment do
    fn %{charge_payment: _} -> :refunded end
  end

  on_complete fn results -> {:saga_completed, results} end
  on_abort fn reason, compensated -> {:saga_aborted, reason, compensated} end
end

Creates a %StateMachine{}: stateful workflows with reducers and conditional reactors.

State machines combine an accumulator with rules that react to state changes. The reducer processes inputs in context of accumulated state, and reactors conditionally execute based on the new state.

Basic Usage

iex> require Runic
iex> alias Runic.Workflow
iex> counter = Runic.state_machine(
...>   name: :counter,
...>   init: 0,
...>   reducer: fn x, acc -> acc + x end
...> )
iex> workflow = Workflow.new() |> Workflow.add(counter)
iex> results = workflow |> Workflow.plan_eagerly(5) |> Workflow.react_until_satisfied() |> Workflow.raw_productions()
iex> Enum.sort(results)
[0, 5]

Options

• :name - Identifier for the state machine (required for referencing)
• :init - Initial state (literal value, function, or {M, F, A} tuple)
• :reducer - Function (input, state) -> new_state for state transitions
• :reactors - List of rules that react to state changes
• :inputs / :outputs - Reserved for future schema-based type compatibility

With Reactors

Reactors are rules that fire when the accumulated state matches their conditions:

require Runic
alias Runic.Workflow

threshold_sm = Runic.state_machine(
  name: :threshold_monitor,
  init: 0,
  reducer: fn x, acc -> acc + x end,
  reactors: [
    fn state when state > 100 -> :threshold_exceeded end,
    fn state when state > 50 -> :warning end
  ]
)

Lock/Unlock Example

require Runic

lock = Runic.state_machine(
  name: :lock,
  init: %{code: "secret", state: :locked},
  reducer: fn
    :lock, state ->
      %{state | state: :locked}
    {:unlock, code}, %{code: code, state: :locked} = state ->
      %{state | state: :unlocked}
    _, state ->
      state
  end,
  reactors: [
    fn %{state: :unlocked} -> :access_granted end,
    fn %{state: :locked} -> :access_denied end
  ]
)

Block DSL with handle/react (Form 2)

For state machines with complex state and event-driven transitions, the block DSL provides a more expressive form. Each handle clause bundles an event match, input pattern, state binding, and state transformation into a named, addressable sub-component. react clauses observe state without modifying it.

Runic.state_machine name: :cart, init: %{items: [], total: 0} do
  handle :add_item, %{item: item}, state do
    %{state | items: [item | state.items], total: state.total + item.price}
  end

  handle :checkout, _, state when state.items != [] do
    %{state | status: :checked_out}
  end

  react :high_value do
    fn %{total: t} when t > 1000 -> {:vip_alert, t} end
  end
end

handle clause semantics

handle event_pattern, input_match, state_var [when state_guard] do
  body  # must return next state
end

• event_pattern — atom or pattern matched against the incoming fact's event type discriminator.
• input_match — pattern match on the event payload / fact value.
• state_var — binds the current state via state_of(:sm_name) meta_ref.
• when state_guard — optional guard on current state.
• body — returns the next state value, fed to the accumulator.

Each handle compiles to a named Rule: :"<sm_name>_<event_pattern>" (e.g., :cart_add_item).

react clause semantics

react name do
  fn state_pattern -> output end
end

• Name is explicitly required (the atom after react).
• Compiles to a Rule with a state_of() condition and a step that produces an output fact.
• Does not modify state — observation only.

Both forms produce identical %StateMachine{} structs. The handle block is sugar for splitting a multi-clause reducer into individually named rules.

Captured Variables

Use ^ for runtime values in reducers and reactors:

multiplier = 2
Runic.state_machine(
  name: :scaled_sum,
  init: 0,
  reducer: fn x, acc -> acc + x * ^multiplier end
)

Used inside Runic macros such as rules to reference the state of another component such as an accumulator or reduce.

Expands in conjunction with the rest of the expression of the rule's expression to evaluate against the last known state of the component.

Examples

require Runic
alias Runic.Workflow

counter = Runic.accumulator(0, fn x, acc -> acc + x end, name: :counter)

threshold_rule =
  Runic.rule name: :threshold_check do
    given(x: x)
    where(state_of(:counter) > 5)
    then(fn %{x: x} -> {:above_threshold, x} end)
  end

workflow =
  Workflow.new()
  |> Workflow.add(counter)
  |> Workflow.add(threshold_rule, to: :counter)

Creates a %Step{}: a basic lambda expression that can be added to a workflow.

Steps are the fundamental building blocks of Runic workflows, representing input → output transformations. Each step wraps a function and can be composed with other steps to form data processing pipelines.

Basic Usage

iex> require Runic
iex> step = Runic.step(fn x -> x * 2 end)
iex> step.work.(5)
10

Arities

Steps support 0, 1, or 2-arity functions:

iex> require Runic
iex> zero_arity = Runic.step(fn -> 42 end)
iex> zero_arity.work.()
42

iex> require Runic
iex> one_arity = Runic.step(fn x -> x + 1 end)
iex> one_arity.work.(10)
11

iex> require Runic
iex> two_arity = Runic.step(fn a, b -> a + b end)
iex> two_arity.work.(3, 4)
7

Note: 2-arity steps only execute when the workflow receives a 2-element list as input.

Captured Variables with ^

Use the pin operator ^ to capture outer scope variables. This is essential for:

• Content-addressable hashing (each bound value produces unique hashes)

• Serialization with build_log/1 and recovery with from_log/1

• Dynamic workflow construction at runtime

  iex> require Runic iex> multiplier = 3 iex> step = Runic.step(fn x -> x * ^multiplier end) iex> step.closure.bindings[:multiplier] 3 iex> step.work.(10) 30

Without ^, Elixir's normal closure mechanism captures the variable, but Runic cannot track, hash, or serialize it - the workflow will fail after persistence.

Captured Functions

Steps can wrap module functions using capture syntax:

iex> require Runic
iex> step = Runic.step(&String.upcase/1)
iex> step.work.("hello")
"HELLO"

Options

• :name - An atom or string identifier for referencing this step in workflows

• :work - The function to execute (alternative to passing as first argument)

• :inputs - Reserved for future schema-based type compatibility

• :outputs - Reserved for future schema-based type compatibility

  iex> require Runic iex> step = Runic.step(fn x -> x * 2 end, name: :doubler) iex> step.name :doubler

  iex> require Runic iex> step = Runic.step(name: :tripler, work: fn x -> x * 3 end) iex> step.name :tripler

In Workflows

Steps can be connected in pipelines using the workflow DSL:

iex> require Runic
iex> alias Runic.Workflow
iex> workflow = Runic.workflow(
...>   name: "pipeline",
...>   steps: [
...>     {Runic.step(fn x -> x + 1 end, name: :add_one),
...>      [Runic.step(fn x -> x * 2 end, name: :double)]}
...>   ]
...> )
iex> results = workflow |> Workflow.react_until_satisfied(5) |> Workflow.raw_productions()
iex> Enum.sort(results)
[6, 12]

Evaluates to true in a condition if the specified step has ever been ran.

Note that this evaluates to true globally for any prior execution of the workflow, not just within the current invocation.

Examples

require Runic
alias Runic.Workflow

rule =
  Runic.rule name: :after_validation do
    given(x: x)
    where(step_ran?(:validator))
    then(fn %{x: x} -> {:validated, x} end)
  end

Evaluates to true if the specified step has been executed for the given input fact.

Considers only input facts for a generation of invokations fed into the root of the workflow.

Examples

require Runic
alias Runic.Workflow

rule =
  Runic.rule name: :scoped_check do
    given(x: x)
    where(step_ran?(:validator, x))
    then(fn %{x: x} -> {:validated, x} end)
  end

Converts a Runic component into a %Workflow{} via the Transmutable protocol.

Components like steps, rules, state machines, etc. can be transmuted into standalone workflows for evaluation or composition.

Examples

iex> require Runic
iex> step = Runic.step(fn x -> x * 2 end)
iex> workflow = Runic.transmute(step)
iex> workflow.__struct__
Runic.Workflow

iex> require Runic
iex> rule = Runic.rule(fn x when x > 0 -> :positive end)
iex> workflow = Runic.transmute(rule)
iex> workflow.__struct__
Runic.Workflow

Use Cases

• Preparing components for standalone evaluation
• Converting natural representations (e.g., a single rule) into evaluable workflows
• Composing heterogeneous components by first converting to workflows, then merging

Creates a %Workflow{} from component options.

Workflows are directed acyclic graphs (DAGs) of steps, rules, and other components connected through dataflow semantics. They enable lazy or eager evaluation and can be composed, persisted, and distributed.

Basic Usage

iex> require Runic
iex> alias Runic.Workflow
iex> workflow = Runic.workflow(
...>   name: :simple,
...>   steps: [Runic.step(fn x -> x * 2 end)]
...> )
iex> workflow |> Workflow.react_until_satisfied(5) |> Workflow.raw_productions()
[10]