Research Dossier

The Cognitive Memory Architecture Research Programme

Author: ZenTrader Core Team  ·  Date: July 31, 2026  ·  Status: Draft research protocol — proposed, not yet peer-reviewed or preregistered

Read the Whitepaper Start your evidence loop

Executive Summary

The whitepaper introduces ZenTrader's Cognitive Memory Architecture (CMA) as the platform's structured, AAS-inspired long-term memory for trading agents. This dossier is the research-grade companion to that narrative: it states plainly what is implemented today, what is a working foundation rather than a finished capability, and what remains a proposed design. It exists so that reviewers — technical, scientific, or funding — can evaluate the architecture on verified evidence rather than marketing language.

ZenTrader already implements an AAS-inspired relational hierarchy (assets → shells → submodels → typed elements), a genuinely insert-only policy-decision ledger, a versioned, golden-set-evaluated scoring pipeline (GeoScore), and — as of 2026-07-31 — a dedicated, database-enforced append-only memory-event ledger (cma_memory_events, stage 1 of the roadmap below). What is not yet implemented is retrieval scoring with explanations, cryptographic tamper evidence, a projection bridge from the ledger into the existing AAS tables, and a preregistered evaluation programme. This document specifies the research questions, hypotheses, methodology, and roadmap for closing the rest of that gap.

1. Purpose and Status of This Document

Every claim below is labelled so a reader never has to guess whether something exists in production:

LabelMeaning
ImplementedVerified directly against the current source code and the live database schema.
PartialA working foundation exists, but the complete behaviour described in the research programme is not yet present.
ProposedA design recommended for implementation and validation; not yet built.

This dossier was produced from an internal architecture review combined with a direct inspection of the relevant source files and the production database schema on 2026-07-31. Where the two disagreed, the verified code/database state is what is reported here.

2. The CMA Research Problem

Large language models have finite working context and no inherently persistent, trustworthy memory of earlier interactions, market states, or decisions. Retrieval-augmented generation addresses part of this limitation, but provenance, temporal validity, and updating remain open problems in the general literature. Financial agents raise the bar further: a retrieved statement may have been correct when generated but invalid after a regime change; an analysis may be an inference rather than an observation; a policy may have changed after a trade was placed; and a plausible narrative must never be confused with verified execution evidence.

Research problem. How can heterogeneous observations, probabilistic agent inferences, deterministic policies, execution states, and eventual outcomes be represented as temporally valid, semantically typed, retrievable, and independently verifiable memories — without allowing mutable projections or probabilistic agents to rewrite historical evidence?

3. Current Implementation, Verified Against Code and Database

core/aas_research.py builds AAS-inspired symbol shells and currently emits five submodels — Provenance, MacroRegimeContext, FactorEngineState, SignalDecision, and LiveExecution — normalised into four relational tables (aas_assets → aas_shells → aas_submodels → aas_submodel_elements).

SubmodelStatusPurpose
ProvenanceImplementedSource, task, profile, observed time
MacroRegimeContextImplementedMarket regime and readiness gate state
FactorEngineStateImplementedDeterministic factor values (price, volume, scores)
SignalDecisionImplementedProposed or rejected trading signal, with rationale
LiveExecutionImplementedSelected broker route and readiness

A direct schema inspection on 2026-07-31 confirms that aas_shells and aas_submodels write via INSERT ... ON CONFLICT DO UPDATE SET raw_json = EXCLUDED.raw_json. This is correct behaviour for a latest-state projection, but it means shell and submodel history is not currently immutable — a later run can overwrite an earlier raw_json value for the same shell or submodel identifier. A dedicated, insert-only event ledger is required before any claim of complete historical immutability at this layer.

Update, 2026-07-31. cma_memory_events now exists: a dedicated table with the four-clock temporal model above, enum-checked memory/authority/lifecycle columns, and — going one step further than gate_decisions — a BEFORE UPDATE OR DELETE trigger that blocks mutation unconditionally, independent of database role grants. This was verified live in production (a manual insert, then a blocked UPDATE and a blocked DELETE, both rolled back) in addition to 16 passing tests. A first producer is now wired: core/aas_research.py mirrors every written AAS submodel into the ledger as an observation-class event, additively and best-effort (a mirroring failure is logged, never breaks the primary AAS write). It is gated behind CMA_LEDGER_MIRROR, default-OFF — matching this codebase's established rollout convention for new observability hooks. A supervised observation run (2026-07-31, one market-watch cycle with the flag temporarily enabled) confirmed it works end-to-end in production: 1,280 rows written, 0 mirroring failures, correct grouping and content — then the flag was turned back off. The table is now also a TimescaleDB hypertable on event_time with a compression policy (chunks older than 30 days compress automatically, data stays fully queryable) — but deliberately no retention/drop policy, unlike the GeoScore hypertables precedent: this table is CMA evidence, and the design principles above ("forgetting must not destroy auditability") explicitly require it to remain permanent, not decay-and-drop like GeoScore's narrower signal system. There is still no projection bridge reading the ledger back into aas_shells/aas_submodels, and no other producer (gate_decisions, GeoScore) is wired yet — those remain open roadmap stages.

The gate_decisions table is a separate, and stronger, evidence structure. Its writer (trading/policy/decision_store.py) contains no update or delete path in code — every call either raises before writing (fail-closed validation) or inserts exactly one row. A live schema check on 2026-07-31, however, shows the distinction that matters for an honest claim: the append-only guarantee is enforced by application code discipline, not by the database. No trigger blocks mutation, and the application's own database role retains ordinary UPDATE/DELETE privileges on the table. This is accurately described as application-enforced append-only, not yet database-enforced or cryptographically tamper-evident append-only — no content hash, previous-hash chain, or signature column exists on any evidence table today.

GeoScore, the platform's qualitative-narrative scoring pipeline, is the most mature in-repository template for CMA's evaluation discipline: every prompt or model change is evaluated against a versioned, range-graded Golden Set before it ships, scoring itself is a deterministic, unit-tested function of the LLM's structured (never numeric) output, and re-scoring an event never overwrites a row — it inserts a new one chained via superseded_by. This append-and-chain pattern is exactly what the proposed CMA event ledger should generalise across all memory classes, not only narrative scores.

4. Research Questions and Hypotheses

QuestionHypothesis
RQ-A — Temporal retrieval. Does CMA retrieve information valid at the requested decision time more reliably than recency, lexical, or dense retrieval alone?Hybrid CMA retrieval improves temporal-validity accuracy and nDCG@k over recency-only, BM25-only, and dense-only baselines.
RQ-B — Evidence reconstruction. Can a past decision be reconstructed from its exact data, memory, model, prompt, strategy, and policy state?CMA achieves a higher complete-reconstruction rate and lower unsupported-claim rate than free-text journals or unversioned RAG.
RQ-C — Contradiction handling. Does explicit validity, supersession, and source authority reduce retrieval of stale or contradicted memories?Validity-aware retrieval reduces stale-memory inclusion and contradiction errors versus timestamp-only retrieval.
RQ-D — Controlled consolidation. Can derived reflections improve multi-hop reasoning without being mistaken for primary evidence?Provenance-bound reflections improve multi-hop retrieval while preserving evidence precision.
RQ-E — Memory economy. Can ranked, compressed memory reduce context size and latency without materially reducing decision quality?CMA uses fewer prompt tokens than full-context baselines while remaining non-inferior on task accuracy.
RQ-F — Tamper evidence. Can canonicalisation, hashing, and signatures detect unauthorised alteration or omission of stored evidence?Injected record mutations are detected, and omission attacks are detectable against independently retained checkpoints.

Provisional engineering targets — to be fixed after a labelled pilot and before any holdout is opened — include a five-percentage-point absolute improvement in temporal-validity accuracy, at least 95% complete decision reconstruction, zero undetected mutation in an adversarial test suite, and at least 30% fewer prompt tokens than full-context retrieval at non-inferior accuracy. These are validation thresholds to be tested, not current product claims.

5. Design Principles

The formal CMA is governed by six invariants:

  1. Evidence is immutable. Observations, decisions, executions, and outcomes are appended, never overwritten.
  2. Current state is a projection. The "latest known state" may be rebuilt, but it is always derived from immutable events.
  3. Time has more than one meaning. Observation time, event time, ingestion time, and validity interval are stored separately.
  4. Authority is explicit. Broker facts, deterministic calculations, human assertions, and LLM inferences are distinct memory classes with distinct trust levels.
  5. Agents propose; deterministic services commit. An agent may request a memory write, but schema, tenancy, policy, provenance, and authority checks decide whether it is accepted.
  6. Forgetting must not destroy auditability. Decay, summarisation, and archiving affect retrieval and cost, never the underlying evidence ledger.

6. Memory Taxonomy (excerpt)

ClassDefinitionMutability
ObservationData received directly from a defined sourceAppend-only
AssertionA claim derived from observationsSuperseded, never overwritten
DecisionDeterministic or human gate outcomeAppend-only
ExecutionBroker-facing action and reported stateAppend-only event stream
ReconciliationComparison between internal and broker statesAppend-only
OutcomeLater evidence evaluating an earlier assertion or decisionAppend-only
ProjectionMaterialised current view (e.g. today's aas_shells)Rebuildable and mutable

7. Relation to Prior Work

The reviewed literature supplies strong solutions for long-term retrieval, reflection, graph memory, financial memory, and provenance individually. ZenTrader's design is unusual in combining these with AAS-inspired semantic twins, deterministic policy evidence, and multi-broker reconciliation — but this is a research inference, not an established uniqueness claim; a systematic literature review is still required before publication.

FieldImplication for CMA
AAS & digital twins (IDTA metamodel)Use AAS identity/shell/submodel principles; maintain a documented ZenTrader compatibility profile rather than claiming conformance.
Retrieval-augmented generationRetain external, queryable evidence rather than treating model weights as system memory.
Generative Agents (Park et al.)Adopt scored retrieval and reflection, but bind reflections to evidence so they cannot silently become authoritative facts.
MemGPTExpose explicit retrieval interfaces; never let an LLM bypass deterministic write policy.
MemoryBankApply decay to retrieval visibility only, never to immutable financial evidence.
HippoRAGConsider graph/PageRank expansion only after the relational-temporal baseline is stable.
FinMemCompare CMA against a layered financial-memory baseline; differentiate on evidence governance and temporal provenance, not layering alone.
LoCoMoReuse its task taxonomy as a general memory sanity check; build a finance-specific temporal benchmark separately.
W3C PROVMap datasets, prompts, models, policies, agents, and decisions to an explicit provenance vocabulary.

8. Validation Programme

Five properties are tested independently rather than collapsed into trading profitability, which is affected by strategy quality, regime, and cost and cannot alone establish that the memory architecture is better:

Baselines span no-memory and full-context extremes, recency/BM25/dense-RAG, Generative-Agents-style scoring, a FinMem-style layered baseline, and three CMA configurations (relational, hybrid, graph+reflection). The final confirmatory evaluation is intended to be preregistered — in the OSF sense of a timestamped, read-only plan frozen before the holdout is accessed — before any headline result is published.

Concrete validation milestones

MilestoneExit criterion
Memory-event schemaJSON Schema validation and database constraints agree on valid/invalid fixtures
Temporal queriesAll synthetic bitemporal test cases pass, including delayed corrections
Evidence reconstructionAt least 95% of labelled decisions reconstruct with all mandatory evidence
Golden SetVersioned query set, evaluator, and non-regression CI are operational
Hashing & signaturesMutation, reorder, and wrong-predecessor tests fail verification as designed
Preregistered evaluationLocked holdout analysed once under the registered plan

9. Limitations

  1. Standards scope. ZenTrader borrows AAS concepts but uses a domain-specific JSON shape and relational normalisation. Full AAS conformance cannot be claimed until serialisation and interfaces are tested against the official IDTA specifications.
  2. Current event immutability. Gate decisions are genuinely append-only in application code; AAS shell and submodel writes are upserts. A dedicated, database-enforced event ledger (cma_memory_events) now exists (2026-07-31), with a first producer wired (AAS submodel mirroring) but gated behind a default-OFF flag and no projection bridge into the AAS tables — so AAS shell/submodel history is still not immutable today, only the new ledger's own rows would be once the flag is enabled.
  3. Source truth. A future hash chain would prove content has not changed relative to a checkpoint — it would not prove that a broker, news source, model, or human assertion was correct.
  4. Non-stationarity. Financial regimes, broker behaviour, and models change over time; results from a fixed historical window may not generalise, so temporal cross-validation is mandatory.
  5. Private reproducibility. Proprietary data and code limit full external replication; a synthetic benchmark, public schemas, and frozen evaluation artefacts are planned to mitigate this without publishing trading IP.

10. Roadmap

The roadmap prioritises schema stability and temporal/evidence correctness before embeddings, graph databases, or autonomous reflection:

  1. Terminology and ADR freeze (memory taxonomy, authority classes, temporal semantics)
  2. JSON Schema package with valid/invalid fixtures
  3. Done, 2026-07-31 Immutable event ledger (cma_memory_events; insert-only, DB-trigger-enforced — no producer wired yet)
  4. Projection bridge from events into existing AAS tables
  5. Read-only, temporally filtered retrieval API
  6. Prompt/model registry, generalising GeoScore's version discipline
  7. Golden Set with expected evidence IDs and CI non-regression
  8. Hybrid (lexical + dense) retrieval behind a replaceable interface
  9. Hash chain and signatures (JCS canonicalisation, SHA-256, Ed25519)
  10. External checkpoints (Merkle batches, independently retained roots)
  11. Preregistered holdout evaluation and public research package

The first implementable release is scoped as CMA v1: immutable events, temporal retrieval, and evidence reconstruction. Graph memory, autonomous reflections, and external transparency logs are later increments — sequenced this way so sophisticated retrieval never hides weak temporal or provenance semantics underneath it.

References

This dossier accompanies, and does not replace, the ZenTrader Whitepaper. It is an internal research protocol shared for technical and funding review; research questions, milestones, and dates are planning artefacts, not commitments to a fixed delivery date. Implementation status was verified against source code and the production database schema on 2026-07-31 and will drift as the codebase evolves — treat any specific claim as time-stamped, not evergreen.