Skip to main content
CLPI is Mnemom’s governance layer — a 5-phase system that transforms alignment cards from static declarations into lifecycle-managed artifacts with policy enforcement, trust recovery, risk intelligence, and on-chain anchoring.

​
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
  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. The result is false violations, unfair score declines, and eroded trust in the scoring system itself. CLPI fixes this by distinguishing configuration errors from behavioral failures, enabling trust recovery when the card was wrong, and providing governance-as-code to prevent drift in the first place.

​
How CLPI relates to AAP and AIP

AAP and AIP are detection protocols — they identify misalignment and compromise. CLPI is the governance layer that prevents problems, recovers from false positives, and anchors trust on-chain. Together: AAP and AIP detect problems. CLPI prevents them and recovers from them.

​
The 5 phases

1

Phase 1: Policy Engine

Governance-as-code. A declarative YAML-based DSL that bridges alignment card capabilities to concrete tool enforcement. Policies define which tools map to card capabilities, what is forbidden, and how unmapped tools are handled — evaluated in CI/CD, at the gateway, and post-action.Policy Engine concepts | Policy DSL spec | Policy CLI
2

Phase 2: Card Lifecycle & Trust Recovery

Alignment cards become lifecycle-managed artifacts with versioned amendments, violation reclassification (card_gap vs. behavior_gap), automatic score recovery, session re-proofing, and compliance export. When a violation was caused by a missing capability — not agent misbehavior — the score recovers.Card Lifecycle concepts | Trust Recovery guide
3

Phase 3: Intelligence Layer

Analytical capabilities on top of policy and reputation data. Fault line analysis identifies value conflicts across teams. Risk forecasting predicts failure modes. LLM-powered policy recommendations generate governance rules from team analysis. Transaction guardrails scope enforcement to individual operations.Intelligence API
4

Phase 4: On-Chain Verification

Immutable reputation anchoring on Base L2. Merkle roots from the integrity checkpoint tree are anchored to the MnemoMerkleAnchor contract. Reputation scores are published to the MnemoReputationRegistry. Any third party can verify an agent’s score without trusting Mnemom’s infrastructure.On-Chain Verification concepts | On-Chain guide
5

Phase 5: Observability

OpenTelemetry integration for the full governance pipeline. Policy evaluation spans, reclassification spans, and policy-aware drift detection — all exported to any OTel-compatible backend. See Observability guide and OTel attributes spec.

​
CLPI sub-pages

Policy Engine

Phase 1. Governance-as-code: capability mappings, forbidden rules, enforcement modes, and policy merge.

Card Lifecycle

Phase 2. Amendments, violation reclassification, trust recovery, score recomputation, and compliance export.

Trust Recovery Guide

Step-by-step workflow for reclassifying violations and recovering trust scores.

On-Chain Verification

Phase 4. Merkle root anchoring and reputation publishing on Base L2.

Observability

Phase 5. OTel spans for policy evaluation, reclassification, and drift detection.

Policy Management Guide

Writing, deploying, and iterating on governance policies.

​
API surface

CLPI spans four API domains:

​
See also