The compliance evidence programme

Every framework a Brutor customer is audited against asks an AI System the same three questions: what did it do, who was in the loop, and can you prove the record is honest? The EU AI Act (Arts 12, 14, 19, 26, 50), ISO/IEC 42001 (A.6.2.6, A.6.2.8, A.8), SOC 2 (CC4, CC6, CC7, CC8), HIPAA (§164.312(b), (c)), GDPR (Arts 5(2), 22, 32), DORA and NIS2 word them differently; the evidence they ask for is the same.

So the AI control plane builds one evidence substrate and treats every framework as data over it. The substrate is made of published standards, so a party outside your organisation — an auditor, a regulator, a customer — can check it with tooling Brutor does not ship.

The layers

Layer	What it is	Standard	Page
1 · Records	Every governed verdict — refusals included — becomes an ai.brutor/action-record/v1 record, signed as a Signed Statement	RFC 8785 (JCS), RFC 9052 (COSE_Sign1), RFC 9995 (hash envelope), RFC 9943 (SCITT)	Action records, Signed statements & keys
2 · Logs	One append-only Merkle log per tenant; signed tree heads every 100 entries or 15 minutes	RFC 6962 / RFC 9162	Tenant logs & witnesses
3 · Witnesses	Tree heads registered with transparency services and timestamp authorities; receipts checked under pinned keys	RFC 9943 registration, RFC 9942 receipts, RFC 3161	Tenant logs & witnesses
4 · Bundles	Portable packages of records, inclusion proofs, heads, receipts and completeness claims; disclosure records	the above, plus ai.brutor/evidence-bundle/v1	Bundles, disclosure & verification
Obligations	A framework registry (data, not code) whose obligations cite shared resolvers; per-framework Evidence Reports	framework catalogs — EU AI Act, ISO/IEC 42001, SOC 2, HIPAA, GDPR, DORA, NIS2, NIST AI RMF, Colorado, Korea, Brazil	Framework registry, catalogs

Layers 1–4 know nothing about any regulation. A framework is a catalog entry naming obligations and, for each, which resolvers evidence it. Adding a jurisdiction is data entry plus, at most, one new resolver.

What is standard and what is ours

Tier	Component	Used for
Published standard	COSE_Sign1 — RFC 9052	every signature
Published standard	COSE Hash Envelope — RFC 9995	the statement payload is the digest of the record
Published standard	SCITT architecture — RFC 9943	how records and tree heads are signed and registered
Published standard	COSE Receipts — RFC 9942	witness receipts and inclusion-proof encoding
Published standard	Certificate Transparency Merkle tree — RFC 6962 / RFC 9162	the tenant log, inclusion and consistency proofs
Published standard	JSON Canonicalization Scheme — RFC 8785	canonical record bytes
Published standard	Time-Stamp Protocol — RFC 3161	an independent date anchor for tree heads
Brutor-versioned	ai.brutor/action-record/v1, the tree-head payload, ai.brutor/evidence-bundle/v1, the framework registry	record vocabulary and semantics, pinned by the published verifier rules and vectors
Optional profile	Agent Action Capsule (draft-mih-scitt-agent-action-capsule-04)	an off-by-default export for parties that ask for that format — an individual Internet-Draft, not WG-adopted (AAC profile)

Integrity is checkable by anyone with a COSE/SCITT library. Record semantics (the honesty rules below) are checked by brutor-verify — the CLI and the in-browser verifier — and the rules and finding codes are published so a third party can reimplement them.

The honesty principles

These are product rules, enforced in code and in the console’s copy:

• n of m, never a percentage. A statement says met 57 of 60, with m the population it is about. A rounded 95 % hides the three.
• Four bases, never blended. Every statement is recomputed (derived from the log, ledger and config), judged (a model over a disclosed sample, stated with human agreement), an indicator (movement, never a threshold) or declared (an operator statement, sealed but not checked). Recomputed and judged counts are never summed; a declared statement is never met; an indicator is never met or not met.
• Missing inputs are never a pass. No rows, no records or no profile gives not_evaluable or undetermined, not met.
• Every statement states its limit — what it does not show.
• Grades never go up. A tree head is standalone until an independently operated witness countersigns it; a witness you run yourself makes it self_witnessed, never witnessed; a timestamp dates a head but never raises its grade.
• Integrity is not completeness. A record proves an action it covers was not altered; it cannot prove there was no action it does not cover. Completeness is a human-signed scope census.
• Never “compliant”. Nothing the programme produces says compliant, certified, guaranteed or tamper-proof. It says sealed, witnessed, timestamped, recomputed, judged, met (n of m), not met, not evaluable, withheld, declared. The console’s copy is pinned by a vocabulary test.

What this programme does not do

It does not give legal advice — every page and product string that names a provision says so. It does not fulfil organisational obligations a gateway cannot observe (risk management, quality management, conformity assessment, CE marking); those are evidenced by pointer and declaration, never claimed. It does not mark content (no watermarking or C2PA). And it covers the programmatic surface — agents, applications, CLIs and portals whose traffic points at the gateway — never consumer chat apps that talk directly to their vendors.

Turning it on

1 · Set the evidence key

Set BRUTOR_EVIDENCE_SIGNING_KEY on the Core Proxy. Without it nothing is sealed and traffic is unaffected. See Signed statements & keys.

2 · Add a witness

Register at least one independent RFC 9943 transparency service under Settings → Evidence. The trial bundle’s brutor-witness is same-operator. See witnesses.

3 · Enable frameworks

Compliance → Frameworks: enable the frameworks you are audited against. See the registry.

4 · Declare profiles

Compliance → Profiles: declare each AI System’s role, classification and facts. Every save is sealed. See the compliance profile.

How this relates to AI System Assurance

Assurance answers is this system still operating as signed off? — health, drift, liveness, contracts. The compliance programme answers can we prove what it did to someone outside the organisation, against a named obligation? It reuses assurance data as inputs (daily health, contract promotions, approvals, the run ledger) and seals them. The Assurance Report keeps its behavioural role; obligation evidence lives in the Evidence Reports.

Pages in this section

Action recordsWhat gets a record, the schema member by member, the 14 verdicts, chaining, data admission.

Signed statements & keysThe COSE header, issuer and subject, the public key document, per-tenant keys, rotation, env vars.

Tenant logs & witnessesRFC 6962 logs, tree-head cadence, witness adapters, grades, the kill switch, running brutor-witness.

Bundles, disclosure & verificationThe bundle format, completeness claims, disclosure records, verifying with any tool, finding codes.

Framework registry & evidence basesCatalogs as data, the four bases, every resolver, version in force, retention floors.

Judged evidence & human agreementSealed rubrics, assessments, blind human reviews, κ and Wilson intervals.

TransparencyThe Portal AI-interaction notice, its ordering guarantee and sealed record.

Incidents, reports & documentationPer-framework deadlines, Evidence Reports as bundles, documentation skeletons.

The Compliance consoleA tour of the Admin UI section.

Evidence API referenceCore and Control Plane endpoints, the vector corpus, the optional AAC profile.