inspeximus: agent memory with provenance, GDPR erasure and a tamper-evident audit trail

WHAT ARE THIS STORE'S IDENTIFIERS, and which folds over them would LOSE information? The question a store outlives its writer to face: someone holds the file months later, the version that wrote it is gone, and whatever deformation happened is already in the bytes. They cannot run a conformance suite. What they need is narrower — which keys are canonical, which folds were DELIBERATE, and which are INVERTIBLE. At remediation time that last distinction is the one that matters: an injective deformation is a backfill job, a fold that maps two keys onto one cannot be undone. Returns `declared` (what the running writer promises — byte-exact, case-sensitive, no normalisation) beside `measured` (what each candidate fold would actually cost on THIS store's keys, independently of the claim). Measured on our own decision store: an 8-character prefix fold would merge 594 groups and lose 1,365 keys, and no field declared any policy at all. A ZERO COST HAS TWO CAUSES and they render identically, so each fold also carries a `verdict`. COST_MEASURED means keys demonstrably merge. NOT_YET_MEASURABLE means the population is too small for zero to mean anything — 13 UUID keys against an 8-hex-character fold collide with probability ~1e-8, so a zero there is the absence of a signal rather than a clean bill of health. ZERO_AT_SCALE is the only one that says the fold is harmless on keys like these. Prefix folds also carry `threshold_population` (how many more keys before a collision is expected, from the per-position perplexity of this store's own keys) and `collides_at_length` / `headroom_chars`, which need no model at all: how many characters shorter the fold would have to be before it started merging. HONEST SCOPE, in `limits`: `declared` speaks for the code running now, not for the version that wrote a record last year; and `measured` sees only surviving keys, so a fold that ALREADY collapsed two of them left no trace of the second. Absence of merging is not proof that none occur…

The Art. 73 report skeleton for incident `seq`: dates, the statutory deadline and whether it is overdue, the evidence entries with their memory state and any oversight on them, later entries that refer to the incident, and the fields the provider must add. Read-only.

Record that incident `seq` was reported (Art. 73, Art. 26(5)): to whom and when. A later entry that names the incident; incident_report and oversight_report treat it as closed from then on.

Does the derived semantic index agree with the store? Reports active text records missing a vector while an embedder is configured (index behind store), persisted-vector recipe vs the current embedder, and the persistence regime. A governed store can still serve stale answers through a lagging index — this is the deterministic check for exactly that. Read-only.

POISON / adversarial-integrity status: which memories are gated from influencing recall durability (self- asserted / uncorroborated / slashed) vs earned. The at-a-glance view of the store's poison-resistance state.

Audit view of the per-source lifetime IRREVERSIBLE-influence budget: how much durable pull each source has spent against its cap — the 'no single source can quietly entrench itself' ledger. Read-only.

Every Art. 4 measure recorded, with counts by audience and by measure. Read-only.

Every recorded action that its signed mandate check marked outside the declared mandate, oldest first, with the reasons, how many actions were checked and how many ran with no mandate in force, and every mandate declaration with the handle that wrote it. A mandate is declared by the operator through ActionLedger.mandate(), never over MCP, so the agent it governs cannot widen it. Tool calls through this server are recorded as `mcp:<tool>` with no target, so a mandate for them names action patterns only. Read from the entries as written; nothing is re-judged or inferred.

THE ALWAYS-LOADED INDEX: one line per record, budgeted, so the right one gets opened. A store too big to hold in context is read through a small index, and the agent decides what to open from those lines alone. The line is therefore the only surface a future need can reach: a record whose line does not distinguish it is present, correct, and never retrieved. MEASURED on a 316-note store, 120 questions written from the note bodies and shown to no line-writer, ranking all 316 candidates. recall@3 on full questions / on the three-to-eight words someone types into a search box: a hand-written title-and-hook 0.333 / 0.508; the title alone 0.300 / 0.450; title plus its highest-idf terms 0.350 / 0.533; a line saying what the record CONCLUDED 0.683 / 0.833; the full records, as a ceiling, 0.858 / 0.967. So the line worth having is a sentence about the conclusion, and no extraction produces one -- term-stuffing is a null on both registers. Which is why the useful call is not this one alone: read `needs_line`, write those sentences yourself, and store them with `set_index_line`. Without them this returns the fallback -- the record's opening sentence, measured through this same call at 0.442 / 0.525 against 0.692 / 0.842 with written lines -- and `limits` says which you got. `budget_tokens` shortens lines to fit and NEVER drops a record -- a record with no line cannot be found at all -- so a budget too small to hold one line each is reported as exceeded rather than silently met. The one exception is not the budget's: a record a standing Art. 21 objection withholds (record_objection) gets no line, and `withheld_by_objection` counts them.

INSPECTOR overview — 'what is in memory, and is it clean': active/superseded counts, by type, likely duplicates (>= dup_threshold), and integrity posture. The at-a-glance store-health view. Read-only. NOT free, and the caller here is a model mid-conversation. The duplicate estimate samples 400 records and runs a FULL recall for each, so it is O(400 x n) over the whole store: measured ~2 s at n=2,000 and ~12 s at n=8,000 (no embedder; median of 5, run-to-run spread 15-25%, so two significant figures is all this supports). "At-a-glance" describes the output, not the wait. The counts (active/superseded/by_type/linked/decayed) are single passes and effectively free -- if that is all you need, this tool is the expensive way to get it.

Expand context AROUND a memory: the k memories most related to the one with `id` (compact snippets), by recalling on that memory's own text and excluding itself. Use it for on-demand local context after recall surfaces a relevant hit — a bounded expansion, not a whole-store dump. Returns [] if the id is unknown. Honours the active project scope, like recall: expanding around a hit must not be a side door back into another project's memories.

The latest Art. 13 or 14 notice per subject and the items each one left out. Read-only.

Every Art. 21 objection this store has recorded, standing or resolved. Read-only.

READ-PATH review trigger — the mirror of a write-time hold-for-review. Feed it an OBSERVATION (evidence, NOT an authoritative write) that CONTRADICTS a settled memory: a different value for `key`, or object="" for a value-obscuring revert ("go back to what we had", names no value). Instead of silently trusting or ignoring it, this REOPENS that settled record for review. A NAMED contradiction (a different value) reopens only once it is CORROBORATED, so a lone stray restatement stays an echo and does not reopen: `support` (a list of the distinct grounds the observation rests on) is what corroboration counts, a restatement whose grounds were already seen is an echo, and it takes >= reopen_corroboration distinct novel grounds. A VALUE-OBSCURING revert (object="") reopens on FIRST sight: it names no value, so there is nothing a second observation could corroborate or echo, and the only safe outcome is a steward's decision. The record stays current meanwhile; nothing is restored until resolve_reopened says so. observe() NEVER supersedes or writes — it only flags; a steward closes the review with resolve_reopened(). Use it for contradicting evidence you don't want to act on blindly. Returns {reopened, key, pending, need, surfaced_prior, review_id}.

Open a memory partition: a named scope per agent or per process with a size cap and an expiry (the CNIL's 2026 note on agentic AI). Writes made with `remember_in_partition` are tagged into it; `sweep_partitions` applies the expiry and cap with tombstones; `close_partition` ends the process (a context partition erases its records at close). `kind` is context, process or agent. Opening a name that is already open returns that partition when the rules match, and is refused when they differ: a partition's rules are fixed when it opens. The result states the rules IN FORCE, read back from the registry.

Counts from the action ledger an auditor asks for: actions, oversight events by type and by actor, actions with a human decision attached, error actions with no oversight after them, stops, and disclosures by session. Read-only.

Every partition with its rules, live count, oldest age, whether a sweep is due, and its closed state; plus how many active records sit outside any partition. The storage-limitation view (GDPR Art. 5(1)(e)).

What PII the store currently holds, by type (emails, phones, cards, …) — a data-minimization / audit view. Every record the store holds is counted, superseded ones included (`superseded_with_pii` says how many), because forget_pii erases those too. Read-only; pair with forget_pii to act on it.

What changed in the store since `since_seq`, from the `memory_events` table the row writer appends to INSIDE its own transaction: {events: [...], tip: <highest seq now>}. Each event is {seq, ts, type, memory_id, agent, tenant, payload}; the automatic ones (record.added, record.changed, record.removed) carry only id, key, status and mtype, never text, so tail them and fetch the record with `get`/`recall` where the grants apply. Another process's write is visible on the next call, no reload. Keep `tip` and pass it back as `since_seq`. `event_type` "*" (or empty) means every type. A JSON-format store (INSPEXIMUS_STORE_FORMAT=json, an encrypted store) has no event table, and the call is an error there rather than an empty feed.

The Art. 72 post-market monitoring report for one period, from the ledgers: actions and errors, oversight by event, incidents and their clocks, rights requests, risks recorded (and those found from post-market data), retention, lifecycle, disclosures, the chain verifier's verdict, and the store's size. `plan` is the operator's monitoring plan, carried by name, version and hash. With `actor` the report is signed into the ledger as a `monitoring` entry; without it, read-only.

Every Art. 28 role declaration, with the current one named. Read-only.

List the project scopes present in this store, with a memory count each — the map for `all_projects` search and the check that your writes are landing where you think. `unscoped` counts memories carrying no project stamp: they are GLOBAL (visible from every project), which is what a store written before project scoping was adopted looks like, and why adopting a scope does not hide anything you already had. `active` is this server's own scope (null = it sees everything). Read-only, deterministic, no LLM.

WHERE DID THIS FACT COME FROM — one answer, assembled from the whole record: the declared source and the lineage it inherited through summarization, whether an origin attestation bound it to a verified key, its evidence grade, every value it has held and WHICH policy retired each one, and whether it still matches the write receipt committed at write time (so a later relabel is loud). Pass `key` (the fact, across all its values) or `id` (one record). Read-only; the returned `limits` state honestly what this does NOT prove. A quarantined record's text and value are withheld, unless `include_quarantined` is set.

The current QMS procedure per name, the ones overdue for review, and which Art. 17(1) aspects have a current procedure. Read-only.

What the read-path guards (3.5.0) hold back: every quarantined record (instruction-shaped text, with the shapes that put it there and whether a human released it) and every keyword-stuffed record (the repeated word and its share). Quarantined records are stored, exportable and erasable; they are kept out of recall unless asked for. Read-only.

Retrieve the top-k memories by RELEVANCE × accrued VALUE (not recency). Use this to load relevant prior knowledge before reasoning. Records the read-path guards quarantined (instruction-shaped text, 3.5.0) are left out unless `include_quarantined` is set; keyword-stuffed records never outrank clean ones. `include_archive` also searches the archive segments beside the store (old captured mechanics moved out by `--archive`); it opens every segment, so it is slower and off by default. Compact by default: each hit is a small projection — {id, text, score, value, tags} — dropping internal bookkeeping fields the model doesn't reason over, which keeps recall cheap to drop into a prompt. FULL TEXT IS KEPT (no truncation by default). Pass `snippet_chars>0` to opt into snippet truncation (flags `truncated`; then use get(id) for full text) — note that truncation can cut off a corrected value past the boundary, so it is off by default. Set `full=True` to return complete records (all fields). `k` is hard-capped for safety. `mmr` (0..1, off by default) reranks for DIVERSITY so you don't get k near-duplicate memories — 1.0 = pure relevance, lower = more diverse (deterministic Maximal Marginal Relevance, zero-LLM). `trusted_only=True` (needs a configured trust root: INSPEXIMUS_TRUST_SEEDS on this server) returns only memories anchored to a trusted signing key or source — a deterministic defense against injected/poisoned memories from untrusted writers. With no trust root configured the call is an error, not an empty list that reads as "nothing trusted matched". `resolve_conflicts=True` (or server-wide INSPEXIMUS_READ_RESOLVER=1) resolves near-duplicate same-subject candidates at read time by value BIRTH — an un-keyed restatement of a superseded value is demoted below the correction instead of out-ranking it; the surviving hit carries `resolved_over` ids. Deterministic, zero-LLM. (Standard progressive-disclosure / small-to-big retrieval practice, not a inspeximus-specific techniq…

Recall AS a named agent: the same ranking as `recall`, hard-filtered to what that agent owns or has an active grant for. FAIL-CLOSED -- an agent with no grants sees only what it wrote itself, and a grant that cannot be evaluated authorises nothing. This is a SEPARATE tool rather than an `as_agent=` argument on `recall` on purpose: an access-control scope that is an optional parameter is one a caller can forget, and forgetting it would read the whole store. Here the scoped read is the only thing this tool can do.

MULTI-HOP recall, PHASE 2 of 2 — hand back the follow-up queries YOUR model wrote after reading `recall_iterative`'s round-1 hits, together with the `prior_ids` it returned. Each follow-up is retrieved and only the records you do NOT already hold come back, so the second round costs you the bridge evidence and nothing else. `prior_ids` is the whole continuation state — there is no session on the server, nothing to expire, and nothing that can be served to the wrong caller. Pass it. Without it every follow-up hit is reported as new, including the ones round 1 already gave you. Want a further round? Call this again with `merged_ids` from this result as the new `prior_ids`. Rounds are your loop; the server holds no state between them. Returns {followups_used, followups_dropped, new_hits, bridged, merged_ids, recall_calls, bounds}. `bridged` is how many records this hop added — 0 is a legitimate answer and means the bridge was not there. BOUND: at most min(len(followups), max_followups) recall() calls, `max_followups` itself capped at 8, and at most k * max_followups NEW records. Worst case with both at their ceilings: 8 retrievals, 400 records. Nothing here scales with store size. Honours the active project scope; `all_projects=True` crosses it, and must match what you passed to `recall_iterative` or round 2 searches a different pool than round 1.

MULTI-HOP recall, PHASE 1 of 2 — use this instead of `recall` when the answer needs a fact that is reachable only THROUGH another one ("who manages the person who signed off on X", "what did the vendor we switched to in March charge us"). One-shot top-k systematically misses that second hop: the record holding it is similar to the BRIDGE entity, not to your question, so no amount of ranking brings it back. HOW THIS WORKS, AND WHY YOU ARE IN THE LOOP. The fix is to read round-1, name what is missing, and search again — which needs a model. inspeximus does not have one and will not grow one: no LLM on the write path and none inside the read path either. You ARE the model. So this returns round-1 hits plus `ask` (the instruction) and `prior_ids` (the continuation token), you decide what the bridge is, and you hand it back to `recall_followup`. Your model stays yours; the retrieval, dedup and merge stay deterministic and ours. Returns {k, max_followups, round, hits, prior_ids, ask, next_call, bounds} — your query is not echoed back (you sent it, and a memory server should not reflect caller text into a model's context). If `hits` already answer the question, stop here — the second call is optional and costs a retrieval. BOUND: exactly ONE recall() and at most `k` records back (`k` hard-capped at INSPEXIMUS_MAX_K). The response size is a function of `k` alone and does NOT grow with the store — unlike this server's `contradictions` surface, whose all-pairs output reached ~150 MB at n=2,000. Honours the active project scope, like `recall`; `all_projects=True` searches every project. A multi-hop walk must not be a side door out of the scope its first hop respected.

The remedy `verify_writes` names for UNSCOPED records: append a fresh write receipt that binds each named record's CURRENT value, context and partition. IT BINDS THE STATE AS IT IS NOW. It does not validate the past: a record edited out of band before this call is committed as edited, and verifies clean afterwards. Run it ONLY on records you have checked against a copy you trust (a backup, an export, the source they were written from). `ids`: the records to recommit, as the UNSCOPED line lists them. `all=True` recommits every active record this server reads instead, and is only for a store checked in full. Pass one of the two: neither, or both, is refused and writes nothing. There is no whole-store default. A record whose latest receipt already binds all three is `skipped`, and a named id that matched no active record is named in `problems`. With a project scope, only that project's records and the unscoped ones are recommitted. Also refused, writing nothing, when this server cannot sign the way the chain is signed (a signed chain and no receipt key here, or the reverse): the new receipts would leave a chain signed in places, and verify_writes reports that. Needs receipts on. Returns {recommitted, skipped, problems}.

Attest for one Art. 5(1) prohibited-practice class (a, b, ba, bb, c, d, e, f, g, h) that the system is `not_used` for it, or that the class is `not_applicable` with the `basis` that rules it out. The register shows the latest attestation per class and the classes with none.

Record a reasoned request from a competent authority (EU AI Act Art. 21) and what was handed over. `scope` is documentation (21(1)), logs (21(2)) or both; `provided` lists {item, sha256} references to what was given, never the content (21(3) confidentiality).

Record a personal data breach (GDPR Art. 33) with its 72-hour clock from `aware_ts` (default now) and the Art. 33(3) content as far as known: nature, categories and approximate numbers of subjects and records, contact point, likely consequences, measures. `high_risk` is the Art. 34(1) judgement that decides whether the subjects must be told. `refers_to` lists ledger seqs; each must exist.

Record a corrective action (EU AI Act Art. 20): `kind` is conformity, withdraw, disable or recall; `non_conformity` what was wrong; `refers_to` the ledger seqs that are the evidence (each must exist); `informed` a list of {party, ts, how} among distributor, deployer, authorised_representative, importer, market_surveillance_authority, notified_body; `presents_risk` the Art. 79(1) case where the authority must be informed (20(2)). The report names which parties were not informed.

Record an EU declaration of conformity (EU AI Act Art. 47) with the Annex V items: the system's name, type and reference; the provider's name and address; the standards or common specifications used; the Art. 43 procedure (annex_vi_internal_control or annex_vii_notified_body, the latter with the notified body's {name, id, certificate}); the place, date and signer. `annex_iv_sha256` pins the technical documentation the declaration rests on; `ce_marking` is {digital_access, affixed_to, notified_body_id} (Art. 48). The assessment itself is the provider's or the notified body's.

Record an EU AI Act Art. 50 disclosure in the action ledger: that the user in `session` was shown `shown` (stored as a digest plus its length) in `channel`. `kind` is interaction (told they interact with an AI system), generated_content (output marked as generated), or another Art. 50 case. `agent` names the agent that disclosed and `principal` who it acts for, as the Commission's Art. 50 guidelines ask for at each new interaction.

Record a serious incident (EU AI Act Art. 73) in the action ledger with its reporting clock: severity serious (15 days), widespread (2 days), death (10 days) or other. `evidence` lists ledger seqs that document it; each must exist. `aware_ts` is when the provider became aware (default now).

Record a lifecycle event of the system in the action ledger: start, stop, pause, resume, configuration_change, key_rotation, substantial_modification (the Art. 3(23) change that ends Art. 111(2) grandfathering) or decommission, which needs `disposition` of the persistent memory (erased, archived, transferred, retained). Annex IV point 6 and the deployer report list these entries.

Record one AI-literacy measure (EU AI Act Art. 4): `measure` is training, guidance, documentation, briefing or assessment; `audience` is staff, contractor, operator_of_the_system or other_person_on_behalf; `considered` lists the Art. 4 factors taken into account (technical_knowledge, experience, education, training, context_of_use, persons_affected). The article asks for measures, not a level reached by any individual, so no score is recorded.

Record that a data subject was given the GDPR Art. 13 (data collected from them) or Art. 14 (data obtained elsewhere) information: the channel (ui, email, letter, api, voice, document), the items the notice carried (controller_identity, dpo_contact, purposes_and_legal_basis, legitimate_interests, recipients, third_country_transfer, retention_period, rights, withdraw_consent, complaint_to_authority, provision_required, automated_decision_making; for Art. 14 also data_categories, data_source), and `text_sha256` pinning the text. Art. 14 needs `source` and `timing` (at_collection, within_one_month, at_first_communication, at_first_disclosure). The entry lists the items it did not carry.

GDPR Art. 21: record the subject's objection and stop serving their records. From this call on, every read that searches or lists the store withholds every record whose source resolves to `subject`, including later writes, until the objection is resolved: recall and its variants, memory_index, verify_claim and check_conflict, and why_recalled explains such a record without quoting it. Every server on this store honours it from its next call. `get(id)` still returns a record by its exact id, and the records stay exportable under Art. 15 (export_subject); erasure is forget_subject. `ground` is own_situation (21(1)) or direct_marketing (21(2), never overridable); `scope` is all or profiling.

Record a HUMAN decision about the agent's work in the action ledger: approve, refuse, override, stop or review (EU AI Act Art. 14, GDPR Art. 22). `actor` is the person or role who decided and is required. `refers_to` is the seq of the action it concerns and must exist. `decision` is what the human substituted, stored as a digest.

Record who this store's operator is for the personal data in it (GDPR Art. 28): controller, joint_controller, processor or sub_processor. A processor names the `controller` and the written `instructions_ref` (28(3)), pinned by `instructions_sha256`; `sub_processors` lists {name, authorised_by, authorised_ts} (28(2)); `purposes` and `categories` describe the processing.

Record one procedure of the provider's quality management system (AI Act Art. 17): name, version, owner, when its next review is due (epoch seconds), the Art. 17(1) aspect it covers (a letter a to m) and, for a document, its reference and sha256. A later entry for the same procedure is the current one. The QMS itself is the provider's; this is the signed record that it exists and who keeps it.

Record who carries which obligations along the value chain (EU AI Act Art. 25). `parties` is a list of {party, role, obligations} with roles provider, initial_provider, new_provider, product_manufacturer, distributor, importer, deployer, authorised_representative, third_party_supplier; one party must carry the provider's obligations. `trigger` is the 25(1) reason (name_or_trademark, substantial_modification, changed_intended_purpose); `cooperation` maps the 25(2) items (technical_documentation, known_limitations_and_failure_modes, targeted_technical_access) to references; `agreement_ref` names the 25(4) written agreement and `agreement_sha256` pins it.

Append one entry to the risk register (EU AI Act Art. 9). The same `risk_id` again is a review or a re-estimate; the register shows the latest state and how long since the last review. `source` is intended_use, foreseeable_misuse or post_market (9(2)(a) to (c)); `harm` is health, safety or fundamental_rights; `measure_kind` is eliminate, mitigate or inform (9(5)); `residual` plus `residual_acceptable` is the 9(5) judgement; `tests` lists {metric, threshold, observed, passed} against a threshold defined before the test (9(8)); `refers_to` lists ledger seqs and each must exist.

GDPR Art. 16 rectification: supersede the value under `key` with `text` through the ordinary keyed write (every write guard applies), and record who asked and why as a rights:rectify entry on the action ledger bound to the memory receipt. `actor` and `reason` are required. Returns the verdict on the write as `remember` gives it. A correction a guard retired on arrival comes back `blocked: true` with the guard's `policy`: the old value still stands, and the ledger entry says `blocked`, not `ok`.

The Annex VIII fields for registration in the EU database (EU AI Act Art. 49). `section` A: provider of a high-risk system (Art. 49(1)); B: provider relying on Art. 6(3) (Art. 49(2)); C: deployer that is a public authority (Art. 49(3)). Evidence fills the traceability reference, the description of the information used, the instructions for use and, for C, the FRIA and DPIA summaries; everything else is marked OPERATOR INPUT REQUIRED. The content of a registration, not the registration itself. `expected_pubkey` (hex, optional) pins the memory chain verdict and defaults to INSPEXIMUS_RECEIPT_PUBKEY; the action ledger is signed with the writer key, so it is pinned only to a key passed here.

A human decision that a quarantined record is a memory after all: it returns to recall and keeps who released it and why.

Store a memory (append-only; raw text is never edited afterward). `tags` group memories into cohorts; `value` (>=1) is its importance — higher-value memories outrank merely-similar ones at recall. Recall does NOT change it: a read leaves value, last_access and the state digest as they were, so an anchor or witness pinned to the store stays valid across reads. `credit` is what moves a memory's standing after an outcome. `mtype` ∈ {episodic, semantic, procedural} sets the decay prior — episodic (events) fades fast, semantic (durable facts) slow, procedural (rules / preferences) barely; pass it when you know the kind, else it's inferred. Optional `key` is a deterministic (subject, relation) supersession key (e.g. "billing-api::auth-method"): storing a new value with the same key retires the old one so recall never returns the stale value — no similarity threshold, no extra LLM call. Use it for facts that get updated (config, prices, versions, status). Pass `object` = the asserted VALUE (e.g. "frankfurt") alongside `key`: with the echo guard on (default here), a later RE-STATEMENT of an already-retired value cannot resurrect it (a corrected fact stays corrected even if the old value is said again). Without `object` the guard still catches a verbatim restatement (text hash), but a *reworded* one needs the value in `object` to be caught. Set `reaffirm=True` to intentionally revert to a previously-retired value (an explicit change-of-mind, not an echo). `source` — WHO OR WHAT this came from ("crm/alice", "user-42", "docs.example.com/pricing"). Pass it whenever the memory is about, or came from, an identifiable person or system. It is what makes the memory reachable later by SUBJECT rather than only by id: `forget_subject("crm/alice")` erases a person's data and everything derived from it, `erasure_audit` can then say whether anything survived, and `slash` can forfeit a source's standing after a bad outcome. Without it a record is attributable to nothing, and none of tho…