Version proof
policy_version and policy_bundle_id identify the policy artifact Decionis selected for the evaluated workflow.
Loading…
API documentation
Policy Snapshot
A Policy Snapshot is the signed reference to the policy artifact Decionis evaluated for one execution intent. It gives auditors version, digest, and effective-window proof without copying policy rules into the application or SDK.
Purpose
Use Policy Snapshot evidence to prove which policy version governed a decision without exposing if-then policy logic in the client surface.
Digest proof
rules_sha256 and parameters_sha256 let reviewers detect whether the evaluated artifact changed after the decision.
Time proof
effective_from, effective_to, and evaluated_at show whether the policy artifact was active when Decionis resolved the request.
Where it appears
Policy Snapshot evidence travels with the protocol response and with the downstream evidence surfaces.
POST
/v1/protocol/evaluate-decisionAPI keyReturns policy_snapshot when Decionis can resolve the policy bundle or policy guard for the evaluated org and workflow.
GET
/v1/protocol/dossiers/:dossierId?org_id=<org_uuid>API keyReturns the stored Decision Dossier payload with the policy snapshot captured at decision time.
GET
/v1/public/decision-dossiers/:dossierId/verify?sig=<signature>PublicReturns share-safe policy snapshot fields when the dossier owner shares a signed verification URL.
Fields
The fields are evidence pointers. They are not the policy source itself.
| Field | Meaning |
|---|---|
| policy_version | Human-readable version selected for this decision. |
| policy_bundle_id | Immutable UUID for the encoded Decionis policy bundle. |
| rules_sha256 | Digest of the encoded rule set evaluated by Decionis. |
| parameters_sha256 | Digest of bundle parameters and resolver settings. |
| effective_from | Start of the policy validity window, when known. |
| effective_to | End of the policy validity window, or null for active policy. |
| evaluated_at | Timestamp when Decionis evaluated the execution intent. |
| source | Source of the snapshot: org_policy_bundle, policy_guard, or request_default. |
Example
The snapshot sits next to outcome, reason codes, dossier, chain, and ledger fields.
curl -X POST https://api.decionis.com/v1/protocol/evaluate-decision \
-H "Authorization: Bearer dcy_org_xxx" \
-H "Idempotency-Key: order-123" \
-H "Content-Type: application/json" \
-d '{
"org_id": "11111111-1111-4111-8111-111111111111",
"decision_type": "CFD_TRADE_EXECUTION",
"workflow_key": "cfd_trade_execution",
"amount": 18000,
"risk_score": 0.74,
"mode": "ENFORCEMENT",
"context": {
"instrument": "EURUSD",
"side": "BUY"
}
}'{
"outcome": "ESCALATE",
"policy_version": "cfd_trade_execution-v1",
"policy_snapshot": {
"policy_version": "cfd_trade_execution-v1",
"policy_bundle_id": "aaaaaaaa-aaaa-4aaa-8aaa-000000000001",
"rules_sha256": "7c9f...",
"parameters_sha256": "b31a...",
"effective_from": "2026-05-04T00:00:00.000Z",
"effective_to": null,
"evaluated_at": "2026-05-04T06:44:51.799Z",
"source": "org_policy_bundle"
},
"reason_codes": ["PROTOCOL_OUTCOME_ESCALATE", "POLICY_MATCHED"],
"dossier_id": "22222222-2222-4222-8222-222222222222"
}Boundaries
A snapshot proves lineage. It does not give the caller authority to inspect or reimplement policy.
No client-side policy logic
Applications should submit execution intent through /docs/decision-evaluation and let Decionis resolve the active policy. Use the snapshot for audit, support, and reconciliation, not as a local rule engine.