Open source. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

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.
  • No workflow is time-driven. There is no scheduler, queue or delayed step; a due date arriving changes no state (L-04).
  • 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, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. 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.

Two mechanical bounds matter as much as the principle. The event buffer is in-process and not durable — a crash between the database commit and the dispatch loses the events, so they cannot back a remote integration. And no workflow ever starts because time passed: there is no scheduler, queue or delayed step, so a follow-up date arriving changes no state (L-04). Everything that runs was explicitly asked to run, by an actor the system records but — having no authentication — never verifies (L-01).

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.

    LimitThe actor is asserted, not authenticated: there is no auth, tenancy or RBAC, and an actor header is not 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, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
  • L-04 No scheduler, no reminders, nothing on a timer. Follow-up Tasks and an Activity timeline are one shared model that a person moves by hand: a due date changes no state. There is no recurring work, no delayed workflow, no queue — so nothing fires on a renewal notice period either.

Jobs it covers

Documented in

Proved by