Technical Report 5 of 6 — preliminary, not peer reviewed

Provable Memory for Continual AI: A Design Space for Ledger-Based Machine Learning Memory

Akash Deep · Aethelas Private Limited, Patna, India

Position paper · organizing four operations on one shared substrate

Abstract

This is a position paper, not an empirical report. We propose organizing a family of related capabilities — continual learning, resistance to catastrophic forgetting, verifiable model history, and machine unlearning — as four operations on a single shared substrate: an immutable, append-only training ledger. We argue this framing clarifies what such a substrate must provide, situate it relative to existing work on blockchain-based AI audit trails, and identify the specific technical gap — using ledger history as active replay memory during training, rather than solely as a post-hoc audit log — that we believe is comparatively underexplored and is the subject of our empirical reports (Technical Reports 1-3).

1. The proposal

We propose treating a model's training history as a single memory substrate with four properties, rather than as four separate engineering problems:

Learn — new training examples are appended to the ledger as they are encountered (write).
Remember — past examples are replayed from the ledger during ongoing training to resist catastrophic forgetting (read, applied to training).
Prove — the model's parameter state at any past point can be verified against a cryptographic commitment recorded at that point (read, applied to verification).
Unlearn — a specific example's influence can be removed by rolling back to the state before it was learned and replaying the remaining history, excluding it (rewrite, with proof of exclusion).

Under this framing, forgetting-resistance and unlearning are not separate mechanisms requiring separate infrastructure — they are the same replay operation run forward (include everything) or with an exclusion set (omit specific examples).

2. Relationship to existing work

Recording AI decisions and model provenance on a blockchain or other immutable ledger is an active area of applied and academic work; recent proposals describe permissioned-ledger architectures for training provenance, deployment integrity verification, and post-deployment behavior auditing, and industry commentary has described a broader 2026 shift toward what is termed "auditable" or verifiable intelligence, with decentralized, blockchain-governed AI models already deployed in some regulated sectors. We do not claim the general idea of ledger-based AI audit trails as novel; that space is genuinely active.

3. Open questions this framing raises

What we believe is comparatively underexplored is the specific use of the ledger as active replay memory that shapes future training — as distinct from a passive record consulted only after a decision has already been made. Most audit-trail proposals we are aware of log a decision after the model produces it; our empirical reports test using the same log to change what the model learns next. This is a narrower and more specific claim than "blockchain records AI decisions," and we present it as such.

Sampling strategy — Technical Reports 1 and 3 suggest that how replay examples are sampled from the ledger (uniformly at random versus balanced across tasks or time) materially affects the plasticity-stability trade-off and the viability of class-incremental settings. This is unresolved.
Storage growth — an unbounded ledger grows linearly with training volume. At what scale does this become impractical, and what pruning or compaction strategies preserve the unlearning/provenance guarantees while bounding storage?
Proof granularity — our current implementation snapshots full model weights; for larger models this is likely infeasible, and a more compact proof (e.g. a Merkle commitment over weight deltas) may be necessary.
Formal unlearning guarantees — rollback-and-replay removes an example's direct training signal, but whether it removes the example's full statistical influence on the final weights (in the sense studied in the machine unlearning literature) is a distinct and stronger claim that this framing does not yet address or test.

4. Why this matters for regulated applications

Financial and other regulated AI applications increasingly require both explainability (why did the model decide this) and, separately, the ability to remove a specific individual's data on request. Treating these as two operations on one substrate, rather than two separate systems bolted onto a model, is the practical motivation for this design space — not an abstract architectural preference.

5. Conclusion

We do not claim to have solved continual learning, verifiable AI, or machine unlearning. We propose a way of organizing these problems around a shared substrate, identify the specific sub-question (ledger-as-active-replay-memory) we believe is underexplored relative to existing ledger-as-audit-log work, and report preliminary empirical tests of that sub-question in Technical Reports 1 through 3, including a negative result that bounds our own claims.