How the evidence works
This page is the technical model behind Compliance in Brutor: the layers, the standards each one rests on, and the rules every statement obeys.
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
Section titled “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 checked against the official text — ten offered (EU AI Act, ISO/IEC 42001, SOC 2, HIPAA, GDPR, DORA, NIS2, NIST AI RMF, Colorado, Korea); Brazil listed as a draft (how they are checked) | 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
Section titled “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
Section titled “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, withmthe 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 nevermetornot met. - Missing inputs are never a pass. No rows, no records or no profile gives
not_evaluableorundetermined, notmet. - Every statement states its limit — what it does not show.
- Grades never go up. A tree head is
standaloneuntil an independently operated witness countersigns it; a witness you run yourself makes itself_witnessed, neverwitnessed; 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.

