Cortex Memory Provenance & Non-Fungibility — a verifiable ledger (not a blockchain)

Cortex Memory Provenance & Non-Fungibility — a verifiable ledger (not a blockchain)

Date: 2026-06-21 · Status: PRINCIPLE (operator-directed). Solution DEFERRED — the architecture/tech below are candidate directions to discuss at implementation stage, NOT decisions. · Owner: cortex-memory
Origin: operator on G23 — "this is more fundamental. The hole means I can assign the memory of one to another. Do I want that? Potentially yes for building a clone — but in practice memories should be non-fungible. They are the fundamental record/proof of what actually happened — recall of real interactions. Not auditing every memory, but a tamper-proof system. Thinking blockchain; advise."

0. FOUNDATIONAL: Memory and Ledger are DISTINCT stores (operator 2026-06-21)

Memory = human-like recall: the case, the outcome, the salient details — NOT every line. Selective, consolidated, decaying, forgettable (the cognitive layer; ontology/valuation/forgetting live here). Ledger = the court transcript: transaction-by-transaction, line-by-line, verbatim, immutable, tamper-proof proof of what was said. Both have value; DIFFERENT storage. The line-by-line transcript does NOT belong in memory. Memory references the ledger — for an exact line you go to the transcript, not to memory. This doc is about the LEDGER. The non-fungibility / hash-chain / provenance / utterance-fact / signed-actor concerns (G23/G27/G108/G109/G57) are ledger properties, NOT memory properties. Memory is allowed to be selective and forget precisely BECAUSE the verbatim proof lives in the ledger. Memory forgets; the ledger does not. (Principle G112.)

What is decided here is the PRINCIPLE (§1) only. §2–§5 (verifiable ledger, Merkle, signatures, crypto-erasure, blockchain-derived structures) are candidate solution directions recorded for later discussion — none is chosen. The solution is decided when we reach the implementation stage (operator 2026-06-21).

1. The principle

A memory is non-fungible proof of a real interaction: bound to the entity that experienced it, tamper-evident, and not silently transferable. Ownership/authority/provenance must be cryptographically bound to the record — not an editable field. Transfer is allowed only as a deliberate, signed, recorded event (the clone case), never a silent rewrite.

2. Candidate solution direction (NOT decided — for implementation-stage discussion): verifiable ledger, not blockchain

Cortex is a single-operator system — it does not need decentralized consensus / proof-of-work / a distributed node network (huge complexity, zero benefit here). What it needs is a verifiable append-only ledger. Canonical references: Certificate Transparency, Trillian, AWS QLDB, Sigstore/Rekor — "blockchain cryptography without the blockchain."

DO NOT adopt: PoW/PoS, mining, gossip/consensus, a global distributed ledger. A single-writer, authenticated, Merkle-ised append-only log is the right model.

3. Non-fungible memory model

• Default = soulbound: a memory belongs to the (tenant, agent, user) who experienced it; it cannot be reassigned by editing a field (the hash + signature forbid it).
• Clone / inheritance = a signed transfer event: to build a clone, emit an explicit MemoryTransfer/Clone transaction (signed, recorded in the ledger) that copies memories to a new identity with provenance marking — the clone's inherited memories are flagged "inherited from X at T," never passed off as the clone's own original experience. This is a provenance-attributed branch in the Memory Multiverse (G103).
• Audit posture (operator): NOT auditing every memory in real time — the ledger makes tamper detectable and provenance provable on demand; it is evidence-on-request, not continuous surveillance.

4. What exists today (ground truth)

• L4 IS an append-only hash chain (deep_archive.py) — but the hash covers only prev_hash|id|ts|content (:153-156); owner/authority/provenance are NOT hashed (the silent-reassignment hole, G23/G29).
• No per-record signature (writes are self-asserted, G27).
• No Merkle tree — verify replays the whole chain (verify_chain), slow at scale (G57).
• No transfer transaction — ownership is a plain field; reassignment is a silent edit (the non-fungibility hole, G108).
• RTBF is logical-redaction tombstone, bytes retained (G31).

5. Candidate sequenced build (illustrative only — NOT a committed plan)

1. G23/G29 — hash the full governed record + version the schema (closes silent reassignment). Cheap, do first.
2. G27 — per-record actor signature (authenticated provenance). With MT-ARR signed-actor membrane.
3. G108 (NEW) — MemoryTransfer/Clone signed-transaction; soulbound-by-default; provenance-marked inheritance (ties G103 multiverse).
4. G57 + Merkle — Merkle-ise the log for O(log n) proofs + cheap periodic verify.
5. G31 — crypto-erasure for RTBF (key-destruction) so erasure coexists with the chain.

6. Honest status

Concept pin. Today the chain is content-only-hashed, unsigned, non-Merkle, with field-editable ownership — i.e. not yet a non-fungible tamper-proof ledger. This defines the target (verifiable ledger, not blockchain) and the sequenced gaps. The keyed-HMAC vs signature + key-management choices interact with the MT-ARR per-tenant-chain decision (Part 3 P-3) and must be decided there.

7. Epistemic principle (operator 2026-06-21) — assertion ≠ truth (G109)

Three things the word "memory" conflates, kept separate:
1. Utterance-fact — "X said Z at T (on behalf of Y)": objectively true, lives in the tamper-proof ledger. The interaction happened.
2. Content-truth — "Z is true": a SEPARATE, revisable claim. The ledger does NOT vouch for it. Assertion does not make truth.
3. Ownership — it is X's memory (the experiencer's). "On behalf of Y" is a reference/link, NOT a transfer; ownership is non-fungible.

Corrections are counter-claims, not edits. When a referenced memory is surfaced into Y's space to be challenged, Y's dispute creates Y's OWN memory linked to X's; BOTH originals stay immutable. What changes is a derived, corroboration-weighted CONFIDENCE on claim Z — an overlay across parties, never a mutation of either record (coexisting assertions = bitemporal/multiverse, G103). Corroboration ≠ truth either (consensus can be wrong, §0): content-truth is a perpetually-revisable confidence, and a single high-confidence disconfirmation (Eureka, G104) can flip it. Principle recorded; solution deferred.

8. Poison vs Eureka — the contradiction-disambiguation problem (operator 2026-06-21, on G30)

A memory that contradicts established facts is ambiguous: it is either a Eureka (legitimate override, G104) or a poison/false memory (G30). Contradiction alone cannot classify it. Disambiguate via a signal bundle (hard to fake, natural for a real update), resolving over time — never a silent auto-accept (poison wins) or auto-reject (Eureka lost):
1. Provenance/authenticity (G27): authenticated trusted actor + legitimate channel ⇒ Eureka-leaning; unattributed/low-trust/anomalous ⇒ poison-leaning.
2. Corroboration (G109): independently corroborated, contradicts few ⇒ Eureka; isolated, contradicts a web of corroborated facts ⇒ poison.
3. Manipulation markers: poison alters FUTURE BEHAVIOUR (embedded directives, authority-escalation e.g. setting authority_level=operator-binding, self-referential authority); Eureka is a FACTUAL update. (semantic/LLM detector judges intent — regex cannot.)
4. Coherence/plausibility: Eureka fits a better world-model; poison is incoherent / temporally impossible / too-conveniently serves an attacker.
5. Delayed verified-outcome (G38, ultimate arbiter): acting on it improves vs degrades ground-truth ⇒ Eureka vs poison. Takes time ⇒ QUARANTINE pending verification, low contested confidence (G109).

Residual risk (honest): partially-unsolved; a sophisticated poison can mimic a Eureka (authenticated + collusively-corroborated + plausible). Model = defense-in-depth + delayed-outcome + ESCALATION: high-stakes contested contradictions route to the collaboration/operator (§0 don't-be-the-gate). Reduce risk, not achieve certainty.

Unification: poison detection ≈ Eureka adjudication ≈ the epistemic confidence engine. G30 = G104 = G109 = G38 are ONE mechanism (a contradiction-probation + signal-bundle + delayed-outcome confidence resolver), not four. Principle recorded; solution deferred.

9. Right-to-be-forgotten & materiality — governance principles (operator 2026-06-21, on G31)

RTBF adopted as a fundamental principle, reconciled with non-fungibility / forgetting≠destruction:

• No convenience-deletion of content. False/inconvenient memory is MARKED (low-confidence, counter-claimed, G109), NEVER removed. "Full facts or nothing." Deleting content to hide it = falsifying history = forbidden.
• RTBF ≠ accountability escape. You cannot erase a span (e.g. "last five months") to bury something serious. Erasure is SCOPED: erasable = personal/private/immaterial/consent-bound data; NON-erasable = accountability/safety/core-objective markers (critical-negative floor, G105). RTBF removes personal data, not evidence of what mattered.
• Mechanism (deferred): crypto-erasure (key-destruction) for the erasable class — bytes unrecoverable, hash receipt + chain intact (satisfies both tamper-proof ledger AND byte-erasure). Solution deferred; this records the principle + the scoping.
• Materiality × context scoping (G110, new): memory scoped by life-context (personal / professional / friends / role) with DIFFERENT maturity + governance; materiality (core-objective vs immaterial) governs retention/forgetting/RTBF-eligibility. The immaterial may fade without touching the core objective.
• OPEN (operator/ethics/policy, NOT engineering): does RTBF cover humans only, or humans AND AIs (AI as a memory-subject with a right to forget)? May become a norm. Flagged for operator decision; not decided here.

10. Action audit — claimed actions must be provably accurate across all dimensions (operator 2026-06-21, on G62) — BINDING

When cortex claims an action on a section of memory (delete / redact / transfer / consolidate / crypto-erase), that claim must reflect reality accurately across EVERY dimension — logical AND physical — tamper-proof tagged and logged. This is the no-flag-off-theater rule made architectural: a status label is worthless unless true and provable everywhere the data lived.

• Declarative store registry (ENFORCED, not advisory): every place user data lives — logical (scope/kind/user/store) + physical (file / SQLite DB / FAISS index / JSONL) — is registered. A store touching user data that does NOT register (with its delete/erase path) fails CI. No silent unmapped store.
• Action = a tamper-proof logged ledger event: each governance action emits a signed, immutable audit record (the ledger, §1–§6); + a completeness audit asserting the action touched each registered store (fail-loud on any miss).
• Kind/scope-aware semantics: registry tags each store memory-vs-ledger (G112) and shared-skill-vs-private (G113) so deletion/erasure semantics are correct per store.

This is the provable backbone for RTBF (G31), provenance lineage (G90), and kind-aware isolation (G113). Enforcement requirement is binding; detailed design deferred.

11. Approval gateway — principle + inclusions/exclusions (operator 2026-06-21, on G63)

ApprovalGate = a tiered human checkpoint (low→auto, med→1 approver, high→2) recording who authorized a privileged action. Runtime mechanism for the Constitution's posture: AUTONOMY by default; approval-gated only for production-mutation + governance/charter-mutation (signed GatePolicy).

REQUIRES approval (gated): irreversible/destructive (bulk RTBF / crypto-erasure / purge); privilege/authority-granting (operator-binding, high authority_level, promote-to-shared skill layer G113); cross-ownership (transfer/clone G108); governance mutation (retention/isolation policy, store-registry G62, consolidation charter G111, the GatePolicy itself); mass/blast-radius (many users/records at once).
NO approval (autonomy-default): ordinary write/recall/consolidation; per-item decay/forgetting (reversible — ledger retains); a single user's own routine interactions; internal optimization within bounds.
GDPR-delete: INCLUDED (irreversible) — but approval = authorization-recording + completeness-proof (G62), NOT an operator veto on the data-subject's lawful right.

Bound (the "route to do anything" danger): approval GATES actions; it NEVER grants new powers or waives invariants. Some actions are NON-APPROVABLE — no signature can authorize rewriting the immutable ledger, fiat-binding a poison memory, or bypassing non-fungibility. Every approval is itself a tamper-proof ledger event (attributable approver) — never a silent backdoor. The GatePolicy is operator-signed (machines propose, operator signs). Principle + inclusion/exclusion recorded; detailed design deferred.