Add memory-blackbox (agent memory provenance ledger) - #34
Open
lavkumarv wants to merge 1 commit into
Open
Conversation
Signed-off-by: lavkumarv <lav.kumar.dev@gmail.com>
lavkumarv
force-pushed
the
add-memory-blackbox
branch
from
September 7, 2026 07:45
3f29214 to
cf1ab17
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds one row to Provenance, Instrumentation & Observability.
memory-blackbox instruments the agent's memory boundary specifically, rather than the syscall or egress boundary that most entries here cover. Every memory read and write goes into an append-only ledger — BLAKE3 hash chain (proves no row was edited), periodically checkpointed signed Merkle roots (proves no row was removed, including tail truncation), Ed25519 signatures on every entry with the key held by the engine and never reachable by the agent — plus a provenance DAG over sources, writes, retrievals, and actions.
That makes the post-incident queries possible:
tracean agent action back to the memory write and source that caused it,blast-radiusfor the forward closure of a poisoned source,verifyfor the three integrity properties above, androllback, which quarantines a source and its closure by appending events rather than deleting them.Closest neighbour in the section is Crux, which also uses Ed25519 receipts over BLAKE3-chained storage; the difference is scope — Crux is a memory/retrieval daemon, this instruments existing stores through adapters (Mem0, Chroma, Letta, pgvector,
MEMORY.md/CLAUDE.mddiffing), an MCP gateway that forwardstools/callbyte-identically, or a sidecar in front of hosted vector DBs.Honest limits, stated in the entry: it is reconstruction only and enforces nothing at runtime; capture is only as complete as the paths you route through it (a
reconcilecommand flags backend entries with no ledger record, i.e. writes that bypassed capture); Merkle anchoring to an external transparency log is on the roadmap, not shipped. Apache-2.0, early development, 0.1.0 on PyPI.I left off the 🔥 marker since that appears to be your own highlight — happy for you to set it or not.