A few weeks ago we argued that complexity compounds. Every reasonable technology decision adds something more to understand, maintain and depend on, until a company owns more systems than it understands.
The obvious reaction would be to build less. But some problems are genuinely complex, and pretending otherwise doesn't remove the complexity. It only pushes it somewhere you can no longer see it.
Complexity doesn't disappear. What you can decide is where it lives, who controls it, and whether you will still understand it years from now. Those decisions are made early, in the foundations, which is precisely where they are hardest to undo. We would rather pay the cost of thinking now than the cost of fixing later.
Deciding where complexity lives sometimes means taking it out of places where it doesn't belong. Most web applications, for instance, keep two versions of the same logic, one on the server and another in the browser, and then spend a great deal of effort keeping both in sync. Every duplicate is one more place where things can go wrong. We prefer a single source of truth. The logic lives in one place, and the screen does what it does best: showing what it receives. One place to understand, fewer places to fail and, almost as a side effect, interfaces that feel faster.
Other times it means accepting complexity on purpose. Our clients rarely start from a blank page: they already have machines, sensors and software from different vendors, and no two environments are alike. There, complexity is part of the problem itself. So instead of fighting it, we give it a structure. Our foundation is being built on an event-driven architecture, in which systems don't call each other directly but announce what has happened, and whoever needs to know reacts. For a simple problem, it would be too much. For environments where everything has to talk to everything, it is what keeps the rest simple.
Yet putting complexity in the right place is only useful if you can still understand what happens there, and understanding starts with remembering. Most systems work like a chalkboard: when a value changes, the old one is wiped out, and with it the story of how you got there. We prefer a ledger. Nothing is overwritten and every fact is kept, so we can go back to any moment, trace exactly what happened and use that history to anticipate what comes next. A system without memory is a system with amnesia. For us, intelligence is the art of using memory.
This is also why we are careful with AI. It makes building cheaper, but not understanding, and anything built without understanding turns into cognitive debt that sooner or later comes due. So we don't hand it the decisions that are core to a business. We use it where it genuinely helps: working on a company's own data and documents to answer questions about its own operations.
Which raises the last question: where does all that knowledge live? Memory and understanding are worth little if they sit in someone else's system. If your AI learns from your secrets, those secrets shouldn't leave the house. That is why our foundation is designed to run on each client's own infrastructure rather than on a platform shared by everyone. Their data stays theirs, and so does the decision about who can access it.
None of these choices makes much sense on its own. Together, they describe a way of building that we are bringing into the Semantic Digital Twin: a device sends a reading; the fact is recorded and never lost; the architecture carries it to whatever needs to know; the screen shows it instants later. Memory at the bottom, integration in the middle, simplicity at the surface.
Technology should increase what a company can do without taking away its control. Building that way takes more thought at the start. We think it is the cheapest decision a company can make.
----------------------------------------------------------
Built with love and:
