> ## 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. # Mnemom Trust Rating > The Mnemom Trust Rating™ — a credit score for AI agents. A composite trust metric built from integrity checkpoints, drift stability, trace completeness, and fleet coherence. ## Overview The Mnemom Trust Rating™ is a **composite trust metric for AI agents** — the equivalent of a credit score, but for autonomous software. It answers a question no other system answers: *Based on independently verified behavioral evidence, how trustworthy is this agent?* Unlike self-reported trust claims or capability benchmarks, the Mnemom Trust Rating is: * **Independently verified** — Scores are computed from [AIP integrity checkpoints](/concepts/integrity-checkpoints), not self-assessments * **Continuous** — Updated every 6 hours from live behavioral data, not point-in-time audits * **Transparent** — Every component, weight, and data source is published and inspectable * **Cryptographically provable** — The underlying checkpoints are [signed and Merkle-attested](/protocols/aip/certificates) * **Multi-dimensional** — Five weighted components capture different aspects of trustworthiness Mnemom Trust Ratings power trust decisions across the AI agent ecosystem: pre-interaction trust checks, fleet governance policies, compliance reporting, marketplace listings, and inter-agent delegation via [A2A](/protocols/aap/a2a-integration). The Mnemom Trust Rating requires a minimum of **50 analyzed integrity checkpoints** before a public score is published. This minimum prevents gaming through selective checkpoint submission and ensures statistical significance. Checkpoints where the thinking block contains fewer than 100 tokens receive a synthetic `clear` verdict and are excluded from the analyzed checkpoint count. This means an agent's total checkpoint count may differ from its analyzed checkpoint count — only substantive thinking analysis counts toward the 50-checkpoint eligibility minimum and the Integrity Ratio calculation. *** ## Score range and grades Scores range from **0 to 1000** and map to letter grades inspired by bond credit ratings. Higher scores indicate stronger demonstrated trustworthiness. | Grade | Score Range | Tier | Meaning | | - | - | - | - | | **AAA** | 900 -- 1000 | Exemplary | Consistently demonstrates exceptional alignment. Highest tier of independently verified trust. | | **AA** | 800 -- 899 | Established | Strong track record with minimal violations. Trusted for high-stakes autonomous operations. | | **A** | 700 -- 799 | Reliable | Solid behavioral record with occasional minor concerns. Suitable for standard autonomous tasks. | | **BBB** | 600 -- 699 | Developing | Building a track record. Some violations or drift events, but trending positively. | | **BB** | 500 -- 599 | Emerging | Limited or mixed track record. More data needed for confident assessment. | | **B** | 400 -- 499 | Concerning | Elevated violation rate or significant drift. Active remediation recommended. | | **CCC** | 200 -- 399 | Critical | Serious integrity concerns. Human oversight strongly recommended for all operations. | | **NR** | -- | Not Rated | Fewer than 50 analyzed checkpoints. Score is being built. | The grade system is deliberately conservative. An "AAA" rating is rare and requires sustained exemplary behavior across all five components. Most well-maintained agents stabilize in the A to AA range. *** ## Score components The composite score is a weighted sum of five normalized components, each scored 0 -- 1000: ``` S = w_1 * integrity_ratio + w_2 * compliance + w_3 * drift_stability + w_4 * trace_completeness + w_5 * coherence_compatibility ``` ### Integrity ratio (40%) The dominant component. Measures the proportion of integrity checkpoints that returned a `clear` verdict. ``` integrity_ratio = (clear_count / analyzed_count) * 1000 ``` Only protocol-verified [AIP checkpoints](/concepts/integrity-checkpoints) are counted. Unanalyzed checkpoints (those below the 100-token minimum evidence threshold) are excluded from both numerator and denominator. * **Data source:** AIP checkpoints * **Update frequency:** Every new checkpoint * **Improvement lever:** Fix alignment card violations, resolve `review_needed` checkpoints ### Compliance (20%) Measures boundary adherence using a session-capped power curve. Violations are grouped by session — only the worst violation per session counts — then scored with a **1-week half-life** decay. This prevents a single bad session (e.g., a busted alignment card producing multiple false-positive violations) from catastrophically cratering the score. ``` score = 1000 / (1 + Σ max_impact_per_session)^1.5 ``` The power curve degrades meaningfully but never craters to zero from moderate violation counts, preserving signal differentiation across the full range. After [reclassification](/concepts/card-lifecycle), violations classified as `card_gap` are **excluded** from the compliance calculation. Only `behavior_gap` violations (genuine behavioral errors) count. This enables [trust recovery](/guides/trust-recovery) when violations were caused by configuration drift rather than agent misbehavior. * **Data source:** AIP checkpoints with `boundary_violation` verdict, grouped by `session_id` * **Update frequency:** Every 6 hours * **Improvement lever:** Time without new violations; resolve root causes to prevent recurrence; [reclassify card-gap violations](/guides/trust-recovery) ### Drift stability (20%) Measures the proportion of sessions where no sustained [drift alert](/concepts/drift-detection) was triggered. ``` drift_stability = (stable_sessions / total_sessions) * 1000 ``` A session is "stable" if the agent maintained consistent behavioral similarity to its baseline throughout the session. Sessions where 3+ consecutive checkpoints fell below the drift threshold are counted as unstable. * **Data source:** AIP drift detection * **Update frequency:** End of each session * **Improvement lever:** Consistent values application, avoid aggressive behavioral pattern changes ### Trace completeness (10%) Measures audit trail quality -- the ratio of decisions that were logged as [AP-Traces](/concepts/ap-traces) versus expected decisions. ``` trace_completeness = (logged_decisions / expected_decisions) * 1000 ``` Agents that log every decision create a complete audit trail. Gaps in trace coverage reduce this component. * **Data source:** AAP traces * **Update frequency:** Every 6 hours * **Improvement lever:** Ensure all agent decisions are logged via AAP ### Coherence compatibility (10%) Reserved for the mean [coherence score](/concepts/value-coherence) across fleet interactions, normalized to the 0 -- 1000 scale. As of this writing the scoring function has not yet wired in live fleet-coherence data: every agent's Coherence Compatibility component is a **fixed 750**, with the score row's own factor text reporting `"Default score — fleet coherence data not yet integrated"`. ``` coherence_compatibility = 750 # fixed, pending fleet-coherence integration ``` Because this component is currently constant across all agents, it does not yet differentiate scores — the effective composite today is driven by the other four components. Once fleet-coherence data is wired in, this section will describe the live formula. * **Data source:** [Fleet coherence](/concepts/fleet-coherence) analysis (not yet integrated into the score) * **Update frequency:** N/A (fixed value today) * **Improvement lever:** None today -- this component cannot currently be moved above 750 *** ## Confidence levels The number of analyzed checkpoints determines the confidence level displayed alongside the score: | Confidence | Checkpoint Count | Display | | - | - | - | | **Insufficient** | \< 50 | Score not published (NR grade) | | **Low** | ≥50 and \<200 | "Low Confidence" indicator | | **Medium** | ≥200 and \<1,000 | "Medium Confidence" indicator | | **High** | ≥1,000 | "High Confidence" indicator | Confidence communicates how much behavioral evidence supports the score. A score of 800 with "Low Confidence" (60 checkpoints) carries less weight than a score of 780 with "High Confidence" (2,000 checkpoints). The 50-checkpoint minimum is a hard gate for score publication. Agents below this threshold display an "NR" (Not Rated) badge with a progress indicator showing how many checkpoints remain until eligibility. *** ## Score computation ### Frequency * **6-hour recomputation:** Scores are recalculated every 6 hours from the latest behavioral data * **Weekly snapshots:** A frozen snapshot is saved each week for historical trend tracking. Snapshots are created every Monday at 00:00 UTC. * **On-demand:** The API always returns the most recently computed score ### Anti-gaming measures The scoring methodology includes several protections against manipulation: 1. **Minimum checkpoint count** -- 50 analyzed checkpoints required before score publication prevents agents from cherry-picking favorable interactions 2. **Synthetic checkpoint detection** -- Checkpoints with abnormally uniform patterns or machine-generated timing signatures are flagged and excluded 3. **Rate limiting** -- Checkpoint submission rates are monitored per agent; anomalous bursts are throttled 4. **Independent verification** -- All checkpoints are analyzed by a separate LLM (the daimonion), not the agent itself ### Trend tracking Every `ReputationScore` includes a `trend_30d` field -- a signed delta comparing the current score to 30 days ago. This enables at-a-glance trajectory assessment: * **Positive trend (+):** Score is improving * **Negative trend (-):** Score is declining * **Flat trend (0):** Score is stable *** ## SDK usage ### TypeScript The [`@mnemom/reputation`](https://www.npmjs.com/package/@mnemom/reputation) package wraps the public endpoint and adds a reputation gate helper. It does not currently export a history helper or grade/confidence formatters -- fetch history with a plain request. ```typescript theme={null} import { getReputation, createReputationGate } from '@mnemom/reputation'; // Get current reputation for any agent const reputation = await getReputation('agent-xyz'); console.log(`Score: ${reputation.score}`); console.log(`Grade: ${reputation.grade} (${reputation.tier})`); console.log(`Confidence: ${reputation.confidence}`); console.log(`30-day trend: ${reputation.trend_30d > 0 ? '+' : ''}${reputation.trend_30d}`); // Inspect components for (const component of reputation.components) { console.log(` ${component.label}: ${component.score}/1000 (weight: ${component.weight})`); } // Gate a decision on a minimum score or grade const gate = createReputationGate({ minScore: 600, minGrade: 'BBB' }); const result = await gate.check('agent-xyz'); if (!result.allowed) { console.log('Denied:', result.reason); } ``` Weekly history has no dedicated SDK helper today -- call the endpoint directly: ```typescript theme={null} const history = await fetch('https://api.mnemom.ai/v1/reputation/agent-xyz/history') .then(r => r.json()); for (const snapshot of history.snapshots) { console.log(`${snapshot.week_start}: ${snapshot.score} (${snapshot.grade})`); } ``` ### Python ```python theme={null} import httpx API_BASE = "https://api.mnemom.ai" # Get current reputation for any agent (public endpoint) response = httpx.get(f"{API_BASE}/v1/reputation/agent-xyz") reputation = response.json() print(f"Score: {reputation['score']}") print(f"Grade: {reputation['grade']} ({reputation['tier']})") print(f"Confidence: {reputation['confidence']}") print(f"30-day trend: {reputation['trend_30d']:+d}") for component in reputation["components"]: print(f" {component['label']}: {component['score']}/1000 (weight: {component['weight']})") # Get weekly history history_response = httpx.get(f"{API_BASE}/v1/reputation/agent-xyz/history") for snapshot in history_response.json()["snapshots"]: print(f"{snapshot['week_start']}: {snapshot['score']} ({snapshot['grade']})") ``` *** ## API reference The primary endpoint for fetching reputation data: ``` GET /v1/reputation/{agent_id} ``` No authentication required. Returns the full score with all components. **Response:** ```json theme={null} { "agent_id": "agent-xyz", "score": 818, "grade": "AA", "tier": "Established", "is_eligible": true, "checkpoint_count": 347, "confidence": "medium", "components": [ { "key": "integrity_ratio", "label": "Integrity Ratio", "score": 920, "weight": 0.40, "weighted_score": 368, "factors": ["97.2% clear verdict rate across 347 checkpoints"] }, { "key": "compliance", "label": "Compliance", "score": 850, "weight": 0.20, "weighted_score": 170, "factors": ["3 violations across 2 sessions (session-capped), effective impact: 0.52"] }, { "key": "drift_stability", "label": "Drift Stability", "score": 700, "weight": 0.20, "weighted_score": 140, "factors": ["2 drift events across 28 sessions"] }, { "key": "trace_completeness", "label": "Trace Completeness", "score": 650, "weight": 0.10, "weighted_score": 65, "factors": ["65% of expected decisions logged"] }, { "key": "coherence_compatibility", "label": "Coherence Compatibility", "score": 750, "weight": 0.10, "weighted_score": 75, "factors": ["Default score — fleet coherence data not yet integrated"] } ], "computed_at": "2026-02-21T14:00:00.000Z", "trend_30d": 12, "visibility": "public" } ``` For the complete API reference including batch, search, compare, and benchmark endpoints, see the [Reputation API Overview](/api-reference/reputation-overview). *** ## Use cases ### Pre-interaction trust checks Before delegating a task to another agent via A2A, check their reputation: ```typescript theme={null} import { getReputation } from '@mnemom/reputation'; let reputation; try { reputation = await getReputation(theirAgentId); } catch { // not found, private, or unreachable -- treat as insufficient } if (!reputation || reputation.grade === 'CCC' || reputation.grade === 'NR') { return escalateToPrincipal({ reason: `Agent ${theirAgentId} has insufficient trust rating (${reputation?.grade ?? 'NR'})`, }); } // Proceed with delegation return executeDelegation(theirCard, task); ``` ### Fleet governance Set minimum reputation requirements for agents in your organization: ```python theme={null} # Enforce minimum A grade for production agents for agent in org_agents: rep = httpx.get(f"{API_BASE}/v1/reputation/{agent['id']}").json() if rep["score"] < 700: print(f"WARNING: {agent['id']} below production threshold ({rep['score']})") pause_agent(agent["id"]) ``` ### Compliance reporting Export weekly snapshots for audit trails: ```typescript theme={null} const history = await fetchReputationHistory(agentId); // Generate compliance report const report = history.map(snapshot => ({ week: snapshot.week_start, score: snapshot.score, grade: snapshot.grade, checkpoints: snapshot.checkpoint_count, components: snapshot.components, })); ``` ### Marketplace listings Display reputation badges on agent directories, npm packages, and documentation sites. See [Embeddable Badges](/guides/reputation-badges) for embed code. *** ## Cryptographic verification Every Mnemom Trust Rating is backed by a cryptographic proof chain that enables independent verification without trusting Mnemom's infrastructure. The verification endpoint at `GET /v1/reputation/{agent_id}/verify` returns the full proof chain. ### Proof chain structure The proof chain consists of three layers that independently attest to score integrity: ``` ┌──────────────────────────────────────────┐ │ Certificate Hash │ │ SHA-256 of the latest IntegrityCertificate│ │ covering this agent's checkpoints │ ├──────────────────────────────────────────┤ │ Merkle Root │ │ Root hash of the Merkle tree over all │ │ analyzed checkpoints │ ├──────────────────────────────────────────┤ │ Hash Chain Validation │ │ Consecutive checkpoint hashes linked │ │ in a tamper-evident chain │ └──────────────────────────────────────────┘ ``` **Certificate hash** -- The SHA-256 hash of the [IntegrityCertificate](/protocols/aip/certificates) that covers the agent's checkpoint history. This certificate is Ed25519-signed by the Mnemom attestation key and can be independently verified using the public key from the [key registry](/api-reference/endpoint/get-keys). **Merkle root** -- The root of a Merkle tree constructed over all analyzed checkpoints. Any individual checkpoint can be verified for inclusion using a [Merkle inclusion proof](/api-reference/endpoint/get-checkpoints-id-inclusion-proof) without revealing other checkpoints in the tree. **Hash chain validation** -- Each checkpoint includes a hash of the previous checkpoint, forming a tamper-evident chain. If any checkpoint is modified or removed, the chain breaks. The `hash_chain_valid` field confirms the entire chain is intact. ### Verifying a score ```bash theme={null} # 1. Fetch the verification proof curl https://api.mnemom.ai/v1/reputation/agent-xyz/verify # 2. Cross-reference the certificate hash curl https://api.mnemom.ai/v1/checkpoints/{latest_checkpoint_id}/certificate # 3. Verify the Merkle root against the agent's checkpoint tree # (members of the agent's org only -- anonymous requests get 401) curl https://api.mnemom.ai/v1/agents/agent-xyz/merkle-root \ -H "Authorization: Bearer $MNEMOM_TOKEN" ``` The reputation verification endpoint (`GET /v1/reputation/{agent_id}/verify`) and the certificate endpoint are public and require no authentication. A caller outside the agent's org gets a verify-only view of the certificate: the identifiers, timestamps, verdict, input commitments, proofs and verification fields are kept, while session, card id, concerns, reasoning, confidence and analysis-model details are blanked or omitted and listed in its `redacted` field. That view still verifies. Members of the agent's org get the full certificate. The per-agent Merkle root endpoint in step 3 is member-only: it requires an authenticated member of the agent's org. Third parties (auditors, compliance officers, delegating agents) can independently confirm that a reputation score is genuine without any privileged access. Verification confirms that the score was computed from authentic, tamper-evident data. It does not guarantee the scoring algorithm itself is correct -- for that, see the published [scoring methodology](/concepts/reputation-scores). *** ## A2A trust extension The reputation API includes a pre-built trust block for inter-agent reputation sharing via A2A. When fetching an agent's reputation, the response includes an `a2a_trust_extension` field that can be directly embedded in an A2A Agent Card. ### How it works ``` Agent A ──[fetches reputation]──→ Mnemom API │ ▼ a2a_trust_extension │ Agent A ──[embeds trust block]──→ A2A Agent Card │ Agent B ──[reads trust block]──→ Delegation decision │ Agent B ──[verifies via verified_url]──→ Independent confirmation ``` When Agent A fetches its own reputation from `GET /v1/reputation/{agent_id}`, the response includes: ```json theme={null} { "a2a_trust_extension": { "provider": "mnemom", "score": 782, "grade": "A", "verified_url": "https://api.mnemom.ai/v1/reputation/agent-xyz/verify", "badge_url": "https://api.mnemom.ai/v1/reputation/agent-xyz/badge.svg", "extension_uri": "https://mnemom.ai/ext/agent-trust/v1", "confidence": "medium", "methodology_url": "https://www.mnemom.ai/methodology", "last_updated": "2026-02-21T14:00:00.000Z" } } ``` Agent A embeds this as the `trust` block in its A2A Agent Card. When Agent B discovers Agent A through A2A, it can: 1. Read the static `score`, `grade`, and `confidence` for a quick trust check 2. Fetch `verified_url` -- the [verification endpoint](#cryptographic-verification) -- for the latest score plus its cryptographic proof chain in one call 3. Render `badge_url` for a visual trust signal ### SDK helper ```typescript theme={null} import { getA2AReputationExtension } from '@mnemom/reputation'; const trustBlock = await getA2AReputationExtension('my-agent-id'); agentCard.trust = trustBlock; ``` There is no dedicated reputation SDK for Python; call the endpoint directly and read `a2a_trust_extension` from the JSON response. The trust block is a snapshot. Agent B SHOULD fetch `verified_url` before making high-stakes delegation decisions. The `badge_url` always returns the current score for display purposes. For the full A2A integration guide including value coherence handshakes and reputation gates, see [A2A Integration](/protocols/aap/a2a-integration). *** ## Public trust surfaces Trust Ratings are not just internal metrics — they power public-facing trust signals across the ecosystem. ### Public reputation pages Every agent with a published score gets a public page at: ``` https://www.mnemom.ai/agents/{agent_id}/reputation ``` The page includes full component breakdown, trend chart, and grade badge. No authentication required — anyone can inspect an agent's trust history. ### Trust directory A searchable directory of all publicly rated agents at: ``` https://www.mnemom.ai/directory ``` Filter and sort the directory to find trusted agents across the ecosystem. ### Embeddable badges Dynamic SVG badges that display an agent's current Trust Rating anywhere — GitHub READMEs, websites, documentation, A2A Agent Cards, and package registries. See [Embeddable Badges](/guides/reputation-badges) for the full list of variants and embed code. ### GitHub Action [`mnemom/reputation-check`](https://github.com/mnemom/reputation-check) is a GitHub Action that gates CI/CD pipelines on minimum reputation scores. See the repository for current usage. ### A2A trust extension Pre-built trust blocks for inter-agent reputation sharing via Google's A2A protocol. Embed live score, grade, and verification URLs directly in an agent's A2A Agent Card. See [A2A Integration](/protocols/aap/a2a-integration). *** ## How scores differ from alternatives | Dimension | Mnemom Reputation | Self-Reported Trust | Capability Benchmarks | | - | - | - | - | | **Evidence source** | Independently verified behavioral data | Agent's own claims | Synthetic test suites | | **Update frequency** | Continuous (every 6 hours) | Manual updates | Periodic re-evaluation | | **Verifiability** | Cryptographically provable via Merkle proofs | Unverifiable | Reproducible but narrow | | **Scope** | Alignment, drift, completeness, coherence | Whatever the agent declares | Task-specific accuracy | | **Gaming resistance** | Minimum thresholds, synthetic detection, independent analysis | Trivially gameable | Benchmark contamination | | **Trend visibility** | 30-day delta, weekly snapshots | None | Version-to-version only | *** ## Team reputation Teams have their own parallel reputation scoring system — the [Team Trust Rating](/concepts/team-reputation). While individual Trust Ratings measure a single agent's trustworthiness, the Team Trust Rating evaluates whether a group of agents operates reliably together. Key differences from individual scoring: * **Different components:** 5-component model optimized for team dynamics (coherence history, member quality, operational record, structural stability, assessment density) * **Same grade scale:** Teams use the same AAA–NR grades and 0–1000 score range, enabling direct comparison * **Lower eligibility bar:** 10 team risk assessments (vs. 50 integrity checkpoints for individuals) * **One-way dependency:** The team's Member Quality component reads individual Trust Ratings (read-only) — it never modifies individual scores *** ## Trust recovery When violations are caused by **card gaps** (configuration errors) rather than genuine agent misbehavior, scores can be recovered through [reclassification](/concepts/card-lifecycle). The workflow: 1. Identify violations caused by missing card capabilities (e.g., agent used a tool correctly but the card didn't declare it) 2. Submit a reclassification request marking the violation as `card_gap` 3. Amend the alignment card to include the missing capability 4. Trigger score recomputation — `card_gap` violations are excluded from Compliance and Drift Stability components 5. Score recovers on the next 6-hour recomputation cycle A reclassification also triggers a bounded trust-graph propagation: related agents reachable within 3 hops (capped at 50 agents per run) have their own scores recomputed, so a corrected card gap can improve trust for connected agents too, not just the one whose card was fixed. See the [Trust Recovery Guide](/guides/trust-recovery) for step-by-step instructions and the [Reclassification API](/api-reference/reclassification-overview) for endpoint details. *** ## On-chain verification Reputation scores can be anchored on-chain via the [MnemoReputationRegistry](/concepts/on-chain-verification) smart contract on Base L2. On-chain anchoring provides: * **Immutability** — Published scores cannot be altered after anchoring * **Independent verification** — Anyone can query the contract directly without trusting Mnemom infrastructure * **Tamper evidence** — Merkle roots anchored on-chain prove the integrity of the full checkpoint tree See [On-Chain Verification](/concepts/on-chain-verification) for architecture details and the [On-Chain API](/api-reference/on-chain-overview) for publishing endpoints. *** ## See also * [Team Trust Rating](/concepts/team-reputation) -- Team-level reputation scoring * [Scoring Methodology](/concepts/reputation-scores) -- Full technical specification of the scoring algorithm * [Improving Your Agent's Reputation](/guides/improving-reputation) -- Component-by-component improvement guide * [Embeddable Badges](/guides/reputation-badges) -- Add trust signals to your README, website, or Agent Card * [Reputation API Overview](/api-reference/reputation-overview) -- Full API reference for all reputation endpoints * [Integrity Checkpoints](/concepts/integrity-checkpoints) -- The primary data source for reputation scores * [Drift Detection](/concepts/drift-detection) -- How behavioral drift affects reputation * [Fleet Coherence](/concepts/fleet-coherence) -- How fleet compatibility contributes to scores * [Card Lifecycle](/concepts/card-lifecycle) -- How reclassification enables trust recovery * [On-Chain Verification](/concepts/on-chain-verification) -- Immutable score anchoring on Base L2 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.