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

One workflow reconstructed from the action ledger: the entries in order, content-free, filtered to a session or a principal when given, each with the memory digest the agent held, the model, the actor and the oversight or incident events that refer to it. The traceability the CNIL's 2026 note on agentic AI asks for. Nothing is inferred; a row carries only what the entry recorded.

Check a retained transcript against action number `seq`: recompute the salted digest of `inputs` and/or `output` the way the ledger did and compare with the entry's `inputs_sha256` / `output_sha256`. "Is this what the model was given, and is this what came back", for an entry whose content the ledger does not keep. Each side is true, false, or null when not passed or not digested. Needs the ledger's salt file beside the ledger. Read-only.

Verify the ACTION LEDGER beside this store: what the client did (every MCP tool call, when INSPEXIMUS_ACTIONS=1), bound to what the store held at that moment. Recomputes every hash, link and signature and checks that each entry's memory_state.last_receipt still exists in the store's receipt chain, so a rewritten memory history is caught from the action side too. Read-only.

Is this store in a state where an applicability question can be ANSWERED at all? The layer BELOW applicability. `evaluate_applicability` asks whether a record is admissible now; this asks whether the machinery that answer rests on is still working. Three store-scoped invariants, no new statuses: key_agreement every key the store holds resolves through the read path observation_channel_alive if records carry locators, some carry a read-time observation receipt_chain_covers_records if this store was WRITTEN with receipts (its .receipts.json sidecar exists) and records exist, the chain is not empty "Enabled" is this server's INSPEXIMUS_RECEIPTS or a receipt sidecar beside the store; either one makes an empty chain over existing records a failure, as it is for verify_writes on this server. A precondition that cannot apply reports `applicable: false` and does NOT count as holding -- a question that did not arise has not been answered. The layer and the first two invariants are @Stratogain's (safal207/Causal-Memory-Layer#289); the third is the same shape: a mechanism switched on and producing nothing.

TAMPER-EVIDENT MEMORY / transparency log: emit a HEAD COMMITMENT — a compact, externally-publishable snapshot {n_writes, writes_tip, n_tombstones, tombstones_tip, ts, sth_hash} that hash-commits to the ENTIRE write + erasure history at this instant. It is a hash commitment and carries NO signature from this server: a key the store operator holds is the very thing it must not depend on, so the signature comes from outside (a witness co-signs `sth_hash`; see verify_cosigned_anchor and `inspeximus anchor`). Publish it somewhere the store operator cannot retroactively alter (a public log, a third-party witness, the auditor's own records). This closes the one hole verify_writes() cannot: an operator who HOLDS the receipt key can rewrite AND re-sign the whole history so it still verifies internally — but they cannot make the rewritten tip equal an anchor an outsider already witnessed. Record this now; check later with verify_consistency(). (RFC 6962 model; the external witnessing is the auditor's job.) Quickstart, install to a verified co-signed anchor: docs/TRANSPARENCY.md, or `inspeximus anchor` in the shell.

Rotate the action ledger: move entries older than `keep_days` into a signed archive file beside it and start the live file with a checkpoint naming the archive, its SHA-256 and the archived tail. Nothing is deleted and the chain verifies across the files; an open incident and anything a kept entry refers to stay live. Returns what was archived (archived=0 and nothing written when nothing is old enough).

POINT-IN-TIME (bitemporal) query: the value that was CURRENT for `key` at event-time `when` (UTC epoch seconds), optionally as the store KNEW it at record-time `as_recorded`. 'What did we believe about X on date D.' A quarantined record's text and value are withheld, unless `include_quarantined` is set.

Append a signed statement of which Art. 18(1) documents are at the authorities' disposal for ten years after `placed_on_market_ts`: `documents` is a list of {kind, sha256 or ref, present, not_applicable_reason} with kinds technical_documentation, quality_management_system, notified_body_changes, notified_body_decisions, eu_declaration_of_conformity. Technical documentation and the declaration must be present; the notified-body items are present or not applicable with a reason; a missing quality management system is recorded as a gap. `declaration_seq` links the declaration entry.

Append a signed retention statement to the action ledger: the oldest entry it accounts for (archives included), live and archived counts, the policy in force and whether the six-month floor of Art. 19 and Art. 26(6) has been observed. Made from the ledger, not asserted.

The latest Art. 5 attestation per prohibited-practice class, and the classes never attested. Read-only.

Export a portable, CONTENT-FREE audit bundle of this store's whole write + erasure history (EU AI Act Art. 12/19). An auditor verifies it OFFLINE with verify_audit_bundle — no live store, no key. Needs INSPEXIMUS_RECEIPTS=1 (else the chain is empty). Save the returned dict as json to hand over. `expected_pubkey` (hex, optional) pins `governance.proof` to the key the receipts should be signed by; defaults to INSPEXIMUS_RECEIPT_PUBKEY.

CAN THIS LIBRARY'S OWN CHECKS ACTUALLY FAIL -- on THIS store? Every verify_*/check_*/*_audit tool here answers a question about your data. None answers the one above it: would this check have noticed if the thing it guards against had happened? A check that cannot fail on your store is not protecting you, it is producing a reassuring string. Corrupts a temporary COPY (never your store) in ways each surface claims to detect, and reports NOTICED / MISSED / SUMMARY_HIDES_DETAIL / CONTROL_FAILED per probe. Read the third and fourth: SUMMARY_HIDES_DETAIL means the boolean stayed clean while the report said otherwise, and monitoring reads booleans; CONTROL_FAILED means the surface was ALREADY unhappy before the corruption, which is a finding about your store rather than about the check. On its first run against our own 450-record decision store it returned three CONTROL_FAILEDs and the reason was worth having: receipts enabled, chain empty, nothing covered by a write receipt.

Record that breach `seq` was notified: `to` the supervisory_authority (Art. 33(1)), the data_subjects (Art. 34(1)) or the public (Art. 34(3)(c)). After 72 hours a notification to the authority needs `reasons_for_delay`. With `exemption` (protected, mitigated, disproportionate) the entry records why the subjects were not told directly (Art. 34(3)).

The Art. 33 and 34 record for breach `seq`: the 33(3) content, the 72-hour clock and whether the authority was notified in time, the subject communication or the 34(3) exemption, the 33(5) documentation, the evidence entries and the fields the controller adds. Read-only.

Explain ONE access decision: {allowed, reason, via}. `via` is the grant record's id when access came from a grant, "owner" when the agent wrote the record itself, and None on a denial. Use it to inspect an ACL a record at a time instead of inferring it from what a recall did or did not return.

ECHO-GUARD FOR CODE (read-only, no LLM): scan a generated snippet and flag every deprecated symbol it RESURRECTS. Call it on your own output before returning code. Whole-identifier match (`foo` matches `foo(` and `x.foo`, never `foobar`); a lexical token scan, not an AST parse. Returns [{symbol, replacement, reason, occurrences}] for each deprecated symbol the code still uses (empty = clean) so you can rewrite before emitting. Powered by keyed supersession — records come from deprecate_symbol.

WRITE-TIME conflict check (read-only, no LLM): BEFORE you remember() a fact, see whether it would CONTRADICT an existing memory — a value change on a managed `key`, or a numeric/negation clash with a similar memory. Returns the conflicting records (empty list = clean) so you can flag or gate the write instead of blindly trusting it. A pure duplicate does NOT flag; a contradiction that merely looks like a duplicate does. Detects, never writes — call remember() yourself once you decide.

WRITE-TIME self-narration guard (read-only, no LLM): does this candidate memory read as the ASSISTANT narrating its own reasoning/state ("as an AI...", "I think...", "I remember that...") instead of a fact about the user/world? LLM memory-writers routinely store their own hedges and self-talk as if they were user facts, silently polluting the store. Returns {'self_narration': bool, 'markers': [...]} so you can gate or rewrite the write before remember(). Flags, never blocks.

CAUSAL staleness: has the SOURCE each memory came from CHANGED, or gone? Returns a report, not a boolean. Decay elsewhere in this library is temporal — a half-life on age — and age cannot tell a fact that has been true for five years from one that rotted in a week. This asks the question that can: did the thing this memory is about actually change? Per record: FRESH (source resolves, still hashes the same), DRIFTED (resolves, content changed — re-read it, don't serve it blind), ORPHANED (an addressable source that is gone), UNRESOLVED_HERE (a relative or non-file locator the default resolver could not address from this working directory — read it with `resolution_base`, it is not evidence of absence), UNCHECKABLE (a source is named but carries no fingerprint, or names the WRITER rather than a document), NOT_BINDABLE (no source at all, e.g. a decision: nothing to fingerprint in any window, so it is left out of the denominator rather than counted as a gap). READ `UNCHECKABLE` FIRST. Fingerprints are only taken when `remember(source={"doc": <path>})` points at a file that existed at write time, so on most stores this is the large number and the honest denominator. `ok` is false whenever NOTHING was checked -- zero drifted over zero checked is not a clean store -- including a store whose records carry no source at all (every record NOT_BINDABLE). `verdict` names the state: CLEAN (something was checked and nothing moved), DRIFTED (a source changed, vanished, or had already moved at capture) or NOT_CHECKED; `not_checked` counts the records that could not be checked by reason, the coverage ratios are null rather than 0, and a `problem` says that nothing was verified. Measured on our own deployment before shipping this: 210,544 records, 98.3% carrying a `source`, 0.01% carrying one that resolves to anything you could fetch again. Scoped to the bound tenant/project when there is one.

Close a partition when its process ends. A context partition erases its records (disposition erased); a process or agent partition keeps them unless `disposition="erased"`. A lifecycle entry is recorded in the action ledger when one is on.

CI/CONTINUOUS compliance GATE (read-only, no LLM): assert the invariants a store claiming AI-Act record-keeping must hold and report any regression. Returns {ok, violations, checked} — violations include receipts_disabled (Art.12/19), integrity_failed (Art.12/15), pii_over_retention (GDPR 5(1)(e)). ok=False means the memory posture regressed. Needs INSPEXIMUS_RECEIPTS=1 for the record-keeping checks. `prior_anchor` (an anchor() dict an auditor pinned earlier, out of band) adds the APPEND-ONLY check: not_append_only (Art. 12/19) fires when today's history is not a consistent extension of it. This surface used to drop the argument, so that violation could never fire here however the store was rewritten — `checked` never listed append_only, but the CLI's own `--prior-anchor` did the check and the tool docstring advertised the violation. The one operator-ADVERSARIAL check of the four is the one an auditor is most likely to want. `expected_pubkey` (hex, optional) binds integrity_failed to the key the receipts should be signed by; defaults to INSPEXIMUS_RECEIPT_PUBKEY, the same pin verify_writes uses.

EU AI Act AGENT-MEMORY compliance EVIDENCE (read-only, no LLM): an article-labelled report (AI Act Art. 12/15/19; GDPR Art. 17/30/5(1)(d)) with LIVE counts from this store and an honest per-control status ('evidence' / 'available' / 'needs_receipts'). Scope: the agent-memory slice only — EVIDENCE, not a certification; obligations bind the deployer, not the tool. For the record-keeping controls, enable the tamper-evident chain with the env var INSPEXIMUS_RECEIPTS=1. `expected_pubkey` (hex, optional) binds `summary.integrity_verified` to the key the receipts should be signed by; defaults to INSPEXIMUS_RECEIPT_PUBKEY. Without either, `limits` says what it does not cover.

Run the consolidation 'dream' pass over ALL memories: flag universal-matcher 'hub' notes, link near-duplicates, and (if `keep` is given) supersede the lowest-value surplus. Includes the STATE-TOGGLE guard — a high-similarity pair that is a polarity clash (a preference flip) is superseded, not merged, so recall returns the new state. ADDS a derived layer only; never edits or deletes raw memories. Returns a report (active / hubs_flagged / linked_pairs / toggled / ...).

Cluster-TRIGGERED consolidation: consolidate a semantic cluster only once it has grown past `threshold` members — not a global blanket. Avoids prematurely consolidating sparse topics (raw episodes stay the best representation) and unbounded growth in dense ones. It changes nothing until a cluster is ripe, but each call clusters every active record. Returns clusters_total / clusters_fired / linked_pairs / ...

Surface mutually-incompatible memories (related in content, opposite in polarity) for review. It FLAGS, never auto-resolves — silent rewrites destroy trust. Returns the conflicting pairs.

The Art. 20 record for corrective action `seq`: the non-conformity, the action, the causes, the parties informed and those not, whether the authority was informed when the system presented a risk, the evidence entries and later entries that refer to it. Read-only.

The obligation matrix for THIS store: every duty of an AI-agent operator under the EU AI Act (Regulation (EU) 2024/1689 as amended by 2026/1744) and the GDPR, each in one of four states. EVIDENCE: this store holds at least one artifact for the duty, counted. CAPABILITY: the library produces the artifact and this store has none yet. NOT COVERED: nothing in the library produces it, and the row names the function that would. NOT APPLICABLE: the duty falls on someone else (a general-purpose model provider), with the reason. Read-only, no LLM. Evidence, never a certification: a row says an artifact exists, not that it satisfies an assessor.

Close the accuracy loop: when the work some recalled memories fed gets a real verdict — a forecast resolves, a claim is ruled correct/wrong, a plan succeeds/fails — call credit(those ids, outcome) so each memory's track record updates. Future `recall` then ranks by WAS-IT-RIGHT (a Beta good/bad posterior), not merely by being-recalled. `outcome`: 'good'/'right'/'correct' vs 'bad'/'wrong'/'failed' (or pass a bool / a signed number, as JSON or as text such as "+1"); any other word is refused, never guessed. Counts only grow: a negative `weight` is refused. Raw text is never edited. Returns what updated, once it is in the store file. `warrant` NAMES THE EXOGENOUS ARTIFACT that produced the verdict — a resolved ticket, a graded forecast, an external run: ground truth the credited memory did NOT author itself. Only a warranted good raises `good_warranted`, which `credit_requires_warrant` counts to block the MINJA self-graded-outcome loop (an agent crediting its own recalled poison as a success). It exists on this surface because it did not, and that was the whole bug. The library has accepted `warrant=` all along; this tool dropped it, so every credit an agent could make over MCP was unwarranted BY CONSTRUCTION. Measured 2026-08-09 on a real deployment: `good` on 470 records, `good_warranted` on **0 of 220,213**. Same shape as `with_warrant` missing from `recall` — the mechanism works given its input, and the surface never delivered the input. PASS IT ONLY FOR A RE-CHECKABLE ARTIFACT. Empty is the correct value when you graded the outcome yourself; a token invented to make the field non-zero forges precisely the signal the guard tests.

The material for an Art. 86 explanation of the decision at action `seq`: the action with its model and principal, the memory state it acted on and what recall returned (with provenance as it stands now), the oversight events on it, the disclosures in its session, and the incidents, risks and corrective actions that refer to it, in one document from the chain. With `actor` the fact that an explanation was produced is logged as a rights:explanation entry carrying the document's hash.

The declaration at `seq` as one machine-readable document in the Annex V order (Art. 47(1)), with the Art. 43 procedure, the Art. 48 marking and the ledger hash that binds it. Read-only.

Account in the write chain for a record a receipt vouches for that is no longer in the store because something other than inspeximus removed it (a raw SQL DELETE, a restored backup). verify_writes() otherwise reports it as "deleted out-of-band" forever, and forget() on a gone id writes no tombstone. This appends the tombstone with `actor` and `reason` inside the committed hash, basis `out_of_band`. It is the operator's declaration, not evidence of what was deleted. Refused while the record is still present (use forget) or when no receipt names it.

The EU AI Act Art. 26 deployer duties with the evidence this store and its action ledger supply (oversight recorded, incidents and the Art. 73 clock, log age against the six-month floor, disclosures, personal data inventory, chain verification), plus the GDPR Art. 35(7) DPIA and Art. 27(1) FRIA appendices built from the same evidence, the FRIA cross-referencing the DPIA per Art. 27(4). `operator_json` is a JSON object string with the deployer's own fields; every field it cannot write is marked OPERATOR INPUT REQUIRED. Not an assessment. `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.

CODING-AGENT REFACTOR RECORD (write, deterministic, no LLM): record that a code symbol `old` was replaced by `new` (a function/method/constant renamed or removed in a refactor). This is the fix for the single most common coding-loop memory failure ��� the model re-emitting a call the refactor already deleted because the old signature is still in its context. A later deprecate_symbol of the same `old` supersedes the replacement. Then call check_code(generated) before emitting code. Returns the recorded deprecation, and the verdict on the write as `remember` gives it: a return to a replacement already retired is retired on arrival by the echo guard and comes back `blocked: true`, with `current_id` the deprecation that stands.

AUDITOR-side FORK PROOF: given two co-signed anchors (e.g. the head shown to client A vs client B), is there a witness that validly co-signed BOTH over an INCONSISTENT pair of heads (same log size, different tip)? One such witness is cryptographic proof of a split-view — an honest witness refuses the second signature, so a valid double-sign means the operator presented divergent histories. This is the check behind "prove my agent's memory store showed one history to one reader and a different one to another". Returns {fork, inconsistent, at, evidence, both_cosigned, malformed}. Honest limit: decidable from head commitments only at a shared size; different-size logs need verify_consistency (reported inconsistent=False = undetermined). `malformed` names any side whose sth_hash does not bind its own fields — that is a head no witness could have signed, not merely an unproven fork. Worked example: docs/TRANSPARENCY.md.

AFTER an erasure: what does the store's lineage say survived? The hard case is not the record — it is the summary built from it, which no longer looks like the subject's data. Reports records still attributable to `subject`, derivatives that outlived an erased origin, dangling lineage, and removals with no deletion tombstone. READ `coverage` BEFORE `verdict`: every structural check walks DECLARED `derived_from` edges, so a store that declares none returns `verdict="unaudited"` (nothing was inspected) and one whose writers claimed derivation the walk could not resolve returns `verdict="partially_audited"` (coverage incomplete by a known amount); neither is a pass. `declared_ratio` is store-wide and never vouches for one subject -- `coverage["subject_reachable_records"]` counts what the walk could actually follow to THIS subject, and 0 means the structural checks said nothing about it. Housekeeping deletions (capacity eviction, keep-budget) land in `advisory`, not `residue`. `values` adds a text scan that is an explicit heuristic and never moves the verdict. Read-only; evidence about what the store RECORDED, not proof that no copy of the material remains.

A portable, INDEPENDENTLY-VERIFIABLE erasure certificate — the auditor-grade receipt proving records were erased (optionally scoped to one `request_id`). Hand it to a third party who can check it WITHOUT your store; pass `expected_pubkey` to also assert a specific signing key (defaults to INSPEXIMUS_RECEIPT_PUBKEY, which `self_check` is then bound to). The GDPR Art.17 / EU AI Act Art.12 proof object.

Audit view of every deliberate erasure: total tombstones plus each {memory_id, ts, request_id} — the read-only 'what was erased, when, for which request' log a DPO/auditor asks for. Content-free (no PII).

DID THE BYTES ACTUALLY GO? (read-only, no LLM) Scan a directory for values that should have been erased — ANY store, not just this one: a vector database, a sqlite history, a JSONL trace, another library's data dir. `delete()` returning success is not the same as the value being gone from disk. Separates three outcomes, and the distinction is the point: LIVE (a table still holds it in a row — the system retained it), UNRECLAIMED (in the bytes but in no row — the storage engine has not reclaimed the page; run VACUUM/compact, and do NOT report this as a vendor defect), PLAIN (a JSON, log or backup still has it; nothing reclaims that on its own). Never echoes the values you pass — findings carry a 12-char fingerprint, because a tool that hunts a secret and then prints it into a transcript is itself the leak. A file it could not read, a directory it could not list, or a symlinked directory it did not enter makes the verdict False and is named in `skipped`: "clean" must never mean "we did not look at that part".

Write the action ledger as an IETF draft-sharif-agent-audit-trail-04 JSONL file: twelve mandatory fields per record, hash-chained per RFC 8785, so tooling that reads that format can read this ledger. The memory digest and recalled ids travel under action_detail.inspeximus; the salted digests are exported under their own name, never as the draft's plain input_hash. `agent_id` is a URI, `agent_version` a semver.

GDPR Art. 15 access: everything this store holds about `subject` (a source doc identifier), resolved exactly as erasure resolves it, with provenance, correction history, the erasure tombstones already recorded, and the ledger actions taken while those records were recalled. Writes one rights:export entry to the action ledger carrying the export's manifest hash. With basis="portability" the same document is the Art. 20 response: labelled, with a versioned format and per-record portable flags, logged as rights:portability. Refuses an ambiguous subject unless allow_ambiguous is set.

TRULY DELETE memories — the one op that removes content (everything else is append-only: supersession only demotes). Use for an erasure / right-to-be-forgotten request, a poisoned or false memory, or a hard correction. Pass `ids` (memory ids to drop) and/or `where_contains` (delete every memory whose text contains this substring, case-insensitive). Verified forgetting: the records are deleted AND their ids are scrubbed from every survivor's links + supersession pointers + the caches, so a forgotten memory cannot resurface via recall or a later consolidation pass. `dry_run=True` PREVIEWS the match (returns {would_forget, ids, sample, dry_run:True} with a few matched texts) and deletes NOTHING — always dry-run a bulk `where_contains` first. Returns {forgotten, ids, scrubbed_links}. `basis` (the decision reason), `request_id` (the DSAR/ticket this belongs to), `authorized_by` (the authorising principal's public key) and `authorization` (their signature) are recorded with the erasure as the Art.30 account of WHY and on WHOSE authority. None of them was on this surface, so an erasure performed over MCP left a record that it happened and nothing about who ordered it.

Erase detected PII — of the given `types` (default all), optionally scoped to a `subject`. Deletes the offending content deterministically (not an LLM guess). Returns what was erased. `basis` records the legal/operational reason with the erasure (Art.30). It was not on this surface, so PII erasures performed over MCP carried no stated ground.

Right-to-erasure by SUBJECT (GDPR Art.17 / DSR): delete every memory about `subject` AND scrub its id from survivors' links/supersession pointers, so it can't resurface via recall or consolidation. `basis` records the legal/operational reason. Returns a receipt (`erased` count, ids, scrubbed_links, tombstones, request_id, coverage, residue_in_store) you can keep as evidence. RUN IT WITH dry_run=True FIRST. This cascades through inherited lineage, so it commonly erases more than the records that name the subject: the preview returns {would_erase, direct, inherited, sample, also_carrying} and changes nothing. `inherited` is the count you cannot predict, and `also_carrying` names the OTHER subjects whose data goes down with this request — one erasure is quietly several more often than not. If the call raises AmbiguousSubject, the subject you passed canonicalizes to the same key as a DIFFERENT source in the store (e.g. two people under one host: crm.example.com/alice and crm.example.com/bob), so erasing would delete a third party's records. Read the message, confirm which subject is meant, and then choose: `exact=True` erases only the records whose RAW source string is this subject (plus their lineage) and LEAVES the colliding subject alone — prefer it, it completes the DSAR without touching anyone else. `allow_ambiguous=True` erases every colliding subject together, so pass it only if you really mean that. This surface used to offer allow_ambiguous alone and this text named it as THE answer, which pointed the caller at the over-deleting half of the choice; measured, that erased a third party's record where exact=True kept it. Collisions are not rare: canonicalisation is host/collection level, so 'employee/1001' and 'employee/1002' share a canonical form. `authorized_by` (the authorising principal's public key) and `authorization` (their signature over erasure_challenge(subject, request_id)) are recorded in the tombstone's `auth` field — the Art.30 record of WHO aut…

Fetch ONE memory's FULL record by id (complete untruncated text + all fields). The companion to recall's progressive-disclosure default: recall returns compact snippets + ids cheaply; call get(id) only for the few memories you actually need in full, instead of paying to dump every full record into context. Returns {} if the id is unknown. A record the read guard quarantined comes back with its text and value withheld, as recall withholds it, unless `include_quarantined` is set.

Fetch ONE memory's full record AS a named agent -- the scoped companion to `get`, so an agent that found a hit through `recall_as` can read it in full without the unscoped `get` handing it back the whole store's records by id. Returns {} when the id is unknown OR the agent has no access; those two cases are deliberately indistinguishable, so this cannot be used to probe for the existence of a record.

One-call GOVERNANCE snapshot: erasure/retention posture, tamper-evidence status of the write chain, and integrity counters — the summary a DPO/CISO or auditor asks for. Deterministic, no LLM. `expected_pubkey` (hex, optional) pins the tamper-evidence half to the key the receipts should carry; defaults to INSPEXIMUS_RECEIPT_PUBKEY. Without either, `proof.expected_pubkey` is null and `limits` says what the verdict does not cover — this report used to be unable to pin at all.

Give another agent READ access to a SUBSET of this store's memories, and record the act. Pass EXACTLY ONE selector: `scope` (a memory's meta scope), `tag`, `key` (a supersession key), or `ids` (explicit record ids). Membership is exact-match on a stored field -- no embedder, no similarity threshold, no LLM -- so the set a grant authorises is the same tomorrow as it is today. There is no query selector on purpose: a grant whose membership came from a similarity score would silently widen after a re-embed or a corpus change. `by` names the granting agent (a grant issued by an agent covers only records THAT agent owns; omit it for an operator-wide grant). Read with `recall_as(agent, ...)`, end it with `revoke(...)`. Both acts land in the write-receipt chain, so `grant_log()` and the audit bundle show who could read what, and when it was withdrawn. Passing no selector is refused rather than read as "everything".

EVERY access-control act -- grants, revocations, and the ones a later act retired -- newest first. The auditable answer to "who could read this, and when was it taken back". Read-only.

The grants in force right now (optionally for one agent), newest first. Read-only.

The full validity timeline for `key`: every value it has held, in event-time order — the audit trail a plain vector store cannot produce. Read-only. A quarantined version keeps its row with its text and value withheld, unless `include_quarantined` is set.