Top-level structure
Master switches
The four-mode enumoff | observe | nudge | enforce is shared with the Protection Card. Same words; same semantics; same UI picker component renders all three master fields (Protection’s mode, Alignment’s autonomy_mode, Alignment’s integrity_mode). Composition rule on each: strictest wins across Platform → Org → Agent (enforce > nudge > observe > off).
Customers can control the two halves independently — e.g., “enforce conscience commitments at runtime, only observe action policy” or “off action-policing for cost, but enforce drift detection”.
§principal
Declares who the agent serves and the nature of that relationship.
*
identifier is required when type != unspecified.
§values
What the agent prioritizes. Core input to the v2 coherence scorer and to fault-line analysis.
Validation: every
definitions key must be present in declared.
Composition note: bounded_actions is composed as union across Platform → Org → Agent. (An earlier draft of this spec said “Agent-scoped” — that was incorrect; the unified card was always intended to let platform/org compose action sets, e.g. an org-wide request_legal_review action.)
§conscience
Inviolable or near-inviolable commitments that constrain the agent’s behavior. Structured for Safe House + drift detection integration.
Validation:
BOUNDARY entries with severity: advisory are rejected.
§autonomy
What the agent may do independently. Maps directly onto the AAP 1.0autonomy_envelope for protocol-level verification — the unified shape renames it but keeps the semantics.
Validation:
bounded_actions and forbidden_actions must be disjoint (no action in both).
§capabilities
Tool-use capabilities, keyed by capability name. Each entry maps to a glob pattern over MCP/A2A tool names or an explicit tool allowlist.
Capabilities are consumed by
@mnemom/policy-engine’s evaluatePolicy({ card, tools }) to produce per-request policy decisions.
§enforcement
Policy-level knobs that affect howcapabilities are enforced at runtime. The master switch lives at the top level (autonomy_mode); this section carries the fine-grained tool-use policy.
§audit
Commitments around trace format, retention, tamper evidence. These are platform-scoped — agents and orgs cannot weaken the audit floor.
Validation:
audit.query_endpoint is a composer-enforced invariant. The validator rejects cards without it; the composer ensures it’s always present on canonical output.
§extensions
Protocol-specific or user-defined additions. Free-formRecord<string, unknown>. Mnemom reserves the clpi.* and mnemom.* namespaces.
_composition.extensions_composition_mode: merge.
§_composition (canonical-only)
Present on the canonical card, absent on raw agent-scope cards. Records the provenance of every composed field._composition is read-only on the wire. Mutating it via API is a 400.
YAML safe schema
Allyaml.load() calls in the Mnemom stack use { schema: yaml.CORE_SCHEMA } — Node-specific tags (!!js, !!binary, etc.) are rejected. If your client produces YAML with those tags, validation fails. Stick to plain scalars, maps, and sequences.
Body-size limits
- Full alignment card payload: 128 KB max (Content-Length + rawBody double-check).
values.declared: recommended under 200 values per scope for coherence-scoring performance.
413 Payload Too Large for oversize bodies; no grace period. If a legitimate card is getting 413’d, file an issue — the limits are currently conservative and will relax with production data.
Versioning
card_version is a date-anchored schema identifier. Accepted values as of 2026-04-17:
unified/2026-04-15— current. All canonical cards emit this version.- (legacy) — the legacy AAP-shape card is no longer accepted at the alignment-card endpoint. Convert via the migration script before publishing.
X-Mnemom-Version request-header mechanism used elsewhere in the API.
See also
- Agent Cards — the two-card product story
- Card Composition — scope composition rules + exemptions
- Protection Card Schema — companion normative spec
- Alignment Card (AAP 1.0 surface) — the protocol-level card
- Policy Engine — how
capabilities+enforcementbecome runtime policy