A feature flag decides which code path runs. Decionis decides whether a high-stakes action should run at all — and records signed proof of the decision. Teams usually need both: flags for rollout control, a decision gate for the steps that move money, mutate production state, or execute on an agent's behalf.
the step you are gating is consequential and needs a judgement, not a toggle: a deploy, a refund, a discount stack, a schema migration, an AI agent's tool call. You want the three-way outcome (ALLOW, ESCALATE to a human, BLOCK), the evidence evaluated inline, and a signed Decision Dossier you can hand to an auditor or a counterparty afterwards.
you are managing rollout risk on code paths: progressive delivery, A/B experiments, per-cohort targeting, an instant kill switch on a new implementation. Flag platforms are excellent at this, their SDKs are mature, and a policy engine is the wrong tool for choosing which variant of a checkout page renders.
They compose naturally, because they answer different questions in the same pipeline: the flag chooses which code path is live; Decionis governs the consequential step inside that path. A common shape is a flag rolling a new payout flow to 10% of traffic while every payout inside it — old flow or new — still passes through the same evaluate-decision gate, so the rollout experiment never widens who can move money.
| Dimension | Decionis | Traditional feature flags |
|---|---|---|
| What is being decided | Whether a captured execution intent is safe: policy plus evidence in, a judgement out. | Which code path or variant executes for this request or user. |
| Possible outcomes | ALLOW, ESCALATE (held for a person who holds the authority), or BLOCK — with reason codes. | On, off, or a variant. There is no held-for-approval state. |
| Human approval path | Built in: ESCALATE routes to an approver in Slack, Microsoft Teams, or Webex, and nothing executes until they sign off. | Approvals exist for changing a flag's configuration, not for the individual actions running under it. |
| Evidence at decision time | The evaluation reads the action's own context — amounts, margins, actor, environment — against versioned policy. | Targeting rules read user and environment attributes; the flag does not inspect what the gated action is about to do. |
| Proof afterwards | Every verdict is recorded in an Ed25519-signed Decision Dossier anyone can verify publicly, without an account. | Audit logs record who changed which flag when — a change history, not a signed record of each governed action. |
| Trying it safely | Shadow mode evaluates policies on real traffic and shows what would have been held, without blocking anything. | Percentage rollouts and targeting rules derisk exposure; the flag itself is already the safe-launch tool. |
| Where it runs | Inline before execution — API, SDKs, a GitHub Action, checkout surfaces, and MCP tools for agent frameworks. | In-process SDKs and edge configs, evaluated wherever the code path branches. |
You can approximate one — flip a flag off until someone says yes — but the approval lives in a chat thread and the flag history only shows the toggle. There is no per-action judgement, no held state for the one risky request while the rest flow, and no signed record tying the approval to what actually executed. If the step is consequential enough that you are building approval ceremony around a flag, it is a decision gate you are reaching for.
How escalation and overrides workNo. Rollout control and experimentation are what flag platforms are for, and Decionis does not do them. Keep the flags; put the gate on the steps whose failure you would have to explain later — payouts, deploys, migrations, discount logic, agent actions.
What teams gate firstA third outcome. A flag is binary at the moment of evaluation, so anything uncertain has to be either allowed or refused wholesale. ESCALATE holds the specific action, routes it to someone with the authority to decide, and records their sign-off in the dossier — the ambiguous case gets a person, not a default.
The verdict vocabularyRun it in shadow mode: policies evaluate on real traffic, verdicts and would-have-held reports accumulate, and nothing is blocked. It is the same first step the flag world taught everyone — observe before you enforce — applied to decisions instead of code paths.
Shadow modeThat a specific intent was evaluated against a specific policy version at a specific time, what the verdict was, and why — signed with a published key, so a customer, auditor, or regulator can verify the record without trusting a screenshot of a dashboard. Flag audit logs establish configuration history; a dossier establishes what happened to one action.
Verify a dossier yourselfRun a scenario in the sandbox and download the signed Decision Dossier it produces, or install shadow mode and watch what would have been held on your own traffic.
Start in shadow mode