Skip to main content
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.
Phase 5 — External Readiness extends compliance evidence with cryptographic durability. Every canonical card composition is recorded in the transparency log with a signed AAP attestation token 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 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.

​
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:
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), 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:
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: The normative 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).

​
AEGIS attestation surfaces

AEGIS adds one surface to the attestation foundation:
  • The Managed Rule signing chain — the active 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.
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