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 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 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.
The diagram shows how the conceptual structure gets executed, conducting a distributed process of trade settlement.
All the content is inferred from the same set of DCM source code files.
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.
The diagram shows the build up of conceptual structure required for executing a (simplified) stock trade settlement.
All the content is inferred from a small set of DCM source code files defining the frames and schemas and their composition.
Why DCM is different
Key distinguishing features
Semantic Transparency
At the heart of DCM lies the principle of semantic transparency: what you see is what you get. The structures you see in DCM are the actual structures of the business domain itself—not just technical constructs or intermediaries. This ensures that, when building with DCM, the business domain remains directly visible and transparent, both in the code and in the running software.
In DCM, meaning resides in the structures themselves.
By contrast, in traditional programming languages meaning is imposed externally and only made visible through naming conventions when attaching labels to technical elements.
Traditional code has a shallow dispositional semantics: it operates through accidental correlations rather than intrinsic structure.
Human Scaling
Traditional software is designed around the constraints of computer hardware, not the capacities and limitations of the human mind. As a result, technical solutions often become so complex that people struggle to keep an efficient grasp—whether in understanding what the system is actually doing or in making changes to implement new business features.
DCM takes the opposite approach: it employs mechanisms modeled on how human cognition (reasoning) work, grounded in decades of research in cognitive linguistics and brain sciences.
This preserves a human scale even within large and sophisticated software systems—keeping them easy to change and extend, and avoiding the trap of software losing its malleability as code size increases.
Perspectivity
DCM lets you overlay multiple perspectives on the same content.
The system ensures that these different views are complementary and non-contradictory, enabling the multidimensional whole to be automatically reconstructed from multiple projections—without requiring you to confront the full complexity of that whole directly.
This preserves human-scale reasoning.
Thus, DCM employs the so-called collage mode of composition, which allows overlap between parts.
Traditional programming languages, by contrast, are built on a Lego-block model of composition, which implies exclusivity of representation.
As a result, there cannot be multiple complementary projections: there are no cross-cutting hierarchies, only a single exclusive hierarchy that must capture all the variety of the content.
Agency
action guidance as raison d’être
DCM is based on a model of intersubjectivity that combines two notions of space: the subjective space of agents (e.g., parties to a contract, each having their own perspective) and an objective space representing the shared world. This objective space acts like a map in which each agent can step outside their own ego-centered perspective and understand the points of view of other agents.
Contrary to DCM, the traditional approach does not even recognise agency as such; there is no notion of dynamics, interaction, or an explicit temporal dimension in the implementation domain. There are only arrangements of memory cells whose values are numbers or characters.
This simply reflects the fact that programming languages are not really languages, but dressed-up instructions for computers originally designed for number crunching.
Generating Kernel
Following the natural path to build systems
The way to build with DCM is first to understand how something comes into being—what processes cause the appearance of a particular structural element, not just what the element is on its own, detached from the process that generated it.
It is like building a tree: follows the same way to build a tree as nature does : grow it from the seed.
If a different tree is required, the DCM approach would involve changing the seed or intervening in the growth process at the right moment—for example, by placing a barrier to limit the tree’s width or height.
Contrary to DCM, the traditional approach is to build an already gown up tree, simply by adding elements together.
This method does not reflect the tree’s morphology; the relationships between branches and leaves are lost. All elements are treated as equal, being given in their current shape and “appearing all at once” or as “pre-existing.”
This is inefficient as this method can not rely on the automatic replication of structure along the growth path (of change of the seed changes all the leaves in a tree) that the DCM approach is based on.
Modelling Relation
The formal relation between business and software
The way that DCM looks at the task of building a software system that runs a business is similar to how a biologist builds a model for a living organism.
It starts by acknowledging that solving this task involves two different domains, not just the task itself: the software domain and the business domain.
DCM then follows a formal framework that aims at establishing a specific relation between these two—the modelling relation—which ensures that the software is a model of the business and not just a superficial imitation.
Contrary to DCM, the traditional approach does not acknowledge the existence of the business domain as such; hence, the business domain manifests itself only informally as vague software requirements, lacking formal structure.
Another problem is that the business domain is treated as an afterthought, in the sense that it does not serve as a fundamental factor shaping the technical domain.
Rather, the business domain appears as a post-factum application of the technical domain (hence the term “business application”), where the latter was created prior to and without an understanding of the former.