Gateway Decision Evidence
Informative profile, introduced in v0.16.3. It adds no new protocol, schema, registry, wire, or package surface. It composes the existing org.peacprotocol/access-decision record and the registered org.peacprotocol/access extension.
Use this when you operate a gateway decision boundary (for example an API gateway or an AI gateway) and want a portable signed record of a terminal access decision the gateway reached, so a relying party can verify it offline with the issuer's public key and a configured expected-issuer policy.
What the record is, and is not
A gateway decision evidence record is an issuer-signed statement that a terminal access decision (allow, deny, or review) was produced within a gateway decision boundary under the issuer's control. It preserves what the issuer observed, not an independently established fact.
It does not prove the decision was correct, that it was enforced, that the represented event actually occurred, or that the issuer is authorized for any deployment. A signature establishes record integrity and possession of the signing key, not issuer legitimacy or authorization.
The record is a standard interaction record:
- Type:
org.peacprotocol/access-decision - Kind:
evidence - Extension:
org.peacprotocol/access, carrying three schema-required fields:resource,action, anddecision, wheredecisionis exactly one ofallow,deny, orreview.
When to issue, and when to abstain
Issue a record only when every precondition holds. Otherwise the correct behavior is to issue nothing, not to issue a weaker or inferred decision.
| Situation | Action | Why |
|---|---|---|
Terminal allow / deny / review, with a truthful resource and action | Issue | A terminal decision the issuer can populate |
A check outcome only (passed / failed / error) | Abstain | A check result is not an access decision |
| Intermediate: retry or fallback is still possible | Abstain | Terminality is not established |
| Handling action only (log, retry, fallback, continue, transform, block) | Abstain | Lifecycle behavior is not an access decision |
| Third-party report only; no issuer-controlled gateway observation | Abstain | Out of profile for the core composition |
resource, action, or decision cannot be truthfully populated | Abstain | The access extension requires all three |
review is a terminal handoff to another decision process, not indecision: it is issuable, while an unresolved or still-processing state is not.
Issuer-controlled observation
Shape validation does not establish provenance. The decision must have been produced within a gateway decision boundary under the issuer's control, and the deployment must establish that provenance before the issuance path. A record whose decision came only from a third-party report is out of profile. The signing key may be held by the gateway process or by a constrained signing service acting for the issuer; issuance and signing remain inside the deployment trust boundary.
Verify under an explicit issuer and key policy
Verification uses the existing PEAC verification path plus the relying application's configured trust policy:
- Signature and issuer (always). Verify the signature and the expected issuer with the shipped verifier. This establishes record integrity and possession of the signing key, not issuer authorization.
- Record shape (always). Require kind
evidence, typeorg.peacprotocol/access-decision, theaccesspillar, and a validorg.peacprotocol/accessextension. - Key pinning (when configured). Enforce an expected
kidonly when the relying application pins one. - Warning policy (application choice). PEAC preserves well-formed unknown extensions with an informational warning and treats them as application data. Rejecting on any warning is a conservative, application-local policy, not a PEAC requirement.
Three verification failures are worth testing, and the runnable example does:
- a tampered payload fails signature verification (
E_INVALID_SIGNATURE); - a record signed by an unaccepted key fails against the relying party's accepted public key (
E_INVALID_SIGNATURE); - a cryptographically valid record carrying an unexpected issuer fails the configured issuer policy (
E_INVALID_ISSUER).
Data minimization
The record carries the required decision context (resource, action, decision) and, when present, an issuer-observed occurrence time. The composition neither requires nor inlines the request or response content that was evaluated, nor raw prompt, completion, policy, request, or response bodies. Do not place keys, tokens, credentials, raw prompts or completions, complete bodies, full policy documents, or unnecessary personal data in the record. When occurred_at is supplied, use the time the decision became terminal at the boundary, never a fabricated or later signing time.
Non-claims and limitations
Successful verification establishes the integrity of the signed record and possession of the signing key. It does not independently establish:
- that the decision was correct, fair, or complete;
- that the decision was enforced or executed;
- that the represented event actually occurred, or occurred as described;
- issuer legitimacy, or that the issuer is authorized for a deployment context (these are configured trust-policy decisions, established out of band);
- any decision, role, deployment, or upstream source beyond the signed
resource,action, anddecision.
This profile standardizes no assertion-basis field, issuer-role field, upstream-source provenance, deployment identifier, terminality field, or content-commitment encoding. It registers no gateway-decision extension and standardizes no application-specific JSON shape. Applications that need such data define it under their own extension namespace, where generic PEAC verification treats it as application data.
This access-decision profile is distinct from gateway decision (settlement) records, which use the org.peacprotocol/gateway-export extension for the x402 payment-settlement state machine. Terminal access decisions and settlement-state records are different record families; do not coerce one into the other.