Framework, Risk Report, Deployment Standard.

What a regulator reads in a record.

A Warrant record is built so a Title III auditor reads it the way they would frame the question: what kind of system this is, what the agent did, whether each action was within its authorisation, and which obligations apply and whether they were met. Each row maps back to a specific clause of regulation.

What the record proves

Every record is independently verifiable without contacting Warrant. A regulator can confirm, from outside, that the record is the one Warrant issued, that it has not changed since, and that it existed at the time it claims. Each record is mapped to a specific EU AI Act obligation. The verify page performs that check end-to-end in the browser.

See the deep dive: how verification works. See an end-to-end record: /verify.

Corpus diff

When a record references a different corpus version than its parent, Warrant computes a sub_clause-level diff and renders it as a dedicated PDF section. Regulators read the fourteen lines that changed between corpus v3 and v4, not the 200-page corpus. The diff is deterministic, lex-ordered, and self-describing, and an auditor can confirm it independently without contacting Warrant.

What's evaluated, what's pending.

The candidate corpus carries 157 sub_clauses across 15 regimes today. Promotion to production is gated on founder tier-1 review (~2.5–3.5 hours of regulatory reading). The table below states the status of each regime against the working corpus snapshot.

Cost and latency floor

The record runs at approximately $0.20 per trace. End-to-end target latency is 60 seconds per trace under the locked vendor routing. Prompt caching is enabled where the inputs are stable, billed at a fraction of the standard input rate within the cache window.

Open audit items

• Tier-1 founder review on 26 RBI FREE-AI placeholders, 5 SEBI verifications, 1 NYDFS spot-check.
• Corpus promotion (candidate → production) gated on the above. Until promotion, every record is bound to the candidate corpus version and a regulator can replay the candidate from the verify page, independently verifiable without contacting Warrant.
• Petri-style alignment audit is on the roadmap; not in the current record.

What we hold operators to.

When Warrant is in your audit path, these are the obligations that keep every record intact. The standard is short on purpose. Each clause is falsifiable, and every record stays independently verifiable without contacting Warrant.

Record authenticity

• Every record is independently verifiable without contacting Warrant. An operator can confirm, from outside, that a record is the one Warrant issued before accepting it as evidence.
• Operators MUST run that check on every record before relying on it.
• Records stay verifiable indefinitely. A record issued today remains independently verifiable years later, after any internal change at Warrant.

Time of record

• Every record proves the time it was issued, independently verifiable without contacting Warrant.
• The synchronous response carries a provisional time proof for latency; the final proof lands shortly after. The verify page surfaces both states.
• Operators MUST NOT treat a record carrying only the provisional proof as final evidence beyond a 24-hour grace window.

Corpus pinning

• Every record is bound to the exact regulations corpus version active at decision time. A regulator can confirm that binding independently without contacting Warrant.
• Operators MUST run the monthly drift check (Pre-Req C) that compares each sub-clause's regulator-text source URL and alerts on change. This separates operator-intentional corpus changes from upstream regulator-text changes.

Reproducible verification

• The check that confirms a record is well-defined and stable, so two parties verifying the same record reach the same result.
• The verify page runs that exact check, so a downstream operator can confirm any record independently without contacting Warrant.

Independent confirmation

• More than one independent party MUST be able to confirm any record in production, so no single party can quietly change what a record says. A network running enough independent parties stays correct even if one is compromised.
• Every party runs against an identical pinned regulations corpus. Any disagreement on a record between parties is a published incident.
• The identity of which party confirmed a record MUST NOT change the result of the check. The result depends only on the record and the corpus, never on who ran it.
• Each party MUST publish, for outside audit, which corpus version and software it is running, plus a liveness signal so a stalled party is detectable. Disagreement on the corpus version or software between parties is a published incident. That surface lands on warrant.build/network in PRE-D.7.

Release integrity

• Every Warrant release is independently verifiable without contacting Warrant. An operator can confirm a release is the one Warrant published, long after it shipped.
• Operators MUST run that check before consuming any release. A failed check for any reason MUST trigger a network incident, not a retry.
• Every main merge requires two maintainer approvals + Code Owner review + a clean CI/security gate. Force-push to main is disabled. Linear history is enforced. The branch protection settings + GitHub-CLI equivalent live in docs/scopes/pre-req-d6-branch-protection-runbook.md so a regulator can independently audit them.
• The release tarball is reproducible: re-running the workflow against the same tag produces a byte-identical result, so an operator can rebuild it and confirm.

Regulator onboarding rubric

• Onboarding is out-of-band by design. There is no self-service signup. Every onboarded regulator entered the system through a manual rubric — signed letter on the regulator's letterhead, callback against the published switchboard, identity record entered into the regulator_identities table by a Warrant Labs maintainer. The full rubric is published as a spec at /spec/regulator-onboarding so any regulator's legal team can confirm what is expected of them before sending a letter.
• The rubric is what makes the token mean what it says. The token's scope claim of the form regulator:read:jurisdiction/{code} is only as strong as the manual binding behind it. Operators MUST treat onboarding as a hard floor, not a feature to optimise.

Token format + scope enforcement

• Regulator API tokens use a token format chosen to avoid the algorithm-confusion attack surface behind several token compromises in 2023–2025. The token-claim shape is otherwise free.
• Every token carries a scope claim of the form regulator:read:jurisdiction/{code} where {code} is an ISO 3166-1 alpha-2 (or the alpha-2-DASH-state form for US states). The scope is the ONLY thing that grants access. A token without the scope claim, with a malformed scope, or with a scope for a jurisdiction not in the active regulator-identities table is rejected as 401 — never as 200 with empty data.
• The token's scope jurisdiction is the source of truth for what the regulator can read. If the URL query asks for a different jurisdiction than the token's scope, the request is rejected as 403 with an audit-log entry against the authenticated identity. This is the cathedral-plan promise that scope mismatch is never silently narrowed.
• Tokens expire twelve months from issuance. Rotation runs the manual rubric at /spec/regulator-onboarding in compressed form (fresh signed letter referencing the prior letter + confirmation callback). The team does not issue a renewal without the rubric.

Tamper-evident access log

• Every regulator access to the API writes one tamper-evident entry to regulator_audit_log, each entry independently verifiable without contacting Warrant over a fixed set of fields (accessed_at, endpoint, id, query_jurisdiction, regulator_identity_id, returned_row_count).
• After local commit, the entry is mirrored to at least 2 independent parties. Mirror is durability, not correctness — a partial-mirror outcome is logged and surfaced on the public network status page, but the local write is the source of truth. The 7-year retention promise from the deployment standard's service-levels clause applies to every entry.
• The regulator can fetch their own access history at GET /regulator/audit-log?jurisdiction={code}. Each entry is independently verifiable offline without contacting Warrant. A Warrant-internal compromise cannot silently rewrite a regulator's history, because every entry is also held by ≥ 2 independent parties.
• An entry that fails verification is an incident. The regulator MUST treat a failed check as evidence of tampering and the operations runbook MUST trigger an incident review against the responsible parties.

Edge auth + internal-surface separation

• The internal surfaces (internal.warrant.build/motions for founder business intel and internal.warrant.build/ops for production SLOs and on-call) sit behind Cloudflare Access policies with inverted threat models. Operators MUST run the two surfaces under separate policies — a single policy that grants access to both is a CCP violation because a competitor breach of motions is a different incident class than an outage-investigator breach of ops.
• Google Workspace is the canonical identity provider for both policies. The founder-only motions policy requires the founder's specific email + Google Workspace authentication + country-of-origin allowlist. The ops policy requires the team's email domain + Google Workspace + an IP allowlist for on-call rotation. Both policies log every decision to the Cloudflare Audit Log + Azure Log Analytics workspace so a regulator-facing forensic query can correlate.
• The regulator-facing API gate is WARRANT_REGULATOR_ENABLED. Operators MUST run the full five-check verification (documented at docs/scopes/pre-req-c7-cloudflare-access-runbook.md in the canonical repo) before flipping the flag to true. Until verified, the API returns 503 on /regulator/aggregate and /regulator/audit-log.

Service levels + on-call

• Operators MUST publish service level objectives on five surfaces and alert against them on a burn-rate model. The canonical numbers: POST /attest p95 < 90s and ≥ 99% success over 30d; /verify ≥ 99.9% over 30d; /regulator p95 < 500ms over 30d; record-verification freshness ≥ 99.95%; ingest success ≥ 99% over 7d. The full machine-readable definition lives in internal/ops/slo.yaml in the canonical repo.
• Every SLO MUST have a documented response runbook (internal/ops/runbook.md) that a single on-call rotation can execute within five minutes of being paged. For /verify specifically — the regulator-visible surface — the escalation policy MUST page the founder tier immediately, not after the standard 15-minute backup window.
• Operators MUST run a drill against each runbook section quarterly against the non-prod environment, with the drill outcome logged. A runbook that has never been exercised is not a runbook.
• The 7-year evidence-log retention requirement is tracked separately from these SLOs — retention failure is a compliance violation, not a service degradation, and is handled by the Azure Cool Storage policy referenced in the receipt persistence layer.

Failure modes

• The ingestion adapter (@warrant/agent-sdk-hooks) MUST NOT throw into the host agent on a Warrant outage. Failed records persist to an optional retryStore and are replayed when the ingestion endpoint recovers.
• A record with refusal_reason set is a valid record. It records that Warrant declined to map the trace and why — that itself is evidence.

Who to write to.

Regulator-facing technical questions go to [email protected]. The team commits to a five-business-day response on first contact; clarifications iterate from there.

Operator-facing questions go to [email protected].

Source code (Apache-2.0 spec, MIT shim): github.com/warrantlabs/warrant.