Skip to main content
CLPI is Mnemom’s governance layer — a set of systems, built on top of the alignment card, 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.
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 itself is not gated this way; it runs for every agent regardless of plan. Contact sales to enable the entitled capabilities.

​
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 flags it as an unmapped-tool violation because there’s no capability mapping for it.
  4. The agent’s trust score 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 and AIP 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.

​
What’s in CLPI

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.

Reclassification & 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.

Fleet Intelligence

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).

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.

​
Checkpoint anchoring

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.
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

​
See also