research: define Causal Memory Controller (CMC) thesis and evidence path

[safal207]

Why this matters

Agentic systems increasingly fail not only because they lack tokens or storage, but because their context and responsibility chains break across steps. Ordinary memory stores bytes. Causal memory should preserve why a memory write, state transition, or effect was allowed.

This issue defines a staged research path for a Causal Memory Controller (CMC): a hardware-adjacent memory/controller primitive that stores causal metadata next to ordinary memory operations.

The goal is not to claim that we already have a chip. The goal is to build a credible proof path from software semantics to embedded profile, simulator, FPGA model, and investor-facing evidence.

Core thesis

CPU computes.
GPU accelerates.
Ordinary memory stores bytes.
Causal Memory stores why a byte, transition, or effect was allowed to exist.

For agentic systems, the useful memory problem is not only capacity. It is continuity:

context -> permission -> action -> memory write -> later effect

CMC should preserve that chain so the system can audit whether an action was operationally successful but causally invalid.

Relation to existing repos

• CML / vCML: causal record semantics (actor, action, object, permitted_by, parent_cause).
• CaPU: commit-before-effect execution boundary.
• T-Trace / LTP: trace/replay/admissibility surface.
• CMC: hardware-adjacent memory/controller direction for causal metadata and bounded causal continuity.

Proposed document

Add:

• docs/hardware/CAUSAL_MEMORY_CONTROLLER.md

The document should define:

1. Problem: ordinary memory does not preserve causal permission lineage.
2. CMC thesis: causal metadata plane next to memory/effect operations.
3. Minimal record model: address/value hash/writer/permitted_by/parent_cause/timestamp.
4. Invariants:
   • write without cause is rejected or audited
   • effect without committed cause is rejected
   • DMA/device write without parent cause is flagged
   • secret read -> network/effect without causal chain is invalid
5. Software simulator plan in Rust.
6. Embedded profile plan in C/Rust no_std.
7. FPGA proof-of-behavior plan.
8. Investor evidence path.
9. Non-claims and scope boundaries.

First technical milestone: CMC-0 simulator

Create a Rust reference simulator before hardware work:

cmc_write(address, value_hash, cause)
cmc_read(address, requester, cause)
cmc_effect(effect_id, parent_cause)
cmc_audit()

Expected outputs:

• accepted write with valid cause
• rejected/audited write with missing cause
• rejected effect before causal commit
• causal chain reconstruction for a memory-derived effect

Evidence path for investors

The project should produce artifacts in this order:

1. Thesis document.
2. Rust simulator with deterministic tests.
3. Benchmarks showing overhead and audit value.
4. Embedded fixed-size ring-buffer profile.
5. Device/actuator demo where effect is blocked without causal commit.
6. FPGA state-machine simulation proving forbidden paths cannot assert execute/write-enable.
7. Architecture note comparing firmware-only vs controller/FPGA/silicon paths.

Non-claims

CMC is not currently:

• a physical memory chip
• a replacement for RAM, CXL, TPM, HSM, CHERI, or secure enclaves
• a proven silicon architecture
• a full AI memory system

At this stage it is a research path for a causal metadata plane and controller-style proof of behavior.

Acceptance criteria

• docs/hardware/CAUSAL_MEMORY_CONTROLLER.md exists.
• It clearly separates CML, CaPU, and CMC responsibilities.
• It defines the minimal causal-memory record model.
• It proposes Rust simulator milestones.
• It proposes embedded/FPGA milestones without overclaiming hardware readiness.
• It includes investor-facing evidence milestones.
• It includes non-claims and comparison boundaries.