> ## 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. The revision history API answers 'what was our detection policy on date X'.

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: posture data and its revision history, which you can already pull as audit evidence. Mapping a specific control to a specific posture field is manual today (see the table below) -- there is no formal, published control-to-field catalog yet.

<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`, `posture.delete`, `team_posture.assign`, and `team_posture.unassign` is recorded with the actor, the before/after body, and an idempotency key — the source of truth for "who changed what, when." This internal audit trail isn't exposed through a documented export endpoint today; what you can pull yourself is the revision history below, plus each revision's `change_summary`.

## Point-in-time queries

The queryable answer to "what was this posture's body on 2026-03-31" comes from the revision history API:

```bash theme={null}
curl -H "X-Mnemom-Api-Key: $MNEMOM_API_KEY" \
  "https://api.mnemom.ai/v1/postures/{posture_id}/revisions"
```

This returns every revision, chronologically, each with `revision_no`, `body`, `change_summary`, `authored_by`, and `authored_at`. For a floating team (the default -- see [Posture versioning](/concepts/posture-versioning)), the answer for a given date is the revision with the latest `authored_at` at or before that date. For a team pinned to a specific revision, fetch it directly:

```bash theme={null}
curl -H "X-Mnemom-Api-Key: $MNEMOM_API_KEY" \
  "https://api.mnemom.ai/v1/postures/{posture_id}/revisions/{revision_number}"
```

A team's current assignment (which posture, and whether it's floating or pinned) shows on its dashboard detail page and via `GET /v1/teams/{team_id}/effective-posture`.

## Audit-prep workflow

For each control your auditor wants evidence on:

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

Until a formal control map ships, 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

Call the revision-history endpoint above for every posture in scope. The `change_summary` on each revision is the load-bearing answer for "why did this change" -- write one on every edit (see [Posture Cloning](/guides/posture-cloning#common-pitfalls)).

## AEGIS attestation surfaces

AEGIS adds one surface to the attestation foundation:

* **The Managed Rule signing chain** — the active [Managed Rules](/concepts/managed-rules) are delivered as primary and secondary storage-tier envelopes, each signed with its own Ed25519 key; the gateway verifies the envelope on every read. Promoted rows also carry a per-row `promotion_signature` for provenance. The wire format reference for downstream evidence systems is at [Managed Rule envelope schema](/specifications/managed-rule-envelope-schema).

It composes with the posture-versioning attestation primitives this guide otherwise covers — posture revisions and Managed Rule promotions together describe *what detection policy was in force* on date X and *which Managed Rules were active*.

## 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 detection rule set


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.