inspeximus

inspeximus is a self-correcting memory layer for AI agents, provided as a zero-dependency Python file plus an MCP server. Its core design goal is to solve an often-overlooked problem: how the system should handle a stored fact when it later proves to be wrong. Instead of relying on embedding drift or heuristics such as "the LLM usually picks the newer value," it deterministically retires the old value by key, and makes that retirement an auditable, rollback-capable, provable record.

Purpose and main capabilities inspeximus is suitable for scenarios where an agent runs continuously for days, the facts it holds change, and afterward someone needs to ask "what the agent knew at the time" and "what it erased." It supports superseding, rolling back, or forgetting a value, and provides the following capabilities:

• Deterministic supersession: after a new value is written by key, the old value is retired; writing the old value again will not revive it, which recency rules cannot achieve. Rollback requires explicitly using remember(..., reaffirm=True).
• Authority mechanism: optionally enable Inspeximus(path, supersession="authority") so that a weaker source cannot overwrite a stronger one. A summary carries the authority value of its weakest parent via derived_from, preventing a rumor from being restated with full authority. Authority rules take effect only when both sides declare an authority value.
• Tamper-evident receipts: when receipts are enabled, each write is added to a hash chain. verify_writes() can be called to detect edits outside the library. For existing records without a chain, a one-time backfill call can generate a receipt for each record.
• Erasure proofs: an erasure operation removes that record's key from the log line in the same transaction as the deletion (the line is retained and marked key_redacted), thereby preventing a key that names an individual from outliving the erasure itself. Erasure proofs cover only this storage, not vector indexes, prompt logs, or backups; it is an integrity primitive, not a compliance certification.
• Action ledger: binds agent actions to the memory it held at the time, recording a digest of the storage state and the id returned by the most recent recall. By default no content is stored; inputs and outputs are kept as salted SHA-256 digests. Signing uses the storage's receipt key. Supports led.matches(seq, inputs=prompt, output=answer) to verify whether given prompts and outputs match the record.
• Multi-process support: the row writer, within the transaction that writes the row, writes to memory_events appends a content-free row; other processes can follow the table by seq and see the commit on their next call, with no reload or proxy needed.
• Event types: including oversight records (led.oversight), disclosure records (led.disclosure), subject rights export (export_subject), rectification (rectify), incident records (led.incident), etc.
• Compliance evidence: inspeximus compliance prints evidence by clause. assessor_pack() renders Annex IV, the deployer report (including DPIA and FRIA appendices), the Annex VIII export, and the audit pack. inspeximus technical-documentation --out annex_iv.md generates an Annex IV skeleton, inspeximus deployer-report --out deployer.md generates the deployer-side report, and inspeximus registration-export --section A writes Annex VIII fields. These documents flag every field that could not be filled in and do not claim to be complete when fields are unanswered.
• Receipt chain management: supports inspeximus receipts enable --backfill to enable and backfill from the shell; supports inspeximus actions archive --keep-days 400 to archive old entries and generate a signed checkpoint; supports inspeximus actions attest --policy-days 183 --actor dpo to attach a signed statement; supports inspeximus actions timestamp --url https://freetsa.org/tsr to timestamp the tail via an RFC 3161 authority; supports inspeximus actions timeline --session s1 to rebuild a single workflow from the chain, with no content stored.

Usage Installation and basic usage are available via the GitHub repository and PyPI. Quick start, migration guides (such as migrating from mem0), and full documentation are in the project repository. The MCP server can record every tool call via INSPEXIMUS_ACTIONS=1. The LangChain integration records tool and model calls via inspeximus.integrations.langchain.InspeximusActionCallback.

Applicable scenarios

• Memory management for agents that run for a long time and whose facts change dynamically.
• Scenarios that require post hoc auditing of an agent's knowledge state and erasure operations.
• Organizations that need to generate evidence documents related to the EU AI Act and GDPR.
• Scenarios that require multiple processes to share the same storage and avoid proxies.

Limitations and notes

• Erasure proof covers only its own storage, not vector indexes, prompt logs, or backups.
• It is an integrity primitive, not a compliance certification; certification must be done separately by others.
• It is not suitable for scenarios that require a managed service, dashboards, a document knowledge graph, or the highest score on a conversational recall benchmark.
• Writing a statement without a key counts as a new fact rather than a correction and is not subject to the guard.
• Authoritative rules have a known bug shape: a fact seeded by the system with full authority cannot be corrected when an agent writes with lower authority than its own.
• Benchmark data: on the MemTX corpus, the default mode serves the labeled belief in 278 of 318 replayable cases, and authority mode in 307.
• Some features (such as Annex IV documents) include 24 provider fields marked OPERATOR INPUT REQUIRED.
• The aging report for archived logs is reported as "not yet testable" until the logs reach the six-month floor.

Classification basis: this project provides a memory layer for AI agents, but is not itself an agent, and does not belong to clear categories such as programming, images, or video, so it is classified as another AI tool.