The Cognitive Memory Architecture Research Programme

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?

Phase 1 — event ledger and first producer. 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 (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 (both were wired in later updates below).

Phase 2 — AAS hypertable compression. The growth problem flagged above is now partially solved: aas_shells is a TimescaleDB hypertable on created_at, with the same compression-only, no-retention policy as cma_memory_events — deliberately, because this data backs the whitepaper's trade-explainability claim rather than being disposable signal data. Its child tables (aas_submodels, aas_data_statements) gained a denormalised shell_created_at column and composite foreign keys pointing at the new hypertable, auto-populated by a BEFORE INSERT trigger so no existing writer code needed to change; one line in core/aas_research.py's ON CONFLICT target was updated to match the now-composite unique constraint. Verified live: the hypertable, compression policy, and both triggers are active in production, with the trigger proven correct by production writes that landed during the migration window itself (zero rows with a NULL shell_created_at). Stage 2: aas_submodels — the largest of the four AAS tables (4.58M rows, 13GB) — is now a hypertable too, with the identical compression-only treatment and the same denormalised-timestamp pattern extended to its own children (aas_submodel_elements, aas_data_statements). This stage surfaced a genuine Timescale limitation the first migration didn't: a hypertable cannot itself hold an outbound foreign key to another hypertable, which broke on the first attempt (rolled back cleanly, no damage) because aas_submodels already FKs into the now-hypertable aas_shells. Fixed by dropping that foreign key — aas_submodels.shell_id is now a soft, application-enforced reference rather than a database-checked one, the same trust model already accepted for cma_memory_events.supersedes_event_id. Stage 3: aas_submodel_elements — the largest AAS table by row count (16.56M rows, ~8GB) — is now a hypertable too. Applying the previous stage's lesson up front, its two outbound foreign keys (to the now-hypertable aas_submodels, and a self-reference via parent_element_id) were dropped before calling create_hypertable(), which then succeeded on the first attempt. Two things measured directly rather than assumed: aas_qualifiers, the only other table besides aas_data_statements that references elements, turned out to have zero rows and no writer anywhere in the codebase — dead schema; and parent_element_id itself is NULL on all 16.56M rows — the element-hierarchy feature this dropped foreign key protected has never actually been used in production. Stage 4 — plan complete. aas_data_statements (10.97M rows, 13GB) is now a hypertable too, closing out all four AAS tables. It turned out structurally simpler than the earlier stages expected: nothing foreign-keys into it, so no denormalised columns or triggers were needed at all — only dropping its three outbound composite foreign keys to the other, now-hypertable AAS tables (all becoming soft references, same as before) and partitioning on observed_at, its only timestamp column. No application code changed for this stage. All four AAS tables — aas_shells, aas_submodels, aas_submodel_elements, aas_data_statements — are now compressed TimescaleDB hypertables with no retention policy; only aas_assets stays a regular table, correctly, since it is genuinely upserted (~650 rows). The unbounded-growth limitation this whole update thread tracked is resolved.

Phase 3 — projection bridge (roadmap item 4). A read-only module (trading/cma/projection.py) now reconstructs the latest AAS submodel state purely from cma_memory_events and compares it against the live aas_submodels rows — the first direct test of the design principle above ("current state is a projection... always derived from immutable events") and of RQ-B (evidence reconstruction) against real data rather than an assumption. Run against every shell the ledger has seen (the Phase 1 mirroring proof run): 256 of 256 shells and 1,280 of 1,280 submodels reconstruct exactly — a measured 100% match rate. This is a narrow result, stated precisely rather than oversold: one producer (AAS submodel mirroring), one supervised run, observation-class events only, and content that is a direct verbatim copy by construction (the mirroring code passes the submodel dict unchanged into content_json), so exact equality is the expected outcome being verified, not yet a claim about reconstruction from more distantly related or partially-derived evidence. It is, however, a genuine live measurement with a real failure mode (a mismatch, or a row present on one side only) that did not occur — not a synthetic benchmark. 9 new rollback-isolated tests cover both directions of drift (ledger has it, AAS doesn't; and vice versa) plus the match/mismatch cases directly. Building this also surfaced and fixed a real bug unrelated to CMA specifically: a session-lifecycle helper that unconditionally closed any injected database session on exit, which breaks for any caller supplying a longer-lived session (not just tests) — fixed by mirroring the safer pattern already used by trading/db/order_store.py.

Phase 4 — gate_decisions database-enforced. That gap is closed: gate_decisions now carries the identical BEFORE UPDATE OR DELETE trigger already proven on cma_memory_events, unconditionally rejecting mutation independent of role grants. The database roles' own UPDATE/DELETE grants are deliberately left in place — revoking them is a separate, larger change touching every role with legitimate other privileges on this table — but the trigger alone already closes the actual gap: a manual UPDATE and DELETE via raw SQL were both tested live and blocked. gate_decisions and cma_memory_events are now both database-enforced append-only. Neither is yet cryptographically tamper-evident — no content hash, previous-hash chain, or signature column exists on any evidence table today.

Phase 5 — gate_decisions as second producer. gate_decisions is now wired as the ledger's second producer: every written decision is additionally mirrored into cma_memory_events as a memory_type='decision', authority='deterministic_derived' event (trading/policy/decision_store.py), best-effort and never blocking the primary write, gated behind its own default-OFF flag (CMA_LEDGER_MIRROR_GATE_DECISIONS) kept deliberately separate from the AAS producer's flag since this writer sits on the live order-execution path. Unlike the AAS producer, this one has not yet been proven live: two supervised overnight observation windows found no organic gate_decisions row to mirror — the platform runs globally in dry_run mode and neither attempt's paper-mode cycles produced an order intent to route. Both attempts happened on a Friday night/weekend, when the equity-hours-gated strategies don't fire at all; a third attempt is planned for a weekday with both crypto and equity timers active.

Phase 6 — GeoScore as third producer. GeoScore's scoring pipeline (trading/geoscore/scoring.py:score_pending) is now wired as the ledger's third producer: every assembled geoscore_event_scores row is additionally mirrored into cma_memory_events, one event per asset × horizon, as a memory_type='assertion', authority='model_inferred' event — the first producer to actually exercise model_inferred's cross-field validation rule (both model_version and prompt_version required), carrying GeoScore's own resolved model id and its geoscore-prompt-v2 contract version. Best-effort, never blocking the primary score write, gated behind its own default-OFF flag (CMA_LEDGER_MIRROR_GEOSCORE). Covered by mocked unit tests and a rollback-isolated real-database test asserting the mirrored rows' content and count against a seeded event — not yet observed live in production, the same open step as the second producer above.

Incident — a "rollback-isolated" real-DB test wasn't. While building the retrieval API below, an unrelated check surfaced that GeoscoreLedgerMirrorRealDbTest (the real-database test for the producer above) had been silently committing real rows to production cma_memory_events on every run since it was written — 27 rows, IDs 1480-1800, all with the unmistakable fake ticker stream_id='geoscore:ZZZTESTBTC:*'. Root cause: _mirror_geoscore_score_to_ledger() calls record_memory_event() without a session argument by design (the mirror deliberately runs in its own transaction, separate from the primary write's — the same convention every producer in this section uses); that fallback path resolves its session through trading.db.order_store._SESSION_FACTORY, and the test never redirected that hook to its own rollback-isolated session, unlike the equivalent gate_decisions test, which does. The primary GeoScore tables were correctly isolated throughout (verified: zero leaked rows in geoscore_events/geoscore_event_scores) — only the separate-transaction ledger mirror escaped. Fixed by adding the same session-factory redirect the gate_decisions test already used; verified clean on rerun (row count unchanged across two subsequent runs). The 27 leaked rows themselves were left in place rather than forced out through the append-only trigger that would otherwise need disabling to remove them — a deliberate call consistent with this ledger's own principle that mistakes get documented, not erased, and they are harmless: inert, unambiguously fake, and excluded from the reconstruction-rate and audit measurements elsewhere in this dossier by their fake ticker alone.

Phase 7 — hash chain (roadmap item 9, part 1 of 2). cma_memory_events' two reserved integrity columns (content_hash, previous_event_hash) are now populated when trading/cma/chain.py's hash chain is enabled: every row's content_hash is a SHA-256 of its canonicalized content_json, and previous_event_hash links it to the prior row's hash, forming a linked list any of the three producers can append to transparently — none of them had to change. A Postgres advisory transaction lock serializes the read-last-hash-then-insert step so concurrent producers can never race for the same link. A companion verify_chain() walks the ledger and checks both a content re-hash and the link continuity; its detection logic is unit-tested directly against fabricated tampered/deleted/spliced-in rows (constructing a genuinely tampered row in the live table is not possible — the append-only trigger above already blocks it, which is itself a meaningful result: this hash chain is defense-in-depth for a scenario where that trigger is bypassed, e.g. a restore from an externally tampered dump, not the primary defense). Practical canonical JSON (sorted keys, UTF-8, no whitespace), explicitly not a certified RFC 8785 (JCS) implementation — number formatting and non-BMP key ordering are not JCS-exact, a real gap against the roadmap item's original wording. Gated behind CMA_LEDGER_HASH_CHAIN, default OFF, not yet enabled in production.

Phase 8 — Ed25519 signatures (roadmap item 9, part 2 of 2). A migration added two more nullable columns (signature, signing_key_id) and trading/cma/signing.py now signs each row's hash-chain link (content_hash, previous_event_hash, plus stream_id/event_type/event_time so a signature cannot be replayed onto an unrelated row) with an Ed25519 private key, when enabled. signing_key_id is a short, non-secret fingerprint of the public key — deliberately not one hardcoded key baked into the verifier, so a future key rotation doesn't retroactively invalidate old rows' verifiability. A companion verify_signatures() checks every signed row against a caller-supplied key map and reports an unknown-key row separately from an actually-invalid signature, since those mean different things (verifier coverage gap vs. real tamper). The private key itself (CMA_LEDGER_SIGNING_KEY) is read from the environment only, never written to the database or this repository — and today it is unset: no signing key has been generated for production, CMA_LEDGER_SIGN_CHAIN is unset/OFF, and signing depends on the hash chain above also being enabled. Roadmap item 9 (hash chain and signatures) is now built end to end; item 10 (external Merkle checkpoints) remains open.

Phase 9 — retrieval API, part 1 (roadmap item 5). trading/cma/retrieval.py turns RQ-A into a queryable function rather than only a hypothesis: retrieve(as_of=T, ...) answers "what did the ledger know, and consider still valid, at time T" by requiring both ingested_at <= T (never let a point-in-time query see information the system only learned about later) and valid_from <= T < valid_to (half-open, NULL valid_to meaning still valid) — the two-clock distinction the CMA design principles describe, now enforced in a WHERE clause instead of only in prose. A companion retrieve_latest_per_stream() uses Postgres DISTINCT ON (not a naive top-N-then-group, which a rollback-isolated test proved would silently drop a real result: a stream with few events can get crowded out of a simple truncated result set by a stream with many). Both functions also accept ordinary scope filters (tenant, profile, strategy, asset, memory/event type, authority, correlation id) and default to excluding non-active lifecycle rows. Explicitly scoped narrow at the time this phase shipped: no ranking, no lexical or dense search, no Golden Set evaluation — this was the plumbing those later phases build on, not a finished retrieval system (roadmap items 7 and 8, both now shipped separately below). Its docstring carries an explicit warning against exposing it to a tenant-facing endpoint without passing tenant_id, given this codebase's own prior evidence-API cross-tenant leak history. 7 new rollback-isolated tests.

Phase 10 — prompt/model registry (roadmap item 6). trading/cma/model_registry.py is a small, code-level registry of known (component, prompt_version) pairs, each entry citing the real git commit and date that introduced it — not a database table, deliberately: GeoScore's own version discipline already lives in git history (a versioned PROMPT_VERSION constant, evaluated against a Golden Set before each change ships), and a separate mutable registry table could itself drift from the code it describes, the opposite of what a registry is for. Building it against real history surfaced a genuine, previously undocumented gap: an earlier calibration round that added 5 VIP/influencer golden-set events (commits 880e3e1a/99b35ad8, 7/10 → 14/15) never bumped PROMPT_VERSION — still geoscore-prompt-v2 as of this writing. Recorded honestly in the registry entry rather than retroactively inventing a "v2.1" this codebase never used. A read-only audit_ledger_versions() scans the live ledger for any model_inferred row using a (component, prompt_version) pair this registry doesn't recognise; run against production it found zero unregistered versions (the ledger's only model_inferred rows are the 27 leaked test rows noted above, which happen to carry a genuinely registered version). Not wired into record_memory_event as an enforcement gate — that would be a separate, later decision on an already HIGH-risk shared writer, not bundled into introducing the registry itself. 12 new tests, including one that pins the real current registry state so a future geoscore-prompt-v3 ship without a matching entry fails loudly.

Phase 11 — Golden Set + CI non-regression (roadmap item 7). trading/cma/golden/cma_retrieval_golden_set.json freezes 5 retrieve()/retrieve_latest_per_stream() queries against real, immutable rows from the Phase 1 AAS mirroring proof run (the TXN research shell's 5 submodels, ids 1276-1280), each with an exact expected event-ID set — not ranges, unlike GeoScore's LLM-graded golden set, because retrieval over an append-only ledger given fixed evidence has exactly one correct answer. tests/test_cma_golden_set_unittest.py replays every case against the live database as an ordinary part of the pytest suite: true CI non-regression, no separate eval script needed. Building the "latest state per stream" case caught a real bug before it was ever pinned: all 5 of the TXN shell's rows share one event_time (they were mirrored in a single market-watch cycle), and retrieve_latest_per_stream()'s tie-break — nonexistent until this phase — silently returned Postgres's scan order, observed picking the first-inserted row of the tied group, the wrong direction for "current state". Fixed by adding id DESC as an explicit tiebreaker (the row that actually entered the ledger last now wins); the golden set's tiebreak case pins the corrected behaviour against the same real data that exposed the bug, so a regression would be caught immediately, not rediscovered.

Phase 12 — hybrid retrieval (roadmap item 8). This codebase had zero vector-search infrastructure before this phase: no pgvector, no embedding-generation code anywhere, no embeddings surface on the AION MCP integration (checked directly rather than assumed). What it did have, already running, was nomic-embed-text (768-dim, a dedicated embedding model, confirmed present) on the same GPU Ollama instance GeoScore's LLM calls already depend on (100.98.188.22:11434) — so building this needed a new Postgres extension and a new Python client, not a new model or a new server. Installed pgvector 0.8.1 (confirmed installable by the existing zentrader_researcher role without superuser — it's a "trusted" extension) and added a nullable vector(768) column plus an HNSW cosine-distance index to cma_memory_events. Because the table is append-only, embeddings cannot be backfilled onto an existing row via UPDATE the way a normal "reserved column" would be — trading/cma/embeddings.py's apply_embedding() runs at insert time only, alongside the hash-chain and signing steps, computing a vector from search_text when present. Unlike those two, a failed embedding call is caught and logged, never raised: it is a network call to a remote GPU that can fail transiently even when correctly configured, and the ledger's evidence-recording contract must not depend on that GPU being reachable. lexical_search() (Postgres ts_rank over the GIN index this table has carried since Phase 1), dense_search() (pgvector cosine distance), and hybrid_search() (min-max-normalized weighted fusion of the two) are three independently swappable pieces — the "replaceable interface" the roadmap item asks for. Verified against the real GPU once, end to end, outside the permanent test suite (mocked in all committed tests, matching how GeoScore's own tests never call the real Ollama instance either): a query for "central bank monetary policy rate decision" correctly ranked a row about "Federal Reserve signals interest rate cuts" top via the dense signal alone (lexical score 0 -- no shared words), demonstrating genuine semantic match, not just keyword overlap. Both new flags (CMA_LEDGER_EMBED, gating insert-time computation) default OFF; no embedding has been written to a real production row. 22 new tests across three files; full cma/geoscore/gate_decision/aas suite green (263 passed), plus a full 1,826-test whole-suite run confirming no regressions elsewhere (2 pre-existing, unrelated failures in an unrelated API area, untouched by this work).

Phase 13 — the model registry catches its own kind of drift a second time. Phase 10 recorded, honestly, that GeoScore's prompt constant was still geoscore-prompt-v2 despite an undocumented calibration change. That has since shipped as geoscore-prompt-v3: a new golden-set-evaluated change (adding a TRACKED_ASSETS asset-naming preference list, golden set 13/15 with n=3 self-consistency runs) correctly bumped the version this time — geoscore-prompt-v2 is now marked deprecated in trading/cma/model_registry.py, geoscore-prompt-v3 is the new active entry, citing its real introducing commits. The two golden-set misses that remain under v3 (a memecoin-post score range, exchange-hack factor signs) are pre-existing calibration gaps unrelated to this change, not a new regression. This is a genuine, small proof point for the registry's own stated purpose: a real version change happened, and it landed in the registry rather than drifting silently a second time.

Forschungsproblem. Wie können heterogene Beobachtungen, probabilistische Agenten-Inferenzen, deterministische Policies, Ausführungszustände und spätere Outcomes als zeitlich gültige, semantisch typisierte, abrufbare und unabhängig verifizierbare Memories repräsentiert werden — ohne dass veränderliche Projektionen oder probabilistische Agenten historische Evidenz überschreiben können?

Phase 1 — Event-Ledger und erster Producer. cma_memory_events existiert jetzt: eine dedizierte Tabelle mit dem oben beschriebenen Vier-Uhren-Zeitmodell, enum-geprüften Memory-/Autoritäts-/Lifecycle-Spalten und — einen Schritt weiter als gate_decisions — einem BEFORE UPDATE OR DELETE-Trigger, der Mutationen unbedingt blockiert, unabhängig von Datenbank-Rollenrechten. Das wurde live in Produktion verifiziert (ein manueller Insert, dann ein blockiertes UPDATE und ein blockiertes DELETE, beide zurückgerollt) zusätzlich zu 16 bestandenen Tests. Ein erster Producer ist jetzt angebunden: core/aas_research.py spiegelt jedes geschriebene AAS-Submodell zusätzlich als Event der Klasse observation in den Ledger, additiv und best-effort (ein Spiegelungsfehler wird geloggt, bricht nie den primären AAS-Write). Es ist hinter CMA_LEDGER_MIRROR gegated, default-OFF — passend zur etablierten Rollout-Konvention dieses Codebase für neue Observability-Hooks. Ein überwachter Beobachtungslauf (ein Market-Watch-Zyklus mit temporär aktiviertem Flag) bestätigte, dass es Ende-zu-Ende in Produktion funktioniert: 1.280 geschriebene Zeilen, 0 Spiegelungsfehler, korrekte Gruppierung und Inhalte — danach wurde das Flag wieder deaktiviert. Die Tabelle ist jetzt außerdem eine TimescaleDB-Hypertable auf event_time mit Compression-Policy (Chunks älter als 30 Tage werden automatisch komprimiert, Daten bleiben voll abfragbar) — aber bewusst ohne Retention-/Lösch-Policy, anders als beim GeoScore-Hypertable-Vorbild: Diese Tabelle ist CMA-Evidenz, und die Design-Prinzipien oben ("Vergessen darf die Auditierbarkeit nicht zerstören") verlangen ausdrücklich, dass sie dauerhaft erhalten bleibt, statt wie GeoScores enger gefasstes Signal-System zu verfallen und gelöscht zu werden. Es gibt weiterhin keine Projektions-Brücke, die den Ledger zurück in aas_shells/aas_submodels liest, und keinen weiteren angebundenen Producer (gate_decisions, GeoScore) — das bleiben offene Roadmap-Stufen (beide wurden in späteren Updates unten angebunden).

Phase 2 — AAS-Hypertable-Kompression. Das oben markierte Wachstumsproblem ist jetzt teilweise gelöst: aas_shells ist eine TimescaleDB-Hypertable auf created_at, mit derselben Nur-Kompression-Policy ohne Retention wie cma_memory_events — bewusst, weil diese Daten die Trade-Explainability-Behauptung des Whitepapers stützen und keine verwerfbaren Signal-Daten sind. Die Kind-Tabellen (aas_submodels, aas_data_statements) erhielten eine denormalisierte shell_created_at-Spalte und zusammengesetzte Fremdschlüssel auf die neue Hypertable, automatisch befüllt durch einen BEFORE INSERT-Trigger, sodass kein bestehender Writer-Code geändert werden musste; eine Zeile in core/aas_research.pys ON CONFLICT-Ziel wurde angepasst, um dem jetzt zusammengesetzten Unique-Constraint zu entsprechen. Live verifiziert: Hypertable, Compression-Policy und beide Trigger sind in Produktion aktiv, wobei der Trigger durch produktive Writes, die während des Migrationsfensters selbst eintrafen, als korrekt belegt wurde (null Zeilen mit NULL-shell_created_at). Stufe 2: aas_submodels — die größte der vier AAS-Tabellen (4,58 Mio. Zeilen, 13 GB) — ist jetzt ebenfalls eine Hypertable, mit derselben Nur-Kompressions-Behandlung und demselben denormalisierten-Zeitstempel-Muster, erweitert auf ihre eigenen Kind-Tabellen (aas_submodel_elements, aas_data_statements). Diese Stufe deckte eine echte Timescale-Einschränkung auf, die die erste Migration nicht betraf: Eine Hypertable darf selbst keinen ausgehenden Fremdschlüssel auf eine andere Hypertable halten, was beim ersten Versuch scheiterte (sauber zurückgerollt, kein Schaden), weil aas_submodels bereits auf die jetzt-Hypertable aas_shells verweist. Behoben durch Löschen dieses Fremdschlüssels — aas_submodels.shell_id ist jetzt eine weiche, anwendungsseitig erzwungene Referenz statt einer datenbankgeprüften, dasselbe Vertrauensmodell, das bereits für cma_memory_events.supersedes_event_id akzeptiert wurde. Stufe 3: aas_submodel_elements — die größte AAS-Tabelle nach Zeilenzahl (16,56 Mio. Zeilen, ~8 GB) — ist jetzt ebenfalls eine Hypertable. Unter Anwendung der Lehre aus der vorherigen Stufe wurden ihre beiden ausgehenden Fremdschlüssel (auf die jetzt-Hypertable aas_submodels sowie eine Selbstreferenz über parent_element_id) vor dem Aufruf von create_hypertable() gelöscht, wodurch dieser beim ersten Versuch gelang. Zwei Dinge wurden direkt gemessen statt angenommen: aas_qualifiers, die einzige weitere Tabelle neben aas_data_statements, die auf Elemente verweist, hat sich als leer und ohne Writer im gesamten Code erwiesen — totes Schema; und parent_element_id selbst ist bei allen 16,56 Mio. Zeilen NULL — das Element-Hierarchie-Feature, das dieser gelöschte Fremdschlüssel schützte, wurde in Produktion nie tatsächlich genutzt. Stufe 4 — Plan abgeschlossen. aas_data_statements (10,97 Mio. Zeilen, 13 GB) ist jetzt ebenfalls eine Hypertable, womit alle vier AAS-Tabellen abgeschlossen sind. Diese Stufe erwies sich als strukturell einfacher als die vorherigen Stufen erwarten ließen: Nichts referenziert diese Tabelle per Fremdschlüssel, daher waren überhaupt keine denormalisierten Spalten oder Trigger nötig — nur das Löschen ihrer drei ausgehenden zusammengesetzten Fremdschlüssel auf die anderen, jetzt-Hypertable-AAS-Tabellen (alle werden zu weichen Referenzen, wie zuvor) und die Partitionierung auf observed_at, ihre einzige Zeitstempel-Spalte. Für diese Stufe war keine Code-Änderung nötig. Alle vier AAS-Tabellen — aas_shells, aas_submodels, aas_submodel_elements, aas_data_statements — sind jetzt komprimierte TimescaleDB-Hypertables ohne Retention-Policy; nur aas_assets bleibt zu Recht eine reguläre Tabelle, da sie tatsächlich upserted wird (~650 Zeilen). Die Wachstumslimitation, die dieser gesamte Update-Strang verfolgt hat, ist damit gelöst.

Phase 3 — Projektions-Brücke (Roadmap-Punkt 4). Ein schreibgeschütztes Modul (trading/cma/projection.py) rekonstruiert jetzt den letzten AAS-Submodell-Zustand rein aus cma_memory_events und vergleicht ihn mit den lebenden aas_submodels-Zeilen — der erste direkte Test des oben genannten Design-Prinzips ("der aktuelle Zustand ist eine Projektion... immer aus unveränderlichen Events abgeleitet") und von RQ-B (Evidenz-Rekonstruktion) gegen echte Daten statt einer Annahme. Ausgeführt gegen jede Shell, die der Ledger je gesehen hat (der Spiegelungs-Nachweislauf aus Phase 1): 256 von 256 Shells und 1.280 von 1.280 Submodellen rekonstruieren exakt — eine gemessene 100%-Trefferquote. Das ist ein eng gefasstes Ergebnis, präzise formuliert statt überverkauft: ein Producer (AAS-Submodell-Spiegelung), ein überwachter Lauf, nur Events der Klasse observation, und Inhalte, die konstruktionsbedingt eine wörtliche Kopie sind (der Spiegelungscode übergibt das Submodell-Dict unverändert in content_json) — exakte Gleichheit ist also das erwartete, hier verifizierte Ergebnis, noch keine Aussage über Rekonstruktion aus entfernter verwandter oder teilweise abgeleiteter Evidenz. Es ist dennoch eine echte Live-Messung mit einem realen Fehlermodus (eine Abweichung, oder eine nur einseitig vorhandene Zeile), der nicht eingetreten ist — kein synthetischer Benchmark. 9 neue rollback-isolierte Tests decken beide Drift-Richtungen ab (nur im Ledger; nur in AAS) sowie die Match-/Mismatch-Fälle direkt. Beim Bau wurde zudem ein echter, CMA-unabhängiger Bug gefunden und behoben: Ein Session-Lifecycle-Helfer schloss jede übergebene Datenbank-Session bedingungslos beim Verlassen — das bricht für jeden Aufrufer, der eine länger lebende Session übergibt (nicht nur Tests) — behoben durch Angleichung an das bereits sicherere Muster in trading/db/order_store.py.

Phase 4 — gate_decisions datenbankseitig erzwungen. Diese Lücke ist geschlossen: gate_decisions trägt jetzt denselben BEFORE UPDATE OR DELETE-Trigger, der bereits bei cma_memory_events bewiesen wurde, und weist Mutationen unbedingt zurück, unabhängig von Rollenrechten. Die eigenen UPDATE/DELETE-Rechte der Datenbankrollen bleiben bewusst bestehen — sie zu entziehen wäre eine separate, größere Änderung, die jede Rolle mit legitimen anderen Rechten auf dieser Tabelle betrifft — aber der Trigger allein schließt die eigentliche Lücke bereits: Ein manuelles UPDATE und DELETE per Raw-SQL wurden beide live getestet und blockiert. gate_decisions und cma_memory_events sind jetzt beide datenbankseitig erzwungenes Append-only. Keines von beiden ist bereits kryptografisch manipulationssicher — es existiert heute keine Content-Hash-, Previous-Hash-Ketten- oder Signatur-Spalte auf irgendeiner Evidenz-Tabelle.

Phase 5 — gate_decisions als zweiter Producer. gate_decisions ist jetzt als zweiter Producer des Ledgers angebunden: Jede geschriebene Entscheidung wird zusätzlich als memory_type='decision'-, authority='deterministic_derived'-Event in cma_memory_events gespiegelt (trading/policy/decision_store.py), best-effort und ohne den Primärschreibvorgang je zu blockieren, hinter einem eigenen, standardmäßig deaktivierten Flag (CMA_LEDGER_MIRROR_GATE_DECISIONS), bewusst getrennt vom AAS-Producer-Flag, da dieser Writer auf dem Live-Order-Ausführungspfad liegt. Anders als beim AAS-Producer ist dies noch nicht live nachgewiesen: Zwei überwachte nächtliche Beobachtungsfenster fanden keine organische gate_decisions-Zeile zum Spiegeln — die Plattform läuft global im dry_run-Modus, und in keinem der beiden Fenster erzeugten die Paper-Mode-Zyklen eine zu routende Order-Intention. Beide Versuche fanden Freitagnacht/am Wochenende statt, wenn die Handelszeiten-gegateten Equity-Strategien gar nicht feuern; ein dritter Versuch ist für einen Werktag mit aktiven Krypto- und Equity-Timern geplant.

Phase 6 — GeoScore als dritter Producer. Die Scoring-Pipeline von GeoScore (trading/geoscore/scoring.py:score_pending) ist jetzt als dritter Producer des Ledgers angebunden: Jede zusammengesetzte geoscore_event_scores-Zeile wird zusätzlich gespiegelt, eine Zeile pro Asset × Horizont, als memory_type='assertion'-, authority='model_inferred'-Event — der erste Producer, der tatsächlich die Cross-Field-Validierungsregel von model_inferred auslöst (sowohl model_version als auch prompt_version erforderlich), mit GeoScores eigener aufgelöster Modell-ID und ihrer geoscore-prompt-v2-Vertragsversion. Best-effort, blockiert nie den primären Score-Write, hinter einem eigenen, standardmäßig deaktivierten Flag (CMA_LEDGER_MIRROR_GEOSCORE). Abgedeckt durch gemockte Unit-Tests und einen rollback-isolierten Real-DB-Test, der Inhalt und Anzahl der gespiegelten Zeilen gegen ein geseedetes Event prüft — noch nicht live in Produktion beobachtet, derselbe offene Schritt wie beim zweiten Producer oben.

Vorfall — ein "rollback-isolierter" Real-DB-Test war es nicht. Beim Bau der Retrieval-API unten kam bei einer unabhängigen Prüfung heraus, dass GeoscoreLedgerMirrorRealDbTest (der Real-DB-Test für den Producer oben) seit seiner Erstellung bei jedem Lauf still echte Zeilen in die produktive cma_memory_events committed hatte — 27 Zeilen, IDs 1480–1800, alle mit dem unverwechselbaren Fake-Ticker stream_id='geoscore:ZZZTESTBTC:*'. Ursache: _mirror_geoscore_score_to_ledger() ruft record_memory_event() bewusst ohne session-Argument auf (die Spiegelung läuft absichtlich in einer eigenen Transaktion, getrennt vom Primär-Write — dieselbe Konvention wie bei jedem Producer in diesem Abschnitt); dieser Fallback-Pfad löst seine Session über trading.db.order_store._SESSION_FACTORY auf, und der Test hat diesen Hook nie auf seine eigene rollback-isolierte Session umgeleitet — anders als der entsprechende gate_decisions-Test, der das tut. Die primären GeoScore-Tabellen waren durchgehend korrekt isoliert (verifiziert: null Leichen in geoscore_events/geoscore_event_scores) — nur die separat-transaktionale Ledger-Spiegelung entkam. Behoben durch denselben Session-Factory-Redirect, den der gate_decisions-Test bereits nutzte; nach dem Fix über zwei weitere Läufe hinweg als sauber verifiziert (Zeilenzahl unverändert). Die 27 bereits geleakten Zeilen wurden bewusst nicht über eine Deaktivierung des Append-only-Triggers entfernt — konsistent mit dem eigenen Grundsatz dieses Ledgers, dass Fehler dokumentiert statt getilgt werden, und sie sind harmlos: inert, eindeutig als Fake erkennbar und allein durch ihren Fake-Ticker aus den Rekonstruktions- und Audit-Messungen dieses Dossiers ausgeschlossen.

Phase 7 — Hash-Kette (Roadmap-Punkt 9, Teil 1 von 2). Die beiden reservierten Integritäts-Spalten von cma_memory_events (content_hash, previous_event_hash) werden jetzt befüllt, wenn die Hash-Kette in trading/cma/chain.py aktiviert ist: Der content_hash jeder Zeile ist ein SHA-256 ihres kanonisierten content_json, und previous_event_hash verkettet sie mit dem Hash der vorherigen Zeile — eine verkettete Liste, an die alle drei Producer transparent anschließen können, ohne selbst geändert zu werden. Eine Postgres-Advisory-Transaktionssperre serialisiert den Schritt „letzten Hash lesen, dann einfügen", sodass konkurrierende Producer nie um denselben Kettenglied konkurrieren können. Ein begleitendes verify_chain() durchläuft den Ledger und prüft sowohl einen Content-Re-Hash als auch die Ketten-Kontinuität; die Erkennungslogik ist direkt gegen konstruierte manipulierte/gelöschte/eingeschleuste Zeilen unit-getestet (eine echte manipulierte Zeile in der Live-Tabelle zu erzeugen ist nicht möglich — der Append-only-Trigger oben blockiert das bereits, was selbst ein aussagekräftiges Ergebnis ist: Diese Hash-Kette ist Verteidigung in der Tiefe für ein Szenario, in dem dieser Trigger umgangen wird, z. B. eine Wiederherstellung aus einem extern manipulierten Dump, nicht die primäre Absicherung). Praktisches kanonisches JSON (sortierte Schlüssel, UTF-8, keine Leerzeichen), ausdrücklich keine zertifizierte RFC-8785(JCS)-Implementierung — Zahlenformatierung und Nicht-BMP-Schlüsselreihenfolge sind nicht JCS-exakt, eine echte Lücke gegenüber der ursprünglichen Formulierung des Roadmap-Punkts. Hinter CMA_LEDGER_HASH_CHAIN gegated, default-OFF, noch nicht in Produktion aktiviert.

Phase 8 — Ed25519-Signaturen (Roadmap-Punkt 9, Teil 2 von 2). Eine Migration fügte zwei weitere nullable Spalten hinzu (signature, signing_key_id), und trading/cma/signing.py signiert jetzt bei Aktivierung das Hash-Ketten-Glied jeder Zeile (content_hash, previous_event_hash, plus stream_id/event_type/event_time, damit eine Signatur nicht auf eine fremde Zeile übertragen werden kann) mit einem Ed25519-Private-Key. signing_key_id ist ein kurzer, nicht-geheimer Fingerabdruck des öffentlichen Schlüssels — bewusst kein fest im Verifier verdrahteter Schlüssel, sodass eine künftige Schlüsselrotation die Verifizierbarkeit alter Zeilen nicht rückwirkend zerstört. Ein begleitendes verify_signatures() prüft jede signierte Zeile gegen eine vom Aufrufer übergebene Schlüssel-Map und meldet eine Zeile mit unbekanntem Schlüssel getrennt von einer tatsächlich ungültigen Signatur, da beides Unterschiedliches bedeutet (Abdeckungslücke des Verifiers vs. echte Manipulation). Der private Schlüssel selbst (CMA_LEDGER_SIGNING_KEY) wird ausschließlich aus der Umgebung gelesen, nie in die Datenbank oder dieses Repository geschrieben — und ist heute nicht gesetzt: Es existiert kein generierter Produktions-Schlüssel, CMA_LEDGER_SIGN_CHAIN ist nicht gesetzt/OFF, und Signieren setzt voraus, dass auch die Hash-Kette oben aktiviert ist. Roadmap-Punkt 9 (Hash-Kette und Signaturen) ist jetzt Ende-zu-Ende gebaut; Punkt 10 (externe Merkle-Checkpoints) bleibt offen.

Phase 9 — Retrieval-API, Teil 1 (Roadmap-Punkt 5). trading/cma/retrieval.py macht aus RQ-A eine abfragbare Funktion statt nur einer Hypothese: retrieve(as_of=T, ...) beantwortet „was wusste der Ledger zum Zeitpunkt T, und hielt es zu diesem Zeitpunkt für gültig" durch zwei Bedingungen: ingested_at <= T (eine Point-in-Time-Abfrage darf nie Informationen sehen, die das System erst später erfahren hat) und valid_from <= T < valid_to (halboffen, NULL bei valid_to bedeutet weiterhin gültig) — die Zwei-Uhren-Unterscheidung der CMA-Design-Prinzipien, jetzt in einer WHERE-Klausel erzwungen statt nur in Prosa behauptet. Ein begleitendes retrieve_latest_per_stream() nutzt Postgres DISTINCT ON (nicht ein naives Top-N-dann-Gruppieren, was ein rollback-isolierter Test nachweislich zum stillen Verlust eines echten Ergebnisses geführt hätte: Ein Stream mit wenigen Events kann von einem Stream mit vielen aus einer einfach abgeschnittenen Ergebnismenge verdrängt werden). Beide Funktionen akzeptieren zusätzlich gewöhnliche Scope-Filter (Tenant, Profil, Strategie, Asset, Memory-/Event-Typ, Autorität, Correlation-ID) und schließen standardmäßig nicht-aktive Lifecycle-Zeilen aus. Bewusst eng gefasst zum Zeitpunkt dieser Phase: kein Ranking, keine lexikalische oder Dense-Suche, keine Golden-Set-Evaluation — das war die Grundlage, auf der die späteren Phasen aufbauen, noch kein fertiges Retrieval-System (Roadmap-Punkte 7 und 8, beide unten separat inzwischen ausgeliefert). Die Docstring warnt ausdrücklich davor, dies ohne explizite tenant_id-Übergabe an einem mandantenfähigen Endpunkt zu exponieren, angesichts der eigenen früheren Evidence-API-Cross-Tenant-Leck-Historie dieses Codebase. 7 neue rollback-isolierte Tests.

Phase 10 — Prompt-/Modell-Registry (Roadmap-Punkt 6). trading/cma/model_registry.py ist eine kleine, code-basierte Registry bekannter (Komponente, Prompt-Version)-Paare, jeder Eintrag mit dem echten Git-Commit und Datum, das ihn eingeführt hat — bewusst keine Datenbanktabelle: GeoScores eigene Versionsdisziplin lebt bereits in der Git-Historie (eine versionierte PROMPT_VERSION-Konstante, vor jedem Rollout gegen ein Golden Set evaluiert), und eine separate mutable Registry-Tabelle könnte selbst von dem Code abdriften, den sie beschreiben soll — das Gegenteil dessen, wofür eine Registry da ist. Der Bau gegen echte Historie deckte eine echte, bisher undokumentierte Lücke auf: Eine frühere Kalibrierungsrunde, die fünf VIP-/Influencer-Golden-Set-Events ergänzte (Commits 880e3e1a/99b35ad8, 7/10 → 14/15), hat PROMPT_VERSION nie angehoben — nach wie vor geoscore-prompt-v2. Ehrlich im Registry-Eintrag vermerkt, statt rückwirkend ein "v2.1" zu erfinden, das dieser Codebase nie genutzt hat. Ein schreibgeschütztes audit_ledger_versions() durchsucht den lebenden Ledger nach jeder model_inferred-Zeile, deren (Komponente, Prompt-Version)-Paar diese Registry nicht kennt; gegen die Produktion ausgeführt fand es null unregistrierte Versionen (die einzigen model_inferred-Zeilen des Ledgers sind die 27 oben erwähnten geleakten Testzeilen, die zufällig eine echt registrierte Version tragen). Nicht als Enforcement-Gate in record_memory_event eingebunden — das wäre eine separate, spätere Entscheidung an einem bereits HIGH-Risk eingestuften, gemeinsam genutzten Writer, nicht Teil der Einführung dieser Registry selbst. 12 neue Tests, darunter einer, der den echten aktuellen Registry-Stand fixiert, sodass ein künftiges geoscore-prompt-v3 ohne passenden Eintrag laut fehlschlägt.

Phase 11 — Golden Set + CI-Non-Regression (Roadmap-Punkt 7). trading/cma/golden/cma_retrieval_golden_set.json friert 5 retrieve()-/retrieve_latest_per_stream()-Abfragen gegen echte, unveränderliche Zeilen aus dem AAS-Spiegelungs-Nachweislauf aus Phase 1 ein (die 5 Submodelle der TXN-Research-Shell, IDs 1276–1280), jede mit einer exakt erwarteten Evidenz-ID-Menge — keine Bereiche wie bei GeoScores LLM-bewertetem Golden Set, weil Retrieval über einen Append-only-Ledger bei fester Evidenz genau eine richtige Antwort hat. tests/test_cma_golden_set_unittest.py spielt jeden Fall gegen die lebende Datenbank als normalen Teil der pytest-Suite ab: echte CI-Non-Regression, kein separates Eval-Skript nötig. Der Bau des "aktueller Zustand je Stream"-Falls deckte einen echten Bug auf, bevor er je fixiert wurde: Alle 5 Zeilen der TXN-Shell teilen sich ein event_time (in einem Market-Watch-Zyklus gespiegelt), und der bis dahin nicht existierende Tiebreak von retrieve_latest_per_stream() gab still Postgres' Scan-Reihenfolge zurück, die beobachtbar die erst-eingefügte Zeile der Gruppe lieferte — die falsche Richtung für "aktueller Zustand". Behoben durch ein explizites id DESC als Tiebreak (die zuletzt in den Ledger gelangte Zeile gewinnt jetzt); der Tiebreak-Fall des Golden Sets fixiert das korrigierte Verhalten gegen dieselben echten Daten, die den Bug aufgedeckt haben, sodass eine Regression sofort auffiele statt neu entdeckt zu werden.

Phase 12 — Hybrides Retrieval (Roadmap-Punkt 8). Dieser Codebase hatte vor dieser Phase keine Vektorsuch-Infrastruktur: kein pgvector, kein Embedding-Generierungscode irgendwo, keine Embeddings-Oberfläche in der AION-MCP-Integration (direkt geprüft, nicht angenommen). Was bereits lief, war nomic-embed-text (768-dim, ein dediziertes Embedding-Modell, bestätigt vorhanden) auf derselben GPU-Ollama-Instanz, von der GeoScores LLM-Aufrufe bereits abhängen (100.98.188.22:11434) — der Bau brauchte also eine neue Postgres-Extension und einen neuen Python-Client, kein neues Modell und keinen neuen Server. Installiert wurde pgvector 0.8.1 (bestätigt von der bestehenden Rolle zentrader_researcher ohne Superuser installierbar — eine "trusted" Extension), plus eine nullable vector(768)-Spalte und ein HNSW-Cosine-Distance-Index auf cma_memory_events. Weil die Tabelle append-only ist, können Embeddings nicht wie eine normale "reservierte Spalte" nachträglich per UPDATE befüllt werden — trading/cma/embeddings.pys apply_embedding() läuft nur beim Insert, neben Hash-Kette und Signierung, und berechnet einen Vektor aus search_text, wenn vorhanden. Anders als bei diesen beiden wird ein fehlgeschlagener Embedding-Aufruf abgefangen und geloggt, nie geworfen: Es ist ein Netzwerkaufruf an eine entfernte GPU, der auch bei korrekter Konfiguration transient fehlschlagen kann, und der Evidenz-Vertrag des Ledgers darf nicht von der Erreichbarkeit dieser GPU abhängen. lexical_search() (Postgres ts_rank über den GIN-Index, den diese Tabelle seit Phase 1 trägt), dense_search() (pgvector Cosine Distance) und hybrid_search() (Min-Max-normalisierte gewichtete Fusion beider) sind drei unabhängig austauschbare Bausteine — die vom Roadmap-Punkt geforderte "austauschbare Schnittstelle". Einmal echt gegen die GPU verifiziert, Ende-zu-Ende, außerhalb der dauerhaften Test-Suite (in allen committeten Tests gemockt, passend dazu, dass auch GeoScores eigene Tests nie die echte Ollama-Instanz aufrufen): Eine Anfrage nach "Zentralbank Geldpolitik Zinsentscheidung" rankte über das Dense-Signal allein korrekt eine Zeile über "Fed signalisiert Zinssenkungen" ganz oben (lexikalischer Score 0 — kein gemeinsames Wort), ein echter semantischer Treffer, nicht nur Keyword-Überlappung. Beide neuen Flags (CMA_LEDGER_EMBED, gated die Insert-Zeit-Berechnung) default-OFF; kein Embedding wurde je in eine echte Produktionszeile geschrieben. 22 neue Tests über drei Dateien; komplette cma/geoscore/gate_decision/aas-Suite grün (263 bestanden), zusätzlich ein voller 1.826-Test-Gesamtlauf ohne Regressionen anderswo (2 vorbestehende, unabhängige Fehlschläge in einem unverwandten API-Bereich, von dieser Arbeit unberührt).

Phase 13 — die Model-Registry fängt ihre eigene Art von Drift ein zweites Mal. Phase 10 vermerkte ehrlich, dass GeoScores Prompt-Konstante trotz einer undokumentierten Kalibrierungsänderung noch geoscore-prompt-v2 war. Inzwischen ist geoscore-prompt-v3 ausgeliefert: eine neue, gegen das Golden Set evaluierte Änderung (eine TRACKED_ASSETS-Präferenzliste für Asset-Benennung, Golden Set 13/15 mit n=3 Self-Consistency-Läufen) hat die Version diesmal korrekt angehoben — geoscore-prompt-v2 ist in trading/cma/model_registry.py jetzt als deprecated markiert, geoscore-prompt-v3 ist der neue active-Eintrag mit den echten einführenden Commits. Die zwei Golden-Set-Fehlschläge, die unter v3 bleiben (ein Memecoin-Post-Score-Bereich, Exchange-Hack-Faktor-Vorzeichen), sind vorbestehende, von dieser Änderung unabhängige Kalibrierungslücken, keine neue Regression. Ein echter, kleiner Beleg für den eigentlichen Zweck der Registry: Eine reale Versionsänderung ist passiert, und sie landete in der Registry statt ein zweites Mal still zu verdriften.