Deterministic execution

The platform is engineered so that the structured parts of a workflow produce the same output for the same input on every run, and the parts that are not deterministic by design are isolated and visible.

Audience: risk and compliance reviewers and IT (the enabler)

Why determinism matters

In a SOX-regulated environment, the question that decides whether AI can move from experiment to production is reproducibility. If the same input can produce a different output on a different day, your analyst cannot defend the decision to a controller, and your controller cannot defend it to an external auditor. Determinism is the precondition for control evaluation, not a nice-to-have.

The compliance test is concrete: given the inputs to a specific work item, can the platform re-execute the workflow and produce the same structured output? If yes, the control is testable. If no, the control is unverifiable and the workflow stays in the pilot phase indefinitely.

What the platform does

The platform optimizes for deterministic structure on the parts of a workflow that drive outcomes:

• Runbook compilation. A Runbook compiles to a typed workflow specification with explicit steps, input contracts, and output contracts. The compiled workflow is pinned per published version. Two runs of the same published Runbook execute the same step graph against the same input schema.
• Verified Actions and tool calls. Tool calls are recorded with the exact arguments passed, the exact code executed where applicable, and the exact result returned. Where a tool is wrapped as a Verified Action, the action's contract pins the function signature, the source, and the expected outputs.
• Output contracts. Work item outputs are typed and named. The Runbook declares which slots a successful run produces, and the platform records each slot value with its key.
• Audit ledger replay. Every prompt, every tool argument, every before and after state is recorded. The engineering lens (see the dual-lens article) exposes the raw payload so a reviewer can read what the agent saw and what it produced.

What is not deterministic, by design

Model-generated text for unstructured tasks is not deterministic. A summary paragraph, a free-form analyst narrative, or a generated reply may differ between runs even with identical input. The platform does not pretend otherwise. Where prose matters to the control, treat the prose as advisory and rely on the structured outputs (typed slots, tool results, file changes, integration calls) as the auditable record.

The same applies to LLM reasoning logs (entries with kind: "log"). They are useful for engineering inspection and are hidden behind the Show debug toggle on the audit detail surface. Do not treat reasoning logs as the canonical control record.

Verifying determinism for a workflow

Open the work item or the run in /audit. The audit detail hero shows the Family, Direction, Action, Origin, and request id. The entry timeline lists each material entry in order. For a deterministic check:

1. Read the input contract on the Runbook. The Edit tab on the App's Runbook page shows the typed inputs.
2. Read the output contract. The published spec lists the slots that a successful run produces.
3. Open the run in /audit?group=<group_id>. Expand the engineering Details disclosure on each tool call entry. Confirm the arguments match what the Runbook prescribes for the input.
4. Compare the recorded outputs against the contract. The status pill should be succeeded; the MetricLine shows entry counts; the work item review surface shows the typed slot values.

If two runs of the same published Runbook on the same input produce different structured outputs, that is a defect in either the Runbook or the tool, not a property of the platform. Open the engineering Details disclosure on each entry to compare.

What this means for SOX evaluation

For an external auditor evaluating an AI-driven control, the relevant questions are: can you re-execute the workflow, can you show the recorded evidence for a sampled run, and can you show that the same input produced the same structured output across the sample. The audit ledger answers the first two. The Runbook contract plus the recorded tool arguments answers the third.

Where the workflow contains a model-generated text artifact, document the artifact as an advisory output in the control narrative. Pair it with the structured output that the control actually depends on, and sample on the structured output.

Limitations

Two limitations are worth naming up front:

• Model output for unstructured tasks is non-deterministic. The platform does not seed or pin the model for free-form generation.
• Re-execution is not yet a one-click action. Today, re-running a workflow against the same input requires creating a new work item with that input through the App's normal trigger surface. The replay endpoint is on the roadmap; we will document the procedure when it ships.