| Pre-execution authorizationIs the action decided before it executes, rather than logged after? | implementedEvery consequential action is evaluated against the organisation's own policy bundle before commit and answered ALLOW, ESCALATE or BLOCK. Execution Authority | statedAuthority is determined before one exact action executes. | statedEach agent action is authorised before it reaches an enterprise resource. | statedEvery agent action is evaluated before it runs. | statedEvery action is evaluated against the policy table before anything touches the world; the verdicts are permit, deny, propose, dry-run, observe or replay (AADP §3.2). | statedEach API request or MCP tool call is sent to the customer's policy decision point over AuthZEN and the decision is enforced before the request is forwarded; a deny returns a 403, or a JSON-RPC error for MCP. | statedCritical actions are checked before an external execution route is allowed and answered Allow, Approval Required, Recovery Required or Block. |
|---|
| Deterministic, versioned policyDoes the same policy revision and the same inputs always give the same verdict? | implementedThe verdict is a deterministic function of the policy revision, the request and the supplied facts; policy revisions are immutable and the revision is recorded in every dossier. Policy decision graph | statedDeterministic pre-execution controls over versioned authority policies are stated. | not foundnot found in reviewed public materials; Authorisation against mission, intent, context and risk is stated; the evaluation method is not. | not foundnot found in reviewed public materials; The Blueprint is versioned; evaluation is described as a reasoning engine, and determinism is not stated. | statedDeterminism over the full evaluation input is normative (AADP §9); policies are data, a content digest of the policy is stamped on every audit row, and superseded policy must be retained (AADP §10). | not foundnot found in reviewed public materials; the gateway authors no policy and enforces whatever the customer's decision point answers; determinism and versioning belong to that engine and are not stated for the gateway. | not foundnot found in reviewed public materials; policy, budget and workflow-order checks and a policy version on the receipt are stated; how the Domain Oracle evaluates, and whether the same inputs always give the same answer, is not. |
|---|
| Exact-action bindingIs the authorisation tied to the exact material fields of the action that will execute? | implementedExecutionBinding 1.0 binds the dossier to the canonical payload digest, execution target, policy identity and digest, material signals, validity window and nonce. Execution authority evidence | statedA canonical transaction digest binds payer, payee, destination, amount, currency or asset and rail. | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials; Tool parameters are evaluated; a commitment carried to the downstream execution is not described. | not foundnot found in reviewed public materials; parameters are bound-checked and the permit is a bearer capability in the current revision; an action-bound signed permit carrying a digest of the exact action is described as a planned addition (AADP §1.2; conformance item A10). | not foundnot found in reviewed public materials; the AuthZEN request is built from token claims and request fields by a CEL mapping; a commitment to the exact payload carried through to the downstream call is not described. | not foundnot found in reviewed public materials; approval is bound to a stable action fingerprint so a changed amount, vendor, policy, tool or scope does not reuse it; what the fingerprint covers and how it reaches the executing provider is not described. |
|---|
| Canonical payload commitmentIs the digest computed over a published canonical form, so anyone can recompute it? | implementedPayloads and bindings are canonicalised with RFC 8785 (JCS) and digested with SHA-256; the profile is named inside the dossier so a verifier recomputes it without asking Decionis. Verify a Decision Dossier | not foundnot found in reviewed public materials; A canonical digest is stated; the canonicalisation profile and algorithm are not. | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials; a canonical serialisation and digest of the action payload is not stated for the current revision. | not foundnot found in reviewed public materials; cryptographic fingerprints of gateway and access logs are committed to the transparency log; a canonical digest over the action itself is not stated. | not foundnot found in reviewed public materials; an action fingerprint and an audit hash on the receipt are stated; the canonical form and the algorithm are not. |
|---|
| Pre-commit revalidationImmediately before commit, is the authorisation checked again against current policy and signals? | implementedThe claim step revalidates the signed dossier, the current policy revision, material signals, human approval, target, payload, expiry and nonce before the action is released. Claim before commit | not foundnot found in reviewed public materials; Single-use authorisation is stated; a revalidation step at commit is not. | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | statedA resumed approval is re-evaluated as a new decision and a kill switch engaged after approval still denies (AADP §8); a directly permitted action executes on the permit, and a separate check at commit is not stated. | not foundnot found in reviewed public materials; the decision is enforced on the request in flight; a separate revalidation against current state before the downstream commit is not described. | not foundnot found in reviewed public materials; a changed action is stated not to reuse an earlier approval; a revalidation step against current policy and state at the moment of execution is not described. |
|---|
| Replay-resistant, single-use grantCan an authorisation be presented twice, or for a different action? | implementedEach grant carries a nonce that is claimed once, within a lease; a second claim, an expired lease or a substituted payload is refused and recorded. Execution authority evidence | statedSingle-use execution authorisation is stated. | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | statedA permit id is single-use and a second report for it is rejected; the request id is the idempotency key; a granted approval is consumed on use (AADP §7–8). The conformance statement records sender-constrained permits as an open item (A2). | not foundnot found in reviewed public materials; delegated tokens are scoped and exchanged per hop; a single-use, nonce-bound authorisation for one action is not described. | not foundnot found in reviewed public materials; duplicate-payment protection and duplicate windows are stated; a single-use, nonce-bound authorisation for one action is not. |
|---|
| Human authority bound to the actionWhen a person approves, is the approval tied to the exact action, not to a session? | implementedPresence resolves an ESCALATE with a verified human whose approval carries the action's binding digest and is revalidated before the nonce is claimed. Presence | not foundnot found in reviewed public materials; Human step-up is stated; that the approval is bound to the transaction digest is not. | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | statedThe propose verdict creates an approval with a deadline; who approved and when is recorded, the approval is single-use and the action is re-evaluated on resumption (AADP §8); binding of the approval to a digest of the exact action is not stated. | not foundnot found in reviewed public materials; human approval is not part of the three pillars; the decision point may implement it, and the gateway does not state a binding of an approval to the action. | statedApproval Required pauses the action for a person, and the approval is bound to the action fingerprint so a changed amount, vendor, policy, tool or scope does not silently reuse it. |
|---|
| Effect evidenceAfter execution, is the observed outcome recorded with a digest of the actual response? | implementedFinalisation records CONFIRMED, FAILED or INDETERMINATE with the request digest, a response digest for confirmed effects, the observer and its version, and how the effect was observed. Effect evidence | not foundnot found in reviewed public materials; An append-only record of what was authorised and what occurred is stated; a response digest is not. | not foundnot found in reviewed public materials; An OpenTelemetry audit trail is stated. | not foundnot found in reviewed public materials | statedThe enforcement point reports success, failure, timeout or not_attempted against the permit, and the intent row is durable before the permit returns, so a crash leaves an intent with no result (AADP §5.3, §9); a response digest or an observer identity is not stated. | not foundnot found in reviewed public materials; evidence covers what the gateway allowed or refused; the press release states that application records supply the business outcomes, and a response digest for the executed action is not described. | not foundnot found in reviewed public materials; receipts carry intent, policy, approval, execution evidence and outcome, and a recovery trail preserves the case when execution fails or evidence is missing; a response digest and an observer identity are not stated. |
|---|
| Signed input snapshotAre the exact inputs the verdict was reached on signed alongside the verdict? | implementedThe inputs snapshot is built once, signed with the dossier and stored verbatim, so a verifier can replay the decision from what was actually evaluated. Decision Dossier | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | statedEach evidence entry carries the request, verdict, reason, both tiers, a timestamp and the policy digest and must be sufficient to re-derive the verdict (AADP §10); Ed25519 signing of rows is an opt-in extra, off by default (README; changelog 0.5.0). | not foundnot found in reviewed public materials; the decision, the policy that answered and the reason are written to the same tamper-evident record as the request; a signed snapshot of the inputs the decision point evaluated is not stated. | not foundnot found in reviewed public materials; the receipt records the policy version and the approval binding; a signed snapshot of the inputs the Domain Oracle evaluated is not stated. |
|---|
| Offline verificationCan a party who does not trust the operator verify the evidence with the service off? | implementedAn open verifier checks the Ed25519 signature, recomputes the digests and refuses the negative cases, from two files and a published key set, with no account and no call to Decionis. Verify without an account | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | statedWith signing on, a receipt verifies against a key id supplied from outside the store and otherwise reads self-consistent; a Merkle root a deployer publishes lets a third party check an exported receipt's membership (README; changelog 0.5.0). Chaining, signing and anchoring are opt-in and off by default. | statedAn open verifier checks inclusion and consistency proofs and the witness signature on the customer's own machine, without trusting Traefik; the record it verifies is the gateway's decision log. | not foundnot found in reviewed public materials; receipts are described as verifiable and auditable with an audit hash; a verifier a party outside the platform can run was not found. |
|---|
| Portable SCITT-profile evidenceCan the evidence leave the vendor's format and be checked by someone else's tooling? | implementedA dossier and its execution lifecycle export to the SCITT Agent Action Capsule draft-04 profile with a COSE-signed producer envelope; a draft-pinned compatibility claim, not conformance to a published standard. SCITT-compatible export | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials; the log is built on C2SP tlog-witness and Tessera; a SCITT or other portable evidence profile is not stated. | not foundnot found in reviewed public materials |
|---|
| Public verification corpusIs there a published corpus a reviewer can run the verifier against today? | implementedA synthetic corpus of signed dossiers, including the cases a verifier must refuse, is archived with a DOI under Apache-2.0 with its signing key deliberately published. Corpus DOI | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials | not foundnot found in reviewed public materials; the oneproof suite publishes sample receipts, a reference verifier and ten rejection vectors for its separate stage-receipt format (preview, 11 September 2026); a corpus for onedoor decision receipts was not found. | not foundnot found in reviewed public materials; a Traefik-operated public witness is available at launch; a published corpus of decision records to run the verifier against was not found. | not foundnot found in reviewed public materials |
|---|