Skip to main content
The transparency log is an append-only public record of every canonical card identity Mnemom has ever composed. Each row carries a signed AAP attestation token + the Merkle leaf hash + the tree size at integration time. Inclusion proofs are computed on demand from rows ordered by log_index.

​
What it proves

For any historic timestamp t and any agent_id:

​
Endpoints

All three are unauthenticated — the log is meant to be publicly verifiable.

​
GET /v1/transparency/root

Returns the current signed Merkle root + tree size + published_at, signed by the active AAP signing key under a distinct typ (AAP-TransparencyRoot/v1) so the per-card attestation and the root commitment can’t be confused.

​
GET /v1/transparency/log/{agent_id}?at=<ISO>[&card_kind=alignment|protection]

Point-in-time query. Returns the row whose composed_at ≤ at is greatest, plus a freshly-computed inclusion proof against the current root.

​
GET /v1/transparency/log/{agent_id}/{log_index}

Direct by-index lookup; returns the row + an inclusion proof against the current root. Use this when you already know the log_index (e.g., from a previous response).

​
Row shape

Mirrors the schema. One row per canonical card identity:
merkle_leaf_hash = SHA-256(0x00 || canonical_json({agent_id, card_kind, content_hash, version, composed_at})). The 0x00 prefix is the RFC 6962-style domain separator.

​
Append discipline

  • Append-only at the DB role level — the application’s service role has SELECT, INSERT grants on card_attestations. No UPDATE, no DELETE. Append-only is enforced at the role layer, not just at the application layer.
  • Idempotent — unique index on (agent_id, card_kind, content_hash, version) makes re-append a no-op. The compose-hook and the 5-minute reconciler are both safe to retry.
  • Best-effort from the compose path — the canonical write commits first; the log append + signing happen post-commit. A 5-minute reconciler closes any gap that arose from a worker crash mid-flight.

​
Merkle tree

​
Sigstore Rekor compatibility

The row shape is intentionally Sigstore Rekor-shaped so the future migration is a data move rather than a schema rewrite. The mapping is documented in the schema spec and the migration plan at migration/sigstore-rekor-migration. Until that migration ships (post-V1-GA), the thin Postgres log serves as Mnemom’s authoritative public log. Backups land in S3 with object-lock to defend against database compromise + rewrite.

​
See also