One screen for Decionis integrations, enforcement, and audit evidence.
Use this index when the homepage snapshot is not enough. It points to first-party docs, demo, pricing, ROI, and audit pages that substantiate what Decionis supports today.
Supported Integrations
Documented surfaces, commercially packaged ones, and demoed handoffs are listed separately, so you can see exactly which kind of proof sits behind each row.
Shipped Artifact Map
The map separates the evidence Decionis emits from the workflow surface that called it. Native integrations, SDK clients, web flows, and public API calls all resolve through protocol artifacts.
Enforcement Patterns
Decionis is positioned as an execution gate, not a post-hoc dashboard.
Canonical protocol evaluation
POST /v1/protocol/evaluate-decision is the default decision surface for new governed workflows after onboarding and deployment-bundle issuance.
Action Gate wrapper
POST /v1/action-gate/evaluate remains available when a surface-specific adapter needs an action-gate response envelope.
Shadow to enforcement rollout
Pricing puts shadow mode first, then controlled enforcement once policy, signals, and evidence are accepted.
Native handoff
Teams, Webex, and ServiceNow examples show approvals, escalations, and state mutation staying paused until Decionis returns the governed verdict.
Proof Artifacts
Per-decision evidence and org-level evidence are documented separately.
Policy Snapshot
Hash-backed policy version, bundle, rule digest, parameter digest, and effective-window evidence.
Reason Codes
Stable explanation vocabulary for decisions, SDK errors, Decision Dossiers, and support workflows.
Decision Chain
Workflow lineage that links related evaluations, parent dossiers, and integrity hashes.
Decision Dossier
Per-decision proof with outcome, policy version, signal context, verification, and integrity metadata.
Public verification
Share-safe verification route for a dossier without exposing the full org-scoped artifact.
Portable artifact
Transport-ready dossier payload for external delivery, workflow records, or downstream storage.
Validation pack
Org-level evidence export with manifest hashes, bundle hashes, signatures, and downloadable audit artifacts.
Shadow Report
Observe-only rollout evidence with would-block, would-escalate, near-miss, and enforcement candidate cards.
Override Trail
Appeal and reviewer trail linked to the original Decision Dossier and chain when available.
Execution Map
One-screen artifact map from execution intent to policy, dossier, chain, ledger, and handoff.
ROI proof
Close-stage model for approval drag, time-to-decision reduction, no-action wins, and 60-day payback.
Public metrics
Machine-readable public metrics endpoint for the current execution snapshot.
Verification Path
Follow this sequence to check Decionis for yourself, past the numbers on the homepage — whether you are doing security review, integration work, or research.
- 01
Start with /docs/quickstart to verify onboarding and deployment-bundle issuance.
- 02
Use /docs/decision-evaluation to verify the canonical route and response shape.
- 03
Open /evidence to inspect the shipped artifact map before drilling into specific docs.
- 04
Use /docs/decision-dossier and /docs/validation-packs to verify per-decision and org-level evidence.
- 05
Use /roi-proof and /pricing to validate business outcome framing and commercial rollout posture.
The reference implementation, the banking profile, and the hosted authority
One row per piece of evidence a buyer is likely to be handed, with the status it carries in its own document, what checking it establishes, and what it is most often stretched into. Each link was verified on the date shown.
| Evidence | Status | Establishes | Does not establish |
|---|---|---|---|
| The published reference implementation The open-source library · verified 2026-09-12 | Apache-2.0 · v0.1.4 | The execution boundary is public, installable, and released with a signed tag, SBOM, checksums and provenance; what it does is what its documents at that tag say. | Anything the repository's master branch says beyond the tag; a hosted authorization service (the package is a library and a runnable reference). |
| Its evaluation path The open-source library · verified 2026-09-12 | Development snapshot (master) | Which artefact a reviewer is looking at, who owns which control, and what each test, demo, corpus and CI status does and does not establish, in the repository's own words. | Independent certification; a version other than the one the npm latest tag names. |
| The trust boundary and the accepted risks The integrating organisation · verified 2026-09-12 | Published version (v0.1.4) | Which fields the agent controls and which the host must supply from authenticated context; which risks the library accepts and what compensating control the host owes for each. | Executor isolation, agent egress denial, credential scoping or incident response — those are the integrating organisation's, and the library says so. |
| Execution outcomes and the unknown outcome The open-source library · verified 2026-09-12 | Published version (v0.1.4) | A single-use grant admits one execution; a lost provider response is recorded as unknown, finalized as indeterminate, and reconciled by reading, never by a second dispatch. | Exactly-once business effects downstream, or confirmation of settlement; whether an observation counts as confirmed is the authority's judgement. |
| The architecture The open-source library · verified 2026-09-12 | Published version (v0.1.4) | How the pieces sit: an agent proposes, an independent authority decides, a verified person approves an escalation, a single-use grant is claimed once, a trusted executor runs the registered handler, and every step leaves a signed record. | That any deployment is wired this way; the document describes the reference, and the host's placement of the executor is the host's. |
| The self-checking adversarial demos The open-source library · verified 2026-09-12 | Synthetic · published version (v0.1.4) | Against synthetic policy, a fixture authority and in-process doubles, every legitimate path executed once and every attack failed to execute; each demo exits non-zero on any attack that runs. | That a hosted integration exists, that any real provider or model behaves this way, or any attack-success rate: the demo is the boundary holding on the commit it ran from. |
| Continuous integration on the reference implementation The open-source library · verified 2026-09-12 | Development snapshot (per commit) | Which commits passed the repository's own verify job — formatting, lint, metadata, fixture, corpus, licence, security, discovery, type, automation, unit and build checks, and the adversarial demos — on a clean checkout. | Anything about the published package unless the commit is the release commit; independent certification; production throughput. |
| The service contract the adapters call The Decionis authority · verified 2026-09-12 | Runs over the API today | The published OpenAPI specification for evaluate, enforce-and-bind, claim, finalize and verify: what an adapter sends, what comes back, with idempotency and replay stated. | That an endpoint is placed on a bank's transaction path; the contract is the wire, not the deployment. |
| The documented gaps The open-source library · verified 2026-09-12 | Development snapshot (master) | What the project says it has not yet done or cannot prove alone: the human sign-offs automation cannot manufacture, the continuity and bus-factor limits, the OpenSSF criteria still marked unmet. | That the list is complete; it is the project's own account, kept current by its maintainers. |
| The hosted authority, over the API The Decionis authority · verified 2026-09-12 | Runs over the API today | Policy evaluation against the signals you supply, a signed Decision Dossier behind every verdict, and shadow mode first — recording what the gate would have done without enforcing anything. | That a bank's production transaction path is enforced: inline authorization on the transaction path is in Private beta. |
| The banking profile of the protocol The banking profile · verified 2026-09-12 | BEAP v1.0 · Published | How a disbursement, a payment run, or a limit increase is written down, who signs it, how the authority to execute is claimed once, and what is recorded afterwards — as a draft with the banks reviewing it. | A finished standard; approval by any body; that any supplier's product meets it; that any bank runs it in production. |
Who owns which control
- The published reference implementation
- Its evaluation path
- Execution outcomes and the unknown outcome
- The architecture
- The self-checking adversarial demos
- Continuous integration on the reference implementation
- The documented gaps
- The service contract the adapters call
- The hosted authority, over the API
- The banking profile of the protocol
- The trust boundary and the accepted risks
The library captures, gates, verifies and dispatches. The authority decides, issues and consumes grants, and keeps the record. The profile says how a bank writes the instruction down and who signs it. The integrating organisation isolates the executor, denies the agent egress, and scopes the credentials; nothing on this page does that for it.
Beside what you already run
Roles, not rankings. Which policy engine, identity provider, approval tool or audit store is the better one is not a question this page answers.
| Alongside | Its role | Decionis' role |
|---|---|---|
| A policy engine (OPA, Cedar, a rules service) | Decides what the policy says. | Binds the decision to the exact action at the moment of action, issues a single-use grant for it, and keeps the signed record; a policy engine can be the authority behind the gate or an input to it. |
| An identity provider | Says who the actor is. | Takes that identity from authenticated server context, never from the model, and binds it into the captured intent. |
| An approval tool or workflow engine | Collects a signature. | Turns a signature into evidence that a named person approved this exact action, re-evaluates policy with it, and issues the grant from that evaluation; a signature alone authorizes nothing. |
| An audit or observability store | Keeps the record. | Makes sure execution cannot bypass the record: every consequential attempt correlates to a decision and a claimed grant, including the attempts whose outcome is not known. |
Signed dossier vs. a generic approval log
ERP and workflow tools record that someone approved. For high-stakes exceptions where standard templates fail, that partial proof is a black box. Decionis records the institutional authority behind the action — concrete, signed, and verifiable.
| What it answers | Generic ERP / approval log | Decionis |
|---|---|---|
| Proof type | Approval log entry (partial) | Signed Decision Dossier |
| Which policy applied | Not recorded | Policy version + rule digest |
| Why allowed / held | Not recorded | Reason codes + Decision Chain |
| Institutional memory | Scattered logs & screenshots | Execution Ledger, verifiable without an account |
The differentiator is ledger-backed authority, not another black-box approval system. See it on a real workflow: shadow mode for internal approvals.
Treat this page as the compact first-party proof map.
The evidence index does not replace the docs. It points reviewers to the exact pages where integrations, enforcement behavior, proof artifacts, and outcome framing are documented.