> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mnemom.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# CLPI: Card Lifecycle & Policy Intelligence

> The governance layer built on top of alignment cards: policy enforcement, violation reclassification and trust recovery, fleet intelligence, and checkpoint anchoring

CLPI is Mnemom's governance layer — a set of systems, built on top of the [alignment card](/concepts/alignment-cards), that turn a card from a static declaration into something with lifecycle management: policy enforcement, violation reclassification, fleet-level intelligence, and tamper-evident checkpoint anchoring.

<Note>
  Most of CLPI sits behind enterprise-tier entitlement flags (`clpi_fault_lines`, `clpi_risk_forecast`, `clpi_policy_recommendations`, `clpi_transactions`, `clpi_reclassification`, `clpi_on_chain`, `clpi_export`) — they are off by default and enabled per contract. The [policy engine](/concepts/policy-engine) itself is not gated this way; it runs for every agent regardless of plan. Contact [sales](https://mnemom.ai/pricing) to enable the entitled capabilities.
</Note>

## The problem CLPI solves

Without CLPI, a common failure mode undermines trust scores:

1. An operator adds a new MCP server to an agent (e.g., a browser tool).
2. The alignment card is not updated to declare the new capability.
3. The agent uses the tool correctly, but the [policy engine](/concepts/policy-engine) flags it as an unmapped-tool violation because there's no capability mapping for it.
4. The agent's [trust score](/concepts/reputation-scores) drops — even though the agent did nothing wrong.

This is **configuration drift**: the card falls out of sync with the agent's actual capabilities. CLPI addresses this by letting an operator reclassify a checkpoint's verdict once the drift is understood, recovering the score, rather than leaving a false violation permanently on the record.

## How CLPI relates to AAP and AIP

[AAP](/protocols/aap/specification) and [AIP](/protocols/aip/specification) are **detection protocols** — they identify misalignment and compromise. CLPI is the **governance layer** that enforces policy up front and lets an operator correct the record afterward.

| | AAP | AIP | CLPI |
| - | - | - | - |
| **Role** | Post-hoc verification | Per-turn integrity | Policy enforcement + reclassification |
| **Catches** | Behavioral drift over time | Active attacks in progress | Configuration drift, tool-use policy violations |
| **Mechanism** | Alignment Cards + AP-Traces | Thinking block analysis | Card `capabilities`/`enforcement` sections + checkpoint reclassification |
| **When** | After the agent acts | While the agent thinks | At request time (policy) and after the fact (reclassification) |

## What's in CLPI

<CardGroup cols={2}>
  <Card title="Policy Engine" icon="shield-halved" href="/concepts/policy-engine">
    Governance-as-code, always on. Card `capabilities` + `enforcement` sections map declared actions to concrete tools, define forbidden patterns, and set the unmapped-tool default — evaluated in CI/CD (`mnemom card evaluate`), at the gateway on every request, and post-hoc by the observer.
  </Card>

  <Card title="Reclassification & Trust Recovery" icon="arrows-spin" href="/guides/trust-recovery">
    `POST /v1/agents/{id}/reclassify` changes an `integrity_checkpoints` verdict (`clear` / `review_needed` / `boundary_violation`) after review — the path for correcting a false violation caused by a card gap rather than genuine misbehavior, which recomputes the agent's reputation score. `GET /v1/agents/{id}/reclassifications` lists the history. Entitlement: `clpi_reclassification`.
  </Card>

  <Card title="Fleet Intelligence" icon="chart-mixed" href="/api-reference/endpoint/post-teams-fault-lines">
    `POST /v1/teams/fault-lines` identifies value-conflict fault lines across a team; `POST /v1/teams/recommend-policy` generates policy-rule suggestions from team analysis; `POST /v1/transactions` scopes enforcement to a single bounded operation. Entitlements: `clpi_fault_lines`, `clpi_policy_recommendations`, `clpi_transactions` (risk forecasting is a related, separately entitled capability — `clpi_risk_forecast`).
  </Card>

  <Card title="Checkpoint Anchoring" icon="link" href="#checkpoint-anchoring">
    Merkle-root checkpointing over an agent's integrity history, with signed attestation and an inclusion-proof verification endpoint. Entitlement: `clpi_on_chain`. See the caveats below before treating this as a public-chain guarantee.
  </Card>
</CardGroup>

## Checkpoint anchoring

<Warning>
  This is the one area where the marketing shorthand ("on-chain", "Base L2") has run ahead of what the shipped endpoints actually check. Read this section before relying on anchoring for a compliance claim.
</Warning>

What's real today:

* The platform computes a Merkle root over an agent's checkpoint leaves and records it, along with a leaf count and tree depth, in Mnemom's own database (`on_chain_anchors` / `score_publications` tables) — not by reading it back from a blockchain.
* `GET /v1/on-chain/verify-proof/{agent_id}` **recomputes** the root from the stored leaf hashes, checks the leaf count against the leaf array, and — given a `leaf_index` — regenerates and verifies a real inclusion proof against the recomputed root. A mismatch at any step returns `verified: false` with a reason; the endpoint never reports a bare `verified: true` without doing this work.
* What that endpoint does **not** yet do is read the anchored root back from a chain. The response is explicit about this via `verification.anchored_root_source`: it proves the tree Mnemom published is internally consistent and matches the root Mnemom recorded as anchored — it does not prove a chain agrees with that record. Publishing to a public chain such that a third party can verify without trusting Mnemom's infrastructure at all is a stated direction, not a delivered guarantee today.
* `GET /v1/on-chain/status/{agent_id}` and `GET /v1/on-chain/history` are read-only and public; writing an anchor record is a service-key operation the platform performs on its own schedule, not something a customer calls directly.

Treat checkpoint anchoring as tamper-evident bookkeeping backed by cryptographic hashing today, and as a building block toward independent chain verification — not as an existing "verify without trusting Mnemom" guarantee.

## API surface

| Area | Overview | Key operations |
| - | - | - |
| Policy | [Policy API](/api-reference/policy-overview) | Evaluate tools against a card (`/v1/policies/evaluate`, `/v1/policies/evaluate/historical`) |
| Reclassification | [Reclassification API](/api-reference/reclassification-overview) | Reclassify a checkpoint, list reclassification history, recompute scores |
| Intelligence | [Intelligence API](/api-reference/intelligence-overview) | Fault lines, risk forecast, policy recommendations, transaction guardrails |
| Checkpoint anchoring | [On-Chain API](/api-reference/on-chain-overview) | Read anchor status, verify an inclusion proof, read anchoring history |

## See also

* [Policy Engine](/concepts/policy-engine) — the always-on governance-as-code layer
* [Trust Recovery guide](/guides/trust-recovery) — reclassifying violations and recovering trust scores
* [Reputation Scores](/concepts/reputation-scores) — how trust scores are computed and how reclassification affects them
* [Alignment Card Schema](/specifications/alignment-card-schema) — the normative unified card schema CLPI operates on


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.