Skip to main content
POST
Verify a Refusal Record's signature

Body

application/json

Durable, signed, independently verifiable evidence that a policy decision rejected a transaction (RFC-0021). Scope is deliberately narrow: covers PolicyEngine.evaluate REJECTs and SignalIntentBinder binding-violation REJECTs only, not caller-authentication failures or webhook signature failures, which are a separate, unsigned audit-sink capability. At most one Refusal Record exists per businessTransactionId.

refusalRecordId
string
required

Unique Refusal Record identifier.

businessTransactionId
string
required

Business Transaction this refusal is about.

decision
Decision · object
required

Immutable result of evaluating an Intent against a Policy. Decision does not create authority, grant authorization, or modify Intent; it only records the outcome of deterministic Policy evaluation.

Example:
evaluatedIntent
object
required

The Intent snapshot the signals were evaluated against: target and parameters only, present for every refusal, not only binding violations.

refusalRecordHash
string
required

Canonical hash of this Refusal Record, same convention as ExecutionTrustRecord.trustRecordHash.

signature
object
required

Cryptographic signature over the canonical Refusal Record, signed with the same key as ExecutionTrustRecord, one root of trust for both approvals and refusals.

createdAt
string<date-time>
required

UTC timestamp when this Refusal Record was created.

bindingViolations
object[]

Present only when the rejection came from SignalIntentBinder. Absent (not an empty array) for an ordinary PolicyEngine.evaluate REJECT that never reached binding-violation logic at all.

submittedBy
string

Authenticated caller who submitted the rejected request. Absent when caller authentication is disabled.

Response

Verification completed. A 200 does not by itself mean the signature verified, see the valid field.

Response shared by POST /refusal/verify and POST /audit/verify: a bare signature-validity result, no wrapper, no partial-failure detail. Both routes verify a signature over bytes with no database lookup, so there is nothing more specific to report than valid or not.

valid
boolean
required

Whether the signature verifies against Parmana's public key for the stated algorithm and key ID.