PROOFGATE STANDARDMINIMUM REQUIREMENTSCOMPLIANCE CHECKLIST

The minimum requirements for AI that can act.

This standard defines deterministic consequence rails for AI systems that touch production. It is not a model preference. It is a boundary architecture: models propose, a policy gate decides, and the system emits signed proof of what happened.

Read the Spec Read the Threat Model

DEFINITION

Deterministic Consequences

A system property where the same validated intent + the same policy state yields the same allowed effects (deny, require approval, execute), with cryptographic receipts and append-only audit truth.

If an AI product cannot prove what it did and why, it is not compliant with this standard.

CORE PRINCIPLES

Architecture, not vibes.

The ProofGate Standard specifies enforceable requirements. You can implement it with any model provider, any tool stack, and any UI. The standard governs one thing: how consequences are permitted and proven.

Models propose, systems decide

Model output must never directly execute tools. It must be expressed as an Intent Envelope.

Policy is explicit

Allowlists, caps, deny rules, and approvals are machine-enforced. No implicit authority.

Least privilege is mandatory

Tools run behind a router. Credentials never sit in the model. Scope is minimized per action.

Approvals must be unforgeable

Approval tokens must be signed, expiring, and bound to the intent hash (no replay, no spoof).

Receipts must be cryptographic

Decision and execution receipts must be signed. Proof of causality is default behavior.

Audit must be append-only

Every request/result must be written immutably. Incidents become forensics, not blame games.

The buyer test (one question)

Ask: “What guarantees do you provide if the model is wrong?”
If the answer is monitoring, user correction, or “the model is improving,” that is not a guarantee. This standard requires enforceable constraints + signed proof.

What this standard is not

It is not “prompt hardening.” It is not “better RAG.” It is not “the right model.” ProofGate is an architectural boundary that remains valid even as models change.

COMPLIANCE CHECKLIST

Minimum requirements (v0.1)

An implementation is compliant if it satisfies the following requirements. Each requirement is verifiable by inspection and/or by produced artifacts.

REQ-01: Intent Envelope

All actions are represented as a structured intent with explicit action type, targets, payload, and metadata. No free-form prompts as execution plans.

REQ-02: Policy Gate

Every intent is evaluated by a deterministic policy engine that returns DENY / REQUIRE_APPROVAL / EXECUTE, with a reason.

REQ-03: No Secrets in the Model

Models never receive raw credentials or bearer tokens. Tool credentials live exclusively in the execution router.

REQ-04: Tool Router with Least Privilege

Tools are invoked only through a router that enforces allowlists, scope limits, and action-specific permissions.

REQ-05: Signed Approval Tokens

When approvals are required, tokens are cryptographically signed, expiring, and bound to the exact intent hash to prevent spoofing and replay.

REQ-06: Signed Receipts

Every decision and execution emits a signed receipt containing hashes of canonical intent and execution results.

REQ-07: Append-only Audit Log

All requests and results are written as append-only audit events (e.g., JSONL). No rewrites. No silent deletion.

REQ-08: TOCTOU Safety

Approval-time execution must re-check the decision against current policy to prevent time-of-check/time-of-use drift.

REQ-09: Replay Resistance

Approvals and executions must not be re-usable after completion or expiration; approvals are one-time and bound to intent hash + expiry.

REQ-10: Deterministic Failure Modes

When a request fails validation or policy denies it, the system returns explicit reasons and produces denial receipts where applicable.

Implementation note

ProofGate compliance can be audited by reviewing:

the policy definition (Invariant Pack),
the router’s permission model,
signed receipts,
append-only audit logs.

Reference Implementation Spec: Intent / Tokens / Receipts