How Did DCM Come About?
Though at this early stage DCM is a one-man show — with all the content presented on this site reflecting the author’s own ideas and interpretations — much of its underlying foundation comes from the extensive body of research in cognitive/brain/mind, linguistics and systems sciences. Sometimes, simply by standing on the shoulders of giants, even a solitary effort can bring forth something worthwhile.
The DCM idea emerged from more than a decade of reflection on software engineering in the trade processing business, where common practices often felt wrong and raised many fundamental questions that demanded answers—some of which are listed here under the Sisyphus, Black Box, and Humpty Dumpty Problems.
The most fundamental question was that of meaning and semantics: What is the actual semantics of the business domain?
And how does programming language code, which is semantically empty, manage to produce results when solving problems in a semantically rich domain?
At a certain point, it became clear that the fields of software development and computer science were not even capable of formulating these questions clearly—let alone answering them—because they were too narrowly focused on computers for number crunching and treated application domains only informally, as a secondary concern, as a post-factum application. Even the term application already projected the assumption that the “technical code level” had ontological priority over the “business domain,” with the latter not even acknowledged as a domain in its own right.
Furthermore, the appropriation of the term technical by programming language code made business logic itself appear to be something inherently informal, ambiguous, and undeserving of scientific scrutiny. There was too much focus on the existing tools and too little focus on the actual job.
The existing theory and practice of software development also ignored the human dimension almost completely, except at superficial visual levels (UX/UI). This situation was akin to observer-less physics more than a hundred years ago, or cognizer-less linguistics.
Even the mathematics used to ground programming languages felt inadequate, since it was too far removed from the kind of mathematics applicable to describing real-world applications for software. The technicality and formality present in programming languages felt like the wrong kind.
At the same time, the author had a strong interest in studying how the brain works as a system—particularly outside the narrow, purely computational viewpoint of artificial neural networks. While diving deeper into linguistics, brain sciences, scientific psychology, systems theory, and studies of natural systems, it became apparent that these were the fields where the earlier questions could not only be formulated but also answered to a satisfying degree.
Although brain science as such is not well aligned to produce formal models executable on a computer for industrial applications, it has provided the kind of foundation that mathematics provides for building bridges. At a certain point, many different ideas came together and began to form a cohesive whole, sharp enough to implement in a piece of software.
The domain of financial contracts and post-trade processing seemed particularly well-suited to serve as the target domain to formalize.
Though there were still many dark areas between those illuminated by one theory or another, the first prototype implementation of a (simplified) settlement process provided enough evidence that the method actually works at real-world scale and delivers results that “make the difference”—both qualitatively and quantitatively.
What was even more convincing was DCM’s and FVT’s ability to capture the semantics of most notions used in financial operations—far beyond how these have traditionally been encoded in software.
Concepts such as position, corporate action, and others have remarkably exhaustive interpretations that can be formalized and thus embedded in software.
Even though these concepts might initially seem very niche and specific to the trading domain, the structure of that domain was shaped by the same conceptual capacities of the human mind that operate in everyday, mundane life. At least, that was the hypothesis—and DCM appears to confirm it.
Thus, it should not be surprising that capturing common-sense logic and reasoning enables the automation of trade-processing businesses into a precise, clockwork-like system—far beyond what is possible when manually coding software at the level of superficial, contingent correlations (see the sections on how PLs mean).
Enabling computers to interpret these concepts in a way similar to how humans do enables the level of agility and flexibility in the business domain that comes closer to that of human thought and natural language.
In a sense, applying this approach is analogous to a transition from manual craftsmanship to industrial manufacturing—removing redundant degrees of freedom, automating low-level activities, and allowing for finer, deterministic control over the resulting product. Note that the current AI/LLMs do not allow for the first or the last of these.
Vasily Churilov, September 2025