code the cause and infer the effects
DCM
A semantic execution layer for financial contracts — and a safer foundation for enterprise AI
DCM (Deep Cognitive Models) is a formal modeling approach for expressing financial contracts, post-trade workflows, custody relationships, settlement obligations, and distributed operational processes as executable, traceable action structures.
It is built on decades of synthesis across cognitive and brain sciences. At its core is a theory of how models can shift between levels of abstraction while preserving their connection to the domain they represent.
DCM is designed for the parts of finance where conventional software architectures become opaque and inefficient — producing complexity, hidden dependencies, and unwanted side effects.
- multi-party settlement and clearing;
- indirect custody chains;
- accounting structures (nostro/vostro, pooled/omnibus);
- reconciliation
- position administration and corporate action processing;
- netting and aggregation;
- operational exception handling;
- cross-party workflow traceability;
- AI-assisted contract and process automation.
What DCM models
DCM treats the core concepts of financial operations as first-class semantic objects rather than incidental consequences of code and tables.
The result is a model that can answer questions conventional systems struggle to answer directly:
Who is required to act next?
Which party has authority to instruct this action?
What must be true before the action can occur?
Which custody, account, and settlement relationships make the action possible?
What operational contract caused a specific low-level technical activity, such as sending a message, or a business-level change, such as the receipt of securities or a cash debit?
If this step fails, what downstream actions are affected, and which parties are impacted?
Is a reconciliation break merely an accounting discrepancy or a missing transaction — or does it indicate a breach of a deeper inter-party contractual or configuration relationship?
Can several obligations be netted against one another?
What is the most efficient way to execute millions of obligations collectively — for example, by minimising the number of movements and external fees — while still respecting the constraints of each individual contract?
Instead of conflating two domains into one, DCM aims to establish the modelling relation between the software (an implementation domain) and the business (as the target domain)
DCM as a semantic IR for AI/LLM in financial operations
AI agents need a world model, not just tools
DCM can provide governance for AI agents
Instead of giving an AI agent open-ended tool access and asking it to “resolve exceptions,” DCM can define:
- what the agent is allowed to know;
- which contracts and fibres it is involved in;
- which actions it may perform;
- which actions require external authorisation;
- what must be true before an action is attempted;
- which party must receive an instruction or confirmation;
- what evidence must be retained;
- what downstream obligations are affected;
- what context must be propagated across an interaction.
This turns an AI agent from an unconstrained prompt-driven actor into a participant in a formal operational environment.
DCM also provides a structured model of memory:
Semantic memory — construction definitions: what TRADE, CUSTODY, DVP, or REQUEST_REPLY mean;
Factual memory — runtime contract and account instances;
Episodic memory — enacted causal chains, timestamps, confirmations, and observed outcomes.
This is more disciplined than typical agent-memory designs that mix documents, logs, prompts, plans, and tool results without clear formal semantics.
From Trade Intent to Settlement Reality
DCM starts with a compact frame, such as a trade:
BUYER receives PRODUCT
SELLER receives CASH
It can then progressively elaborate the operational structure required to settle that trade:
TRADE
→ CUSTODY
→ BANK
→ RETAIL / CLIENT / POOLED / OMNIBUS ACCOUNT
→ VOSTRO / NOSTRO ACCOUNT
→ CSD
→ DVP
→ COMMUNICATION
Each added construction contributes a focused model of a specific operational relationship — a principle that allows complexity to scale through composition.
These models overlap through explicit bindings, progressively forming an integrated model of the trade's operational reality.
This gives DCM a fundamentally different composition model from conventional software.
DCM — TRADE Substrate: C-DAG Construction
Incremental appearance of substrate elements as each C-node's Overlay Instantiation Statement (OIS) executes — i0 → i16. This is construction, not enactment: elements accumulate monotonically and never disappear once bound. Node colour = figure chain (blue = STOCK/PRODUCT, amber = CASH); dashed teal/amber = mirroring links; purple dashed = info-plane (REQUEST_REPLY / COM) wiring, toggle on the right.
Controls
Current C‑node
i0—
C‑DAG timeline
Legend
DCM — TRADE Substrate: Simulated Enactment
The substrate below is already fully built (final C‑DAG state). This animates its RTLR enactment: a TC trigger fires at SETTLEMENT_DATE.SOD, causal change propagates down each mirror chain toward CSD, the DVP atomic exchange fires, and confirmation (:OUT) round‑trips back up to the top‑level TRADE nodes before SETTLEMENT_DATE.EOD. Node/edge styling follows §12: thin/no‑fill = not enacted, blinking = in‑progress, bold/filled = enacted.
Controls
Current phase
P0—
RTLR timeline
Event log
Legend
Conventional composition : isolated “lego blocks”
A conventional approach to building software for executing digital contracts typically reduces a contract to a static collection of disjoint technical artefacts.
In doing so, it loses semantic information and introduces syntactic noise from the outset.
Much of the subsequent development effort is then spent writing code to mechanically reassemble these static artefacts at runtime in order to produce the desired effects — such as the movement of cash or securities — through implementation-specific technical manipulations: inserting database records, sending formatted data snapshots or messages, invoking services, and so on.
The semantic relationships that gave rise to these artefacts are no longer intrinsic to the model. They have to be reconstructed through code, configuration, conventions, and runtime coordination.
DCM composition : collage model
DCM captures the semantic information that drives the construction of a contract from the outset and preserves it across every layer, all the way through runtime execution.
Instead of encoding effects independently and reconstructing their relationships later, DCM models the underlying causes and derives the operational effects from them — preserving the causal and semantic connections throughout.
Why DCM is different
1. Contracts become self-contained executable action structures
Custody, account servicing, and post-trade processing depend on multiple parties maintaining related but independently operated records.
DCM represents this explicitly via a special mirroring construct.
A mirrored relationship is not simply an alias or shared database row. It is a formal correspondence between independently maintained representations of the same underlying financial content.
This naturally models:
- custody books;
- nostro/vostro relationships;
- client and custodian positions;
- omnibus-to-segregated account views;
- CSD participant accounts;
- reconciliation obligations.
A break is not just “data mismatch.” It is a violation of a defined correspondence.
DCM does not stop at static terms and conditions. It models:
- who acts;
- on which asset or information object;
- at which location or account;
- under which authority;
- in which causal order;
- with which temporal triggers and deadlines;
- with what confirmation and communication requirements.
2. Reconciliation is first-class, not bolted on
3. Authority is part of the model
Financial operations are not governed only by physical or technical capability. They are governed by mandates, permissions, delegation, and institutional authority.
DCM represents this through dominion: a formal relation determining who may authorise a change in a given operational space.
For example:
- a custodian may locally operate an account;
- the client may retain authority to instruct operations affecting that account;
- an instruction must therefore be represented as a formal information event before the custodian can act.
This creates a native bridge between:
- operational action;
- communication;
- authority;
- evidence;
- auditability.
4. Netting and aggregation become model-derived
Traditional systems commonly implement aggregation and netting as product-specific ad-hoc SQL, batch jobs, or bespoke accounting logic.
In DCM, aggregation can emerge automatically from a shift in vantage, without writing any specific code.
For example, the same securities may be represented:
- individually by client custody account;
- collectively in an omnibus account;
- collectively again at a CSD participant account.
The correspondence between these views is explicitly modelled.
Netting and aggregation can therefore be derived from the relationship between more detailed and more aggregate operational vantages, rather than rebuilt separately for every product and infrastructure.
5. Every action can retain its causal lineage
A local action such as:
debit cash from a custodian’s nostro account
usually loses its business context once it enters a low-level workflow, API call, queue, or ledger process.
DCM introduces an activation context that can accompany operational activity across parties and contracts. This preserves a route from any immediate action—including purely technical actions—back to the contracts it is intended to implement, or to the ultimate cause that initiated it.
This creates a native form of distributed traceability:
Trade
→ custody obligation
→ pooled account action
→ nostro instruction
→ CSD settlement action
Rather than correlating logs after the fact to reconstruct the Humpty-Dumpty piece by piece, the causal relationship is part of DCM’s core operational model. Humpty-Dumpty is therefore never broken in the first place.