Skip to main content
Every Mnemom agent has two cards — alignment and protection. Both compose from up to four scopes: platform, org, team (optional), agent. This page documents the composition rules, the canonical-card mechanism, and how exemptions change the computation.
Team scope is optional. Solo agents (in zero teams) compose under the 3-layer cascade platform → org → agent — the historical shape, unchanged. Teamed agents compose under platform → org → {team₁, …, tₙ} → agent. See Team Scope for the team layer’s mechanics; the rest of this page covers the rules that apply at every layer present.

Why composition exists

Previously, card merging happened per request. The gateway would fetch an agent card, an org template, and a CLPI policy, then run mergeOrgAndAgentCard() and mergePolicies() on every inbound call. That cost real latency, scattered merge logic across services, and made it hard to answer “what does this agent’s effective card actually look like?” Composition moves the merge to storage time. When an agent’s scope-level card, org template, platform policy, or exemption list changes, a background job (compose_agent_card, compose_protection_card) computes the canonical card — the fully-merged, fully-resolved, ready-to-serve document — and writes it to canonical_agent_cards or canonical_protection_cards. Every gateway and observer read hits the canonical table, not the raw scope rows. The request path has zero merge cost.

The scopes

Scope ordering is platform → org → (team)? → agent. The team layer is conditional: agents in zero teams compose under the 3-layer cascade; agents in one or more teams pick up a Team layer between Org and Agent. Multi-team agents fold strictest-wins across all their teams. See Team Scope for details. Later scopes apply over earlier scopes according to the per-field rules below. The same rules apply with 0, 1, or N team layers present — the composer’s strictest-wins idiom is variadic.

Field-level composition rules

Composition is not a single blended operation. Each card section has its own merge semantic chosen to match its governance intent: Composition metadata (_composition) on the canonical card records which scopes contributed which fields, so downstream readers can debug “where did this value come from?”

Exemptions

An exemption waives a specific org- or platform-scope field for a specific agent, with explicit justification and expiry. Exemptions replace the legacy boolean org_card_exempt flag, which was an all-or-nothing escape hatch.

Structure

Rules

  • Exemptions are section-specific. A single exemption targets one field or pattern-scoped subset, not the whole card.
  • Exemptions are audit-logged synchronously on grant and revocation. Every composition that honors an exemption is traceable.
  • Exemptions expire (default 90 days). The composer refuses to honor an expired exemption; the next recompose quietly drops it.
  • Exemptions on BOUNDARY conscience entries are rejected at the API layer. Inviolable commitments cannot be waived.

Composition with exemptions

When the composer runs:
  1. Compute the scope union (platform + org) for each field.
  2. For each active exemption, subtract the exempted patterns from the scope union before applying agent-scope.
  3. Apply agent-scope per the normal rules.
  4. Record the exemption reference in _composition.exemptions_applied[].

The canonical card

The canonical card is the output of composition:
card_yaml is what the CLI and dashboard surface as the “card this agent is running.” card_json is what the gateway reads for policy evaluation (faster than re-parsing YAML on every request).

The recompose pipeline

Composition runs in response to events:

Staleness window

Between an org-template change and the recompose worker finishing, the canonical card is stale. The gateway handles this with the needs_recompose KV bypass: when the canonical row flag is true, the gateway serves the canonical without populating the 5-minute KV cache, so the next change after recompose is seen immediately. For a sub-50-agent org, recompose completes in under 2 seconds. For 10k+ agents, the background worker paces the batch to avoid saturating downstream services.

Worked example: three-scope composition

Scenario: Acme Corp has an agent mnm-patch-001 (a deploy remediation agent).

Platform scope

Org scope (Acme Corp)

Agent scope (mnm-patch-001)

Composed canonical card

Note the agent’s integrity_mode: observe was silently overridden to enforce by the org. The composition metadata makes this traceable — not hidden. The protection card composes separately. The protected_surface entries carry source_scope stamped at the highest scope that declared them — so the agent cannot claim provenance of an org rule:

Debugging composition

CLI

mnemom card show always renders the canonical composed card. The _composition metadata block, the raw agent-scope row, and per-field scope provenance are not surfaced by the CLI today — use the API below.

API

Observer

Every gateway + observer card read emits a structured log entry with card_source: canonical_hit (or canonical_miss_fallback in the rare case the canonical row is missing and the composer is still catching up). The production criterion is that the fallback rate is zero on production traffic.

Trust Posture is a parallel cascade, not nested

Cards compose along Platform → Org → Team → Agent. Trust Posture — the team-scoped oversight policy artifact — composes along its own parallel cascade Platform → Org → Team and does NOT fold into the per-agent card. Postures and cards are parallel artifact types: postures are team-scoped policy input (drives the observer’s sideband sweep), cards are agent-scoped runtime treatment (read by the gateway at request time). They share infrastructure (this composer idiom, KV caching, audit log) but their data planes are independent. Practically:
  • An advisory written by a posture-driven detector lands in pending_advisories tagged with source: sideband.{coherence,fault_line,fleet}. The gateway picks it up on the next turn for an affected agent and lets card-driven enforcement decide the runtime treatment.
  • The posture cascade has no agent leaf because postures are inherently fleet-level (they observe a group, not an individual).
  • Composing a posture into the canonical card is intentionally not supported — see Posture vs. Cards for the design rationale.

See also