Status: research thesis / hardware-adjacent roadmap.
This document defines the first research path for a Causal Memory Controller (CMC): a memory/controller-adjacent primitive that preserves causal metadata next to ordinary memory and effect operations.
It is not a claim that CaPU or CML already provide a physical memory chip. It is a disciplined proof path from existing causal semantics toward simulator, embedded runtime, FPGA model, and possible hardware architecture.
CPU computes.
GPU accelerates.
Ordinary memory stores bytes.
Causal Memory stores why a byte, transition, or effect was allowed to exist.
Agentic systems do not only need more memory. They need memory with causal continuity.
For an agent, the critical chain is not just:
prompt -> context -> output
The critical chain is:
context -> permission -> action -> memory write -> later effect
When this chain breaks, a system can still look operationally successful while losing responsibility, authorization lineage, or causal grounding.
CMC exists to explore whether causal metadata can be kept close to memory/effect boundaries so later reads, writes, actions, and device effects remain auditable.
Ordinary memory answers:
address -> bytes
It does not answer:
who wrote this?
why was this write allowed?
what parent cause authorized it?
which later action used this memory?
can the resulting effect be traced back to a valid cause?
For agentic systems, robots, controllers, autonomous tools, and high-risk automation, this is a structural blind spot.
A model or agent may carry a large context window, external vector memory, or logs, but still lose the causal chain that explains why a state transition or side effect was permitted.
CMC treats causal continuity as a memory/control-plane problem, not only as an application logging problem.
CML / vCML -> causal record semantics
CaPU -> commit-before-effect execution boundary
T-Trace -> trace/event verification surface
LTP -> replay / admissibility / continuity protocol
CMC -> hardware-adjacent causal metadata plane near memory/effects
CML defines the semantic unit of causal memory:
- actor
- action
- object
- permitted_by
- parent_cause
- timestamp
- integrity hooks
CMC should reuse those semantics in a constrained, controller-friendly form.
CaPU defines the execution boundary:
Gate -> Incubate -> Commit -> Execute
CMC extends the same principle toward memory and controller operations:
No write/effect should become authoritative without causal permission, durable commit, and traceability.
CMC should emit trace events that can be replayed and verified by external tooling. Hardware-adjacent causal memory is only valuable if its behavior is externally inspectable.
A minimal causal memory entry can be represented as:
CausalMemoryEntry {
address: u64,
value_hash: bytes32,
writer: ActorId,
permitted_by: CauseId | PolicyRef,
parent_cause: CauseId | null,
timestamp: u64,
flags: EntryFlags,
}
The controller does not need to store full application data. It can store compact metadata next to, or parallel to, ordinary memory writes.
Possible storage strategies:
- Sidecar table: address/page/region -> causal metadata.
- Ring buffer: append-only causal event stream for constrained devices.
- Tagged region map: region-level causal labels, cheaper than per-byte metadata.
- Hybrid: region tags for normal operation, event records for sensitive transitions.
CMC-0 should model four operations:
cmc_write(address, value_hash, cause)
cmc_read(address, requester, cause)
cmc_effect(effect_id, parent_cause)
cmc_audit()
Records that a value or state was written to memory.
Questions:
- Was there a valid cause?
- Was the writer permitted?
- Does this write derive from an existing chain?
Records that an actor accessed memory.
Questions:
- Is the requester allowed to read this causal region?
- Does reading this memory create a causal dependency for later effects?
Records a boundary where memory-derived state influences an external effect.
Examples:
- network send
- actuator move
- payment/API call
- code deployment
- device command
Questions:
- Does the effect have a committed parent cause?
- Does it derive from valid causal memory?
- Is the causal chain reconstructible?
Runs deterministic checks over causal memory state and emitted event records.
A memory write that affects later decisions must carry a valid cause or be explicitly marked as an observed causal gap.
An effect must not be authorized unless it can reference a committed causal record.
If parent_cause references a missing record, the chain is causally invalid.
If sensitive memory is read and later used for network/device output, the effect must reconstruct a causal path back to the sensitive access.
Missing cause, malformed cause, expired cause, or failed commit must lead to HOLD, REJECT, EXPIRE, or AUDIT — not silent execute.
The first implementation should be a Rust reference simulator, not hardware.
Suggested layout:
rust/
cmc-core/
Cargo.toml
src/
lib.rs
record.rs
controller.rs
audit.rs
trace.rs
tests/
causal_write.rs
missing_cause.rs
effect_before_commit.rs
secret_to_effect.rs
Initial API sketch:
pub struct CausalMemoryController { /* bounded or simulated state */ }
impl CausalMemoryController {
pub fn write(&mut self, address: u64, value_hash: [u8; 32], cause: CauseRef) -> Decision;
pub fn read(&mut self, address: u64, requester: ActorId, cause: CauseRef) -> Decision;
pub fn effect(&mut self, effect_id: EffectId, parent_cause: CauseRef) -> Decision;
pub fn audit(&self) -> AuditReport;
}Expected tests:
- accepted write with valid cause
- rejected or warned write with missing cause
- rejected effect before causal commit
- reconstructed chain for memory-derived effect
- detected secret-read-to-effect without causal lineage
The simulator should produce deterministic outputs and golden fixtures before any embedded or FPGA work begins.
After the simulator, define a constrained embedded profile.
Target properties:
bounded memory
bounded execution time
fixed-size records
no dynamic allocation in the core path
small decision vocabulary
safe failure defaults
Possible implementation targets:
- Rust
no_std - C99 embedded profile
- MCU-friendly ring buffer
- RTOS middleware adapter
Minimal embedded record:
typedef struct {
uint64_t address;
uint8_t value_hash[32];
uint32_t writer_id;
uint32_t cause_id;
uint32_t parent_cause_id;
uint64_t timestamp;
uint16_t flags;
} cmc_record_t;The embedded profile should prove that causal metadata can be tracked without requiring a full desktop runtime or database.
Build a small middleware demo before FPGA.
Example demo:
sensor input
-> agent proposes action
-> memory state updated
-> CMC records causal write
-> CaPU commit check
-> device effect allowed or blocked
Possible scenarios:
- robot arm movement blocked without causal commit
- door unlock denied when parent cause is missing
- payment/tool call blocked when memory-derived authorization is stale
- network send denied after secret memory read without explicit chain
The demo must visibly show:
operational request exists
but effect is blocked because causal memory is invalid
This is the investor-friendly proof moment.
Only after CMC-0 and CMC-1 should we explore FPGA.
Minimal port sketch:
CauseIn
MemOpIn
CommitIn
ReadOut
WriteOut
EffectOut
TraceOut
ViolationOut
Minimal hardware invariant:
WriteOut.enable or EffectOut.execute MUST NOT assert
unless a valid committed cause exists for the same operation.
Required simulation tests:
- valid cause -> write enable allowed
- missing cause -> write enable blocked
- commit fail -> no effect
- expired cause -> no effect
- trace event emitted for every decision
The FPGA prototype should be described as a causal controller/state-machine proof, not a full CPU or memory chip.
The evidence path should be staged and falsifiable.
Deliverables:
- this thesis document
- simulator design
- invariant list
- non-claims
Investor question answered:
Is this a coherent new primitive, or just logging?
Deliverables:
- Rust simulator
- deterministic tests
- golden fixtures
- small benchmark
Investor question answered:
Can causal memory behavior be reproduced deterministically?
Deliverables:
- embedded profile
- fixed-size ring buffer
- device/actuator demo
- blocked-effect example
Investor question answered:
Can this protect or explain real device/tool effects?
Deliverables:
- FPGA state machine
- simulation assertions
- forbidden-path proof
- host interface sketch
Investor question answered:
Is there a credible path from software semantics to controller hardware?
Deliverables:
- architecture whitepaper
- area/power/latency estimate
- comparison against firmware-only path
- partner/lab pathway
Investor question answered:
Does dedicated hardware add value beyond software?
| System | Stores | Does not store |
|---|---|---|
| RAM | bytes | why the bytes were authorized |
| database | records | causal permission lineage by default |
| logs | events | enforceable memory/effect continuity |
| vector memory | semantic similarity | responsibility chain |
| tracing | execution flow | whether a memory-derived effect was causally permitted |
| CMC | causal metadata for memory/effects | full application state or model reasoning |
CMC is not about making memory larger. It is about making memory causally accountable.
CMC is not currently:
- a physical memory chip
- a replacement for RAM
- a replacement for CXL
- a replacement for TPM, HSM, CHERI, secure enclaves, or RTOS safety kernels
- a proven silicon architecture
- a full AI memory system
- a general-purpose processor
At this stage, CMC is a research direction and proof path for causal metadata near memory/controller boundaries.
- causal metadata associated with memory writes, reads, and effects
- deterministic audit of memory/effect lineage
- commit-before-effect compatibility with CaPU
- simulator, embedded profile, and FPGA proof path
- investor-facing evidence artifacts
- real silicon design
- production memory controller replacement
- general AI long-term memory product
- full OS virtual memory implementation
- formal hardware certification
Agentic AI does not only need more memory.
It needs memory with causal continuity.
Ordinary memory stores what changed.
Causal Memory stores why the change was allowed.
CMC is a staged path toward memory/controller systems that preserve
actor, permission, parent cause, and responsibility lineage close to
where memory-derived effects happen.
- Implement CMC-0 as a Rust simulator.
- Add deterministic tests for missing cause, valid cause, and effect-before-commit.
- Emit a simple trace format compatible with CML/T-Trace concepts.
- Add one benchmark: overhead of causal metadata tracking per write/effect.
- Create a small investor demo: memory-derived effect blocked because causal lineage is missing.
The goal is not to sound like hardware too early. The goal is to build an evidence ladder that makes hardware feel inevitable only after the software and embedded proofs are real.