Decision Governance

On a regulated decision path, "the system decided so" is not an answer. You must be able to show which rule produced the decision, who published that rule, and which version was running that day. This page explains how the platform makes that possible.

The decision endpoint is deterministic. The outcome is produced by the rules and flow nodes you publish — not by a model's probability output. The same input, evaluated against the same published version, yields the same decision.

Who writes a decision

Capability	Permission
Authoring rules and flows, updating drafts, publishing	`fraud:edit_rules`
Reading decisions and reports	`fraud:view_reports`
Reading decision detail and resolving masked fields	`fraud:view_decisions`
Placing and releasing a legal hold	`fraud:override`

Retention, erasure and legal hold are covered in detail on a separate page: Data Retention and Legal Hold.

The publisher's identity is never taken from the request body. It is resolved from the verified access token; any actor field sent in the body is ignored. The name on a publication record is therefore the platform's own determination, not the caller's claim.

Flow lifecycle

draft → validation → simulation → publish gate → published → archived

Draft. A flow is created as a draft and can be modified only in that state. Attempting to modify a published or archived flow is rejected.
Validation. Schema, node and edge integrity are checked.
Simulation. The flow is executed against sample inputs.
Publish gate. The flow is compiled and a gate summary is produced.
Publish. All three steps must have been performed against the current checksum of the content being published. If a single character changed after validation, the checksum no longer matches and the publish is rejected.
Archive. The previously active version in the same scope is archived automatically; exactly one active version remains.

⚠️

Only published, active flows enter resolution. A draft or inactive flow is never evaluated, however narrowly it is scoped.

A rollback is a new publication, not an edit. Published content is never modified in place; the earlier version is published again. History cannot be rewritten after the fact.

The publication record

Every publication is written to an append-only record:

the full compiled snapshot of the flow at that moment,
the publisher's identity,
the publish note,
the publish gate summary.

Every decision record carries the flow version it was decided with. "Why was this transaction blocked" is traceable from the decision itself back to the publication record.

An extra gate for your own code

A script node passes mandatory static analysis before publication: module import/export, require and eval patterns are blocked. The result is recorded as clean, warning or blocked; a blocked script cannot be published. At runtime it executes in an isolated environment under time and memory ceilings, and each execution is recorded separately.

Failure posture

The rule evaluator is three-valued: true, false, indeterminate. If an operand is missing or its type does not match, the result is indeterminate and, under the fail-closed principle, is treated as matched; the reason text records this explicitly, so the uncertainty stays visible in the decision. Uncertainty propagates correctly through logical combinations; a fail-closed posture does not silently become fail-open.

There is one deliberate exception: in a switch node, indeterminate cases are not selected, the flow falls through to the default branch, and the indeterminate cases appear in the explainability output.

If a flow raises an error while running, the decision is raised to at least review; an existing block is never lowered.

We also state what is not fail-closed. When external signal providers are unreachable or context enrichment fails, the decision is not blocked — it is made without that input, and the fact is recorded. The only thing that locks a decision is a rule you wrote.

AI-assisted drafting

You describe a policy in prose and the system produces a starting flow draft.

The generated draft is never persisted and never published; it is returned in the response.
The draft is created disabled.
Side-effecting node types are removed from the palette the model may use: script, transform, HTTP request, platform event, gRPC call, database lookup, cache write, external event source and subflow.
If the draft does not pass the engine's own validator, nothing is returned.
The response carries the model and prompt version as an audit stamp.
If no model is configured, the system does not invent a template; it returns an explicit error.

AI generation is therefore a suggestion. To reach production, you must save the draft and take it through the validation → simulation → publish gate chain above.

Where machine learning sits

There is no model call on the decision endpoint's path. What runs on the decision path is the flow you published.
score is not a model's probability output; it is the numeric weight accumulated by nodes.
A separate machine learning platform exists (model registry, governance, invocation observability and transaction scoring) and is used from the panel surface; access is protected by fraud:view_reports.
If you want a model output to influence a decision, you do so by publishing that output as a flow input — that is, through the same gate.

Flows and Resolution — scope axes, multi-flow evaluation, outcome merging
Decision API — request, response, reason codes
Overview — the engine as a whole

Compliance AI Data Retention and Legal Hold