What is a deterministic workflow?

Deterministic workflow, defined

People ask this as: what is a deterministic workflow versus an ai agent workflow

A deterministic workflow is a multi-step business process whose transitions are explicit code with defined outcomes: the same inputs under the same policy version produce the same result, and every step leaves evidence. It is the opposite of a workflow whose next step is a model's judgement at runtime. In Accordo every commercial mutation passes through a module service or a named workflow, runs inside one transaction, and leaves an audit event and a step-level trace — and determinism claims only reproducibility: nothing about the property makes the encoded process correct.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • Deterministic means reproducible, not correct. A workflow encoding the wrong rule reproduces the wrong decision exactly, and nothing in the framework detects that.
  • The transaction-scoped event buffer is in-process and not durable. A crash between commit and dispatch loses delivery, so these events cannot back a remote integration.
  • Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04).
  • In local-development mode the actor a workflow records is asserted in a header, not authenticated (L-01).
  • Determinism here describes this framework's services and workflows. It is not a claim that no model runs anywhere at runtime in an application an owner extends.

No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim. Every claim and every limitation is on one page.

The definition, and the contrast that gives it meaning

A deterministic workflow is a named, multi-step process — qualify this lead, request this stage change, approve this quote — implemented as explicit code whose branches are enumerable in advance. Given the same record state, the same request and the same policy version, it takes the same path and produces the same outcome, including the outcome of refusing. Its value is that the process can be reviewed before it runs and accounted for after.

The contrast is a workflow in which a model decides the next step at runtime. That design can be useful, but its behaviour is a distribution rather than a function, and its audit trail explains what happened without constraining what happens next time. The architectural rule this framework is built on keeps the two apart: AI may interpret intent and compose the system at development time, but CRM state changes pass through deterministic services and workflows, and a model may recommend a commercial decision without being able to make one (C-03).

How Accordo executes one

Every mutation goes through a module service or a named workflow and leaves an audit event and a step-level trace behind it (C-16). An action's business writes run inside one transaction with generated-service savepoints nested inside it — all writes commit or none do — and domain events are queued in a transaction-scoped buffer, dispatched only after the commit and dropped on rollback, so no subscriber ever observes a half-applied process. The trace is written after the transaction resolves, which means a failed action still leaves a record of how far it got.

Refusal is a first-class outcome, not an exception path. The renewal workflow refuses an agent actor that tries to record the human decision, and a named test asserts both the refusal and the fact that nothing changed underneath it (C-04). A workflow that stopped and left state altered would not have stopped.

What determinism does not cover

Determinism is about reproducibility, not correctness: a workflow that faithfully encodes the wrong business rule reproduces the wrong decision every time, and nothing in the framework can tell. Review of the encoded rule is human work, which is why the rules live in explicit source rather than generated configuration.

The in-process event buffer alone is not durable. A separate transactional outbox and durable job store support explicitly composed self-host workers; a crash-safe remote integration still needs its handler and delivery policy. Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04). The framework enforces authorization and one tenant per application instance; the deployment supplies authentication. Self-hosted SQLite and dedicated-database PostgreSQL compositions exist, but are not a general production-readiness claim (L-01, L-02).

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-03 Commercial policy is deterministic code, not a model's judgement: a renewal at or above the threshold stops and waits for a named human.

    LimitProven for the built-in renewal object and its single value threshold. A general policy engine over arbitrary custom objects does not exist.

  • C-04 The agent cannot approve on the human's behalf. A test asserts the refusal, so the boundary is a property of the system rather than a promise in a README.

    LimitIn local-development mode the actor is asserted, not authenticated: no authentication ships, so an actor header there is not an identity. This holds a boundary against an honest agent, not against an attacker with network access.

  • C-16 Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

    LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

Limitations

  • L-01 No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
  • L-04 Timers exist; a service that runs them for you does not. Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.

Jobs it covers

Documented in

Proved by