Compliance

Coverage current through v1.29.2 (2026-09-26) — the 1.29.x governed model-identity line (digest-pinned model registry, decision-run/evaluation records) rides the same compliance evidence base. Root mirror: COMPLIANCE.md.

Brain Server is a single-node, loopback-first memory component for an AI system. This page summarizes its compliance posture for buyers and procurement. It is a documented engineering posture, not a certification — ISO/IEC 42001 and SOC 2 attestation are organization-level audits outside this repository. The full buyer-facing technical file is COMPLIANCE.md.

What the system is

brain-server stores knowledge chunks, their embeddings, a lexical index, and a knowledge graph, and serves deterministic retrieval (/recall, /search). All data stays on the host (SQLite); there is no cloud, no telemetry to third parties, and no data egress by default.

Data flows (loopback unless stated):

client ── ingest ──► /ingest, /ingest/memory, /ingest/markdown ──► SQLite
client ── recall ──► /recall ──► embed → hybrid (vec0 + FTS5, RRF) → rank
                        └──► audit read-event (opt-in) ──► audit_events (hash chain)
operator ── DSAR ──► /dsar ──► locate → export → purge → tombstone → certificate
                          └──► Art 19 webhook (opt-in, outbound, HMAC-signed)

Purpose limitation. The system stores only what the client sends it. There is no web crawler, no email, no location, no biometric collection. Ingestion paths are explicit client calls; nothing is inferred or scraped.

Data minimization

• Stores exactly the content it is given, chunked for retrieval. No enrichment, inference, or profiling.
• POST /ingest trusts the client’s declared entities/relations — the client controls the graph schema.
• PII control is deterministic read-time output redaction for principals without pii:read/Admin (email / phone / Luhn card, conservative pattern matching, “control, not a classifier”). No plaintext is stored in a placeholder vault.
• Read-event auditing is off by default in loopback, on by default in JWT mode; sampling via BRAIN_AUDIT_READ_SAMPLE_RATE.

Logging (EU AI Act Art 12 / Art 26(6) posture)

The audit is an append-only, tamper-evident hash chain. Since v1.27.31 each link is a keyed HMAC-SHA256 over the full row under a per-DB epoch (hmac256, head pin (id, hash, epoch), key via BRAIN_AUDIT_CHAIN_KEY/BRAIN_AUDIT_CHAIN_KEY_FILE); rows from before that release verify as legacy SHA-256 chains. /audit/verify proves integrity; /metrics reports brain_audit_chain_ok. Retention is configurable via BRAIN_AUDIT_RETENTION_DAYS (deployers: ≥180 days per AI Act Art 26(6) guidance).

Erasure (GDPR / CCPA / PH DPA)

• GET /export — portable JSON export of a subject’s data.
• POST /purge — hard, explicit, audited deletion (by id or owner) with a tombstone.
• POST /dsar — locate → export → purge → chain-verifiable deletion certificate (found / purged / tombstone root / chain head / certified_at).
• GET /tombstones — queryable deletion registry.
• Art 19 onward notification — opt-in HMAC-SHA256-signed webhook on purge.
• Erasure is human-executed. Every delete / purge / DSAR is an operator action via the console or the HTTP API, never an agent call — the memory_forget agent tool was removed (v1.20.25). This keeps the irreversible GDPR Art 17 erasure act under a person’s hand and audited on the chain, rather than delegable to the LLM.
• Erasure-path directive (v1.28.83, Art 17 vs Art 17(3)). Three erasure paths, three completeness postures — pick by the legal character of the request: (1) POST /dsar purge = the Art 17 path: subject-wide sweep (vec/FTS/graph/proposals/workflow/feedback arms) + tombstone + signed certificate; (2) DELETE /memory/{id}?scrub_proposals=1 = single-chunk erasure that ALSO reaches the verbatim HITL decision-record copies (each scrub writes its own audit row; the decision record’s id/status/digests survive, the content does not); (3) bare DELETE /memory/{id} = chunk erasure that PRESERVES the approved decision record verbatim (the response discloses retained_proposal_copies so the retention is never silent). Path (3) is the default because the decision record is approval evidence — the Art 17(3) balance (retention for legal claims / audit purposes) recorded AT the seam. An Art 17 erasure DEMAND (no 17(3) basis) must use path (1), or path (2) for a single chunk — never bare path (3).

Governed act surfaces (shipped)

The regulated-workflow acts procurement asks about each have a live surface: Art 30 records of processing (/art30), the RoPA register (/ropa), a breach ledger (/breach*), cross-border transfer assessments (/transfers/{id}/tia and /transfers/{id}/dpa), re-fetchable DSAR deletion certificates (/dsar/{id}/certificate), and the ISO 10002 complaint lifecycle (/workflow/runs/{id}/complaint/*).

Populating the RoPA register is operator work (only you know your controller identity and lawful bases): edit docs/examples/ropa-seed.json — replace the placeholder entities, review each basis — then load each row with:

brain ropa list
brain ropa add --activity "Knowledge recall indexing" \
    --controller "Your Legal Entity" --processor "Your Host" \
    --lawful-basis "Legitimate interest" [--categories S] [--recipients S] \
    [--retention-days N] [--security-measures S] [--transfers S]

The compliance pack’s gdpr_ropa gate reads green only when the register has real rows behind it. The row-by-row depth for each lives in COMPLIANCE.md.

Framework mapping

The full, row-by-row mapping with the intent-based-auditing coverage and the jurisdiction table is in COMPLIANCE.md.

What certification is NOT claimed

This document describes an engineered control posture. ISO 42001 / SOC 2 attestation require organization-level audits (policy, third-party pen tests, monitoring) that this repository does not and cannot certify. Buyers should treat these docs as the technical evidence base an audit would start from, not as an audit result.

Next steps

• Security — the controls behind these postures.
• Deployment — configuring audit retention, redaction, and the DSAR webhook.