Decionis

Execution pattern

Policy change review

Govern changes to the rules, not only actions under them.

Category
ApprovalsCommon in Fintech & payments · Healthcare · Public sector
Works through
adobe commerce · github · salesforce · servicenow +1 more
Proof
Signed Decision DossierVerifiable against our published JWKS.
Deploy
Shadow Mode firstMeasure on your own traffic before anything is stopped.

What executes

Someone edits a policy, raises a threshold, or disables a rule.

What normally goes wrong

Every control has an edit button, and loosening one is the fastest way to make a blocked action succeed. If policy changes are not themselves governed, the gate can be removed by whoever it inconveniences — and the record will show the action was permitted.

The decision

The signals available at the moment of the action, and the rule that judges them.

Signals

  • Which rule changed, and in which direction
  • Whether the editor is subject to the rule
  • Blast radius of the loosened threshold
  • Prior overrides against the same rule

The gate

Require independent review for any change that loosens a control, and refuse changes made by someone the rule constrains.

ALLOW

The change lands with its review recorded alongside the version.

ESCALATE

A loosening change waits on someone independent of it.

BLOCK

The change does not land — for example self-approval of one's own limit.

The Protocol — Deterministic. Contextual. Explainable.Four stages left to right. Input signals — user or agent identity, context and data, tools and resources, spend and budget, policies, history and reputation, and environment — enter the Decionis Protocol. Inside, the protocol normalizes context and intent, evaluates policies and rules, runs a deterministic risk and policy engine, and explains the reason and evidence. It emits a verdict: ALLOW (authorized), ESCALATE (needs approval or more info), or BLOCK (high risk or out of policy). The verdict drives an enforcement action: allow, block, require approval, or throttle and limit. Every decision is recorded for audit, learning, and continuous improvement.INPUT SIGNALSUser / Agent IdentityContext & DataTools / ResourcesSpend / BudgetPoliciesHistory & ReputationEnvironmentDECIONIS PROTOCOLNormalizeContext & IntentEvaluatePolicies & RulesRisk & Policy Engine(Deterministic)ExplainReason & EvidenceVERDICTALLOWAuthorizedESCALATENeeds approvalor more infoBLOCKHigh risk orout of policyACTIONSAllowBlockRequire ApprovalThrottle / Limit
Four stages left to right. Input signals — user or agent identity, context and data, tools and resources, spend and budget, policies, history and reputation, and environment — enter the Decionis Protocol. Inside, the protocol normalizes context and intent, evaluates policies and rules, runs a deterministic risk and policy engine, and explains the reason and evidence. It emits a verdict: ALLOW (authorized), ESCALATE (needs approval or more info), or BLOCK (high risk or out of policy). The verdict drives an enforcement action: allow, block, require approval, or throttle and limit. Every decision is recorded for audit, learning, and continuous improvement.

No policy pack decides this pattern yet

Write the gate above as your own policy: a repository policy file, or a bundle in your workspace.

Govern this pattern with a published Zap

Start from the workflow already running in your source system. Decionis adds the policy decision and returns signed evidence without turning Zapier into the authority.

Prove it, then deploy it

A verdict you cannot check is an opinion, and a gate you cannot measure first is a risk of its own.

View the signed proof

Every verdict on this pattern produces a Decision Dossier: the signals it saw, the policy version that judged them, and an Ed25519 signature anyone can check against our published JWKS — without an account, and without trusting us.

Deploy in Shadow Mode

Run this gate against your own traffic while it stops nothing. You get the verdicts it would have returned and the actions it would have held, so the decision to enforce is made on your numbers rather than ours.

What to do next

The same five steps for every pattern in the library.

  1. Simulate this recipe

    Run the policy against a realistic action in the browser. Push it past what the rules allow and watch the verdict come back. No account.

  2. View the signed Decision Dossier

    See exactly what was decided and why: the rule that fired, the evidence it read, the policy version in force, and an Ed25519 signature you can verify yourself.

  3. Deploy in shadow mode

    Measure what the policy would have caught on your own traffic without touching the live path. Every recipe defaults to shadow, so the first deployment carries no execution risk.

  4. Connect a real workflow

    Point the same policy at the system where the action actually originates — a checkout, an ERP posting, a Zap, an agent's tool call.

  5. Share the verified result

    Publish the proof: a public verification link, an embeddable badge, a PR comment, or an anonymized shadow-mode finding. This is how the next person discovers Decionis.

← All execution patterns