Compliance mapping

A compliance audit pack is a signed, tamper-evident, content-free export of one agent run: every chained receipt, the head hash, the model lineage, the span, the anchor. This page covers the optional framework parameter, which adds a section mapping that pack's contents to the clauses an auditor actually asks about.

What this is, and firmly is not

It is a mapping of the evidence in one pack. Each mapped item cites the artifact in the pack that evidences it — a JSON path, a count, a hash — so a reviewer can check the claim against the same document rather than taking it on faith. Where an obligation is organizational rather than technical, or where Sable holds only part of the evidence, the item says so instead of claiming coverage.

It is not a certification, an attestation of compliance, or a legal opinion, and Sable is not an auditor or a notified body. No output of this endpoint means you comply with anything. The same disclaimer is embedded verbatim in every mapping, so it travels with the document rather than living only on this page.

Requesting one

curl -X POST "https://api.buildsable.com/v1/runs/$RUN_ID/audit?framework=eu_ai_act" \
  -H "Authorization: Bearer $SABLE_SESSION_TOKEN"

framework accepts eu_ai_act, soc2, or none (the default). With none, no mapping section is produced and the pack — including its signed manifest — is byte-identical to what it was before this parameter existed.

EU AI Act

Clause	Coverage	Evidence cited from the pack
Article 12 — record-keeping	evidenced	`receipts[]` (one signed, timestamped record per metered request), `chain.head_hash` and `chain.manifest_sha256` for ordering and tamper evidence, and the public `anchor` when the run has one.
Article 13 — transparency to deployers	partially evidenced	`summary.models` and each receipt's `model` / `engine`: which system actually served each request. What the deployer was told about the system is outside Sable and is not evidenced.
Article 14 — human oversight	partially evidenced	`receipts[].policy` (the rule set and its hash that governed the call) and `receipts[].guardrails` (the detectors, their hash, and their content-free findings).
Article 15 — accuracy, robustness, cybersecurity	partially evidenced	`receipts[].attestation` where a call ran on the TEE-attested route, `receipts[].content_fingerprint`, and `receipts[].context` where retrieved context was declared.

Two of those deserve their plain-language version, because they are the ones easiest to overclaim:

Article 14. Sable records the constraints an agent operated under and proves they were applied. It does not implement human oversight. There is no human-in-the-loop step here, no review queue, and no approval gate. The oversight process is yours; the pack evidences the bounds you configured.

Article 15. A receipt does not evidence the accuracy of model output. What it evidences is integrity and provenance: what was submitted (by fingerprint), what served it, under which rules, and that none of it was altered afterwards. If you need output quality tracked over time, that is eval drift monitoring, and it is not part of a pack.

SOC 2

Criterion	Coverage	Evidence cited from the pack
CC6 — logical access	partially evidenced	Every receipt was minted for a request authenticated by a scoped API key (spend caps, model allowlists, expiry, delegation depth), plus `receipts[].policy` and `receipts[].guardrails` where present. Organizational access control — who could mint the key, onboarding and offboarding, physical access — is outside Sable.
CC7 — system operations	partially evidenced	Per-request outcome and timing, the tamper-evident chain, the anchor where present, and `manifest_proof`, one signature over the whole pack.
CC7.2 / model lineage	evidenced	`summary.models`, and each receipt's signed `model` + `engine` — the "prove which model served this request" question, answered per request.

Absent evidence is reported as absent

If no call in the run ran on the attested route, the Article 15 item says receipts[].attestation: absent — these calls ran on the standard (non-attested) route. If the run has not been anchored yet, the anchor line says so. This is deliberate: a mapping that quietly omitted the gaps would be worse than no mapping, because it would read as coverage.

The mapping is signed

The pack's signed manifest gains two fields when a framework is requested:

framework — which one,
compliance_mapping_sha256 — the digest of the mapping section.

Both are covered by the same signature as the rest of the manifest, so the mapping is exactly as tamper-evident as the receipts it cites. Verify it the way you verify anything else Sable signs:

curl https://api.buildsable.com/v1/receipts/verify \
  -H "Content-Type: application/json" \
  -d '{"receipt":"<manifest_proof.proof>","signature":"<manifest_proof.signature>"}'

Then recompute sha256 over the returned compliance_mapping section and check it against compliance_mapping_sha256 in the payload. A different evidence set produces a different digest, so a mapping cannot be swapped for a friendlier one without breaking the signature.