> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mnemom.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance Attestation Foundation

> Use versioned Trust Postures as audit evidence for SOC 2, EU AI Act, HIPAA, and ISO 27001. Point-in-time queries answer 'what was our detection policy on date X' with a single SQL join.

Versioned Trust Postures are the foundation for compliance attestation. They give auditors a single, queryable answer to the question "what was your detection policy at time T" — across SOC 2, EU AI Act, HIPAA, ISO 27001, and any other framework that mandates documented control state at point-in-time.

This guide is the **foundation** layer. The full control-mapping (which posture field maps to which control) lands once SOC 2 work formalizes. The foundation is enough to start collecting audit evidence today.

<Note>
  **Phase 5 — External Readiness** extends compliance evidence with cryptographic durability. Every canonical card composition is recorded in the [transparency log](/concepts/transparency-log) with a signed [AAP attestation token](/concepts/aap-attestation) and a Merkle inclusion proof. Auditors can answer "what was Agent X's canonical alignment posture on 2026-03-31" via [`mnemom verify-card <agent_id> --at 2026-03-31T00:00:00Z`](/guides/verify-card) and receive a verifiable cryptographic answer — independent of Mnemom's online services.

  The transparency log is publicly readable at `/v1/transparency/log/{agent_id}?at=<ISO>`; the signed Merkle root is at `/v1/transparency/root`; the public-key set is at `/v1/.well-known/jwks.json`. None of the three require Mnemom credentials.
</Note>

## The three properties that make postures auditable

1. **Named, library-cataloged.** Every posture has a stable `posture_id`, a human-readable `name`, and a kebab-case `slug`. Auditors can reference "the policy assigned to the Banking team at the time of incident" by id, not by reconstructing config.

2. **Versioned, forward-only.** Every edit creates a new revision. Old revisions never disappear — they become queryable historical entries. Rollback creates a *new* revision whose body equals the target's, so audit linearity is preserved with no destructive history rewrites.

3. **Audit-logged on every mutation.** Every `posture.create`, `posture.put`, `posture.clone`, `team_posture.assign`, and `team_posture.unassign` writes a row to `governance_audit_log` with the actor, the before/after JSON, and the idempotency key. The audit log is the source of truth for "who changed what, when."

## Point-in-time queries

The queryable answer to "what was the team's effective posture on 2026-03-31" is a single SQL pattern. The detail depends on whether the team was floating or pinned at that time:

### Floating team — query the posture's history

```sql theme={null}
WITH active_revision AS (
  SELECT
    tpr.body,
    tpr.revision_no,
    tpr.authored_at,
    tpr.authored_by,
    tpr.change_summary
  FROM trust_posture_revisions tpr
  WHERE tpr.posture_id = (
    SELECT posture_id
    FROM team_posture_assignments
    WHERE team_id = $team_id
  )
    AND tpr.authored_at <= $point_in_time
  ORDER BY tpr.revision_no DESC
  LIMIT 1
)
SELECT * FROM active_revision;
```

This returns the revision that was current on the day in question, plus its `change_summary` — the load-bearing answer for an auditor's question.

### Pinned team — query the pinned revision directly

```sql theme={null}
SELECT
  tpr.body,
  tpr.revision_no,
  tpr.authored_at,
  tpr.authored_by,
  tpr.change_summary
FROM trust_posture_revisions tpr
JOIN team_posture_assignments tpa ON tpa.assigned_revision_id = tpr.revision_id
WHERE tpa.team_id = $team_id;
```

Pinned teams don't move — the answer doesn't depend on `point_in_time` (as long as the assignment was active then; check the audit log for the assignment's lifespan).

## Audit log shape

`governance_audit_log` rows for posture mutations look like:

```jsonc theme={null}
{
  "id": "audit-2026-04-15-...",
  "actor_user_id": "user-...",
  "actor_role": "org_admin",
  "action": "posture.put",
  "target_type": "posture",
  "target_id": "tp-org-acme-banking",
  "before_json": { /* prior revision's body */ },
  "after_json":  { /* new revision's body */ },
  "metadata": { "revision_no": 4, "revision_id": "tpr-..." },
  "request_id": "cf-ray-...",
  "idempotency_key": "...",
  "at": "2026-04-15T13:42:11Z"
}
```

Key properties for auditors:

* **Attribution.** `actor_user_id` + `actor_role` answer "who did this." Roles include `platform_admin`, `org_owner`, `org_admin`, `team_admin`, `member`, `system`.
* **Diffability.** `before_json` + `after_json` are the full bodies. The dashboard's [revision diff view](/concepts/posture-versioning#diff) consumes the same data; auditors can run their own diffs offline.
* **Idempotency.** The `idempotency_key` proves a mutation wasn't applied twice. Replay attacks are visible as duplicate rows with identical keys.
* **Request correlation.** `request_id` ties the audit row to the upstream HTTP request log for end-to-end traceability.

## Three-step audit-prep workflow

For each control your auditor wants evidence on:

### 1. Identify the posture body field that maps to the control

Until the formal control map lands, this is manual. Examples:

| Control concept                                                    | Posture field                                                        |
| ------------------------------------------------------------------ | -------------------------------------------------------------------- |
| *"Anomaly detection runs at least every 15 minutes"*               | `sideband.coherence.cadence_seconds ≤ 900`                           |
| *"Reputation-weighted scoring is enabled for fault-line analysis"* | `sideband.fault_line.use_reputation_scores = true`                   |
| *"Critical findings always trigger advisories"*                    | `sideband.fault_line.severity_floor ∈ {low, medium, high, critical}` |
| *"Cluster partitions across the fleet are flagged"*                | `sideband.fleet.patterns.cluster_partition = true`                   |

The [normative schema](/specifications/trust-posture-schema) is the field reference; pair each control with the field(s) it constrains.

### 2. Pull the point-in-time evidence

Run the SQL pattern above for every team in scope, for every relevant date in the audit window. The output for an auditor is a CSV per team with columns `(team_id, date, posture_id, revision_no, body)` — enough to prove the control held continuously.

### 3. Pull the change log

For the same audit window, dump `governance_audit_log` filtered to `target_type = 'posture'`:

```sql theme={null}
SELECT actor_user_id, actor_role, action, target_id, metadata, before_json, after_json, at
FROM governance_audit_log
WHERE target_type = 'posture'
  AND at BETWEEN $audit_start AND $audit_end
ORDER BY at ASC;
```

This is the "who tightened what, when" timeline. Pair it with the point-in-time evidence and the auditor has the full picture.

## What's deferred

The foundation is in place; the layers above it are on the roadmap:

* **Compliance attestation snapshots** — a one-click "export this posture for SOC 2 evidence" button. Today, the SQL above is the manual equivalent.
* **Compliance framework mapping** — formal SOC 2 / ISO 27001 / HIPAA / EU AI Act control → posture field map.
* **Detection coverage scoring** — "% of fleet with each axis enabled" rolled up to a dashboard tile.
* **Policy-as-code export** — Terraform provider + YAML round-trip.

These are the natural next steps once SOC 2 prep work formalizes. The architecture is intentionally compatible — none of them require changes to posture data model, just additional read paths over the existing rows.

## AEGIS attestation surfaces

Two AEGIS-introduced surfaces extend the attestation foundation:

* **Signed [advisories](/concepts/advisories)** — per-incident published JSON documents with a `synthetic` boolean. Each advisory's lifecycle is recorded in the admin CMS audit log and emits an [`advisory.published`](/api-reference/webhook-events#advisorypublished) webhook on publication. For SOC 2 / EU AI Act / ISO 42001 evidence flows, the advisory list is the authoritative cross-tenant incident record.
* **The Managed Rule signing chain** — [Managed Rules](/concepts/managed-rules) carry Ed25519 per-row promotion signatures (`promotion_signature`); KV and R2 envelopes are independently signed; the gateway verifies on every read. The signing-key escrow + 90-day JWKS rotation overlap is auditable. The wire format reference for downstream evidence systems is at [`/specifications/managed-rule-envelope-schema`](/specifications/managed-rule-envelope-schema).

Both surfaces compose with the posture-versioning attestation primitives this guide otherwise covers — posture revisions + Managed Rule promotions together describe *what detection policy was in force* on date X, *which cross-tenant Managed Rules were active*, *what advisories were live*, and *which signing keys signed each*.

## See also

* [Trust Posture](/concepts/trust-posture) — concept overview
* [Posture versioning](/concepts/posture-versioning) — revisions, rollback, immutability
* [Trust Posture schema](/specifications/trust-posture-schema) — normative field reference
* [Sideband detection](/guides/sideband-detection) — tuning the detectors
* [Posture cloning workflow](/guides/posture-cloning) — clone-and-customize
* [Managed Rules](/concepts/managed-rules) — the AEGIS signed cross-tenant rule pipeline
* [Advisories](/concepts/advisories) — the AEGIS per-incident transparency surface