Templates use the unified card shape. The JSON/YAML templates on this page use the unified card format — the shape
mnemom card validate and PUT /v1/alignment/agent/{id} both expect. A card copied verbatim from any template below will validate and publish without modification. See Alignment Card Schema for the full normative spec.For protocol-level interop with external agents (A2A, MCP), the AAP 1.0 card uses a different schema and is specified at /concepts/alignment-cards — a separate, still-stable surface that is not submitted to mnemom card validate.Creating a card
An alignment card is a structured document that follows the AAP specification. You can author cards in JSON or YAML — the API accepts both formats and stores cards as JSON internally.Start from the template
Every card requires five blocks: identity, principal, values, autonomy, and audit — plus two top-level master switches (autonomy_mode and integrity_mode) that control action-policing and values verification independently.
- JSON
- YAML
Choose values
Select from the standard value identifiers and add custom values as needed:
For custom values, add a
definitions entry:
Define the autonomy block
List the actions your agent actually takes asbounded_actions. These should match your agent’s real tools and capabilities:
named_entity_critical, purchase_value > 100, shares_personal_data.
Forbidden actions are semantic identifiers, not prose descriptions. Use concrete action names like delete_without_confirmation, not vague phrases like “harmful behavior”.
Set audit commitment
Declare how your agent logs decisions and whether external parties can query traces:Full example: Customer support agent
- JSON
- YAML
Publishing via CLI
Publishing via dashboard
Publishing via API
Update your agent’s alignment card directly with aPUT request to /v1/alignment/agent/{agent_id} — the canonical Resources × Scope × Verb URL. The body is the unified alignment card in YAML (canonical) or JSON. Publishing triggers composition — the server regenerates the agent’s canonical card against platform + org scopes before the response returns.
The older
/v1/agents/{agent_id}/alignment-card URL still works but only 308-redirects here (sunset 2027-01-15). Use the canonical /v1/alignment/agent/{agent_id} directly.Idempotency-Key so retries are safe to replay.
Who can publish. Publishing is authorized by organization membership, not by who originally claimed the agent. Any member of the organization that governs the agent — role
owner, admin, or member — can publish its cards, so teammates can manage shared agents without re-claiming them. You never pass an organization id: the server derives it from the agent. A caller who is not a member of the agent’s org receives 403 Forbidden with code agent_org_forbidden, naming both the org and the agent.?include_composition=true to include the _composition metadata block showing which scope contributed which fields.
Organization card templates (Enterprise)
Organization card templates require an Enterprise plan. Contact sales to enable this feature.
How composition works
When an org template is active, the canonical card for each agent is computed by composing the org template with the agent’s individual card:- Values: Org values are always included. Agent values are added on top. Agents cannot remove org values.
- Forbidden actions: Org forbidden actions are always included. Agents can add more but cannot remove any.
- Bounded actions: Agent-specific. The org template does not restrict which actions an agent can take.
- Escalation triggers: Org triggers are always included. Agents can add more.
- Audit commitment: Org audit commitment is the floor. Agents can increase retention or add capabilities but cannot weaken audit requirements.
Setting up
- Navigate to Organization Settings in the dashboard
- Open the Alignment Card Template section
- Enable the org template toggle
- Configure your base card using the visual or JSON editor
- Save — all agents in the org immediately inherit the template
Agent exemptions
In rare cases, an agent may need to be exempt from the org template. Exemptions require:- A double-confirm flow in the dashboard (confirm intent, then confirm again with reason)
- A written reason that is stored in the audit trail
- Owner or admin role
Validation rules
Reference table of all validation checks performed duringmnemom card validate and on publish:
Warnings do not prevent publishing but are reported in validation output. Fix warnings to improve verification quality.
Policy integration
Policy is now part of the alignment card itself. The unified schema includes capability mappings, forbidden rules, and enforcement defaults directly in the card:- Card defines capabilities: Your card’s
autonomy.bounded_actionslists semantic categories likeweb_fetch,read,write - Card maps tools: The
capabilitiessection maps concrete tool names (likemcp__browser__*) to those card categories - Card defines enforcement: The
enforcementsection sets the mode (observe/warn/enforce) and defaults for unmapped tools - Evaluation bridges all three:
mnemom card evaluatechecks that every tool maps to a declared bounded action
bounded_actions and the tool-to-capability mapping in capabilities. The 24-hour grace period gives you time to make these updates after new tools are first observed.
Amendment tracking
Every card update creates a formal amendment with version history and diffs. Amendments can be linked to reclassification requests — proving that a violation was caused by a card gap rather than agent misbehavior. See Card Lifecycle for details.Best practices
Version control your cards
Keep alignment card files (JSON or YAML) in your repository alongside your agent code. Use
mnemom card validate in CI to catch issues before deploy.Match bounded actions to real tools
Your
bounded_actions list should reflect your agent’s actual tools and capabilities. Adding actions the agent never takes produces noise; missing actions the agent does take produces false violations.Set meaningful expiry dates
A 6-month expiration is typical. Shorter lifetimes increase operational overhead; longer lifetimes risk the card becoming stale relative to actual behavior.
Use escalation triggers for real decisions
Escalation triggers are the card’s most actionable component. Define triggers for situations where your agent genuinely needs human approval, not aspirational conditions.
Define custom values precisely
Every custom value needs a clear
description in the definitions block. Vague definitions lead to inconsistent verification results.Review cards after capability changes
When you add or remove tools from your agent, update the alignment card and policy to match. Stale cards produce misleading integrity scores.
See also
- Alignment Cards concept — Full specification of card structure and semantics
- Card Lifecycle — Amendment tracking, reclassification, and trust recovery
- Policy Management — Policy setup alongside card management
- CLI Reference —
mnemom card show,card publish, andcard validatecommands - Organization Card Templates — Org-level card policies (Enterprise)
- AAP Specification — Normative protocol specification