Many enterprise data systems suffer from a hidden problem: the data no longer “knows” what it means. Over decades, business meaning has been fragmented across processes, rules and technical structures, making systems increasingly opaque and difficult to control.

Meaning-driven architecture offers an alternative. By explicitly modelling goals, decisions and domain concepts, systems become transparent, testable and easier to govern. Instead of hiding logic in process flows or rule sets, decision tables make reasoning explicit—providing a stable semantic foundation for both traditional IT and AI. Link

Traditional IT tends to organize systems around processes, data structures, and rules. Business logic is distributed across workflow diagrams, service orchestration, scripts, and rule fragments. The result is familiar to anyone who has worked in large systems: process spaghetti in BPM environments, and rule spaghetti in large rule engines. The underlying issue is the same in both cases. The real business reasoning of the organization is hidden inside technical control structures.

When decisions are implicit, systems accumulate process spaghetti or rule spaghetti.

This is why systems become opaque over time. You can see the flows, the rules, and the data fields, but it becomes increasingly difficult to answer the simple question: what decision is actually being made here, and why?

A more stable architectural approach starts somewhere else: with meaning.

Meaning-driven architecture is not about vague interpretations or philosophical abstraction. On the contrary, it is about making the structure of meaning in an organization explicit and operational. That means modelling three things clearly:

• the goals the organization pursues
• the decisions that realize those goals
• the domain concepts that give those decisions a consistent semantic basis.

https://rules-as-code.yellenge.nl/

“During a modernization program at a large insurance company, the CIO asked what seemed like a simple question:

“Where exactly do we calculate the deductible for travel claims?”

It should have been easy to answer.

But the team couldn’t find it.

They searched the claims system.
They checked the policy administration platform.
They looked in the rule repository.

Nothing.

Eventually they discovered the rule buried inside a workflow task—hidden in about 400 lines of script code inside a process.

But the real shock came later.

That rule had not been updated for four years, even though the underwriting department had already changed the deductible policy.

As a result, the claims system had been applying the wrong deductible.

For four years.

When they calculated the financial impact, the numbers were staggering.

That one hidden rule had resulted in over €50 million in incorrect claim payments.”

The fundamental unit of business value isn’t data. It isn’t AI. It isn’t any specific technology. It’s the decision. Everything else is infrastructure in service of making better decisions more consistently. But here’s the thing: if you can’t define the terms you’re using, you can’t define the decisions you’re trying to improve. And if you can’t define the decisions, you’re not optimizing anything. You’re just adding complexity and calling it progress. Link

I’ve been running an informal experiment for years. When someone uses a buzzword confidently, I ask them to define it. Not to embarrass them. Not as a gotcha. I just want to see what happens when someone has to turn a familiar noise into a clear thought. John lists “Big Data”, “Digital Transformation”, and the current “AI Agents” as examples.

When someone says “we need an agentic AI solution” in a meeting, the meeting just continues. The vague language goes unchallenged. The decision gets made on vibes dressed up as strategy… In professional settings, form without function can succeed for years because the feedback loop is broken or nonexistent.

The 95% use LLMs to generate text they can’t evaluate. They paste the output, skim it, and ship it. If it sounds right, it must be right. They’re using the tool the same way they use buzzwords: performing competence without verifying it.

The 1% use the same tool and get radically different results. Because they understand the domain, they can evaluate what the AI produces. They can spot where it’s wrong. They can take a good-but-incomplete output and connect it to adjacent concepts in ways the tool never would have on its own. They’re not just copying. They’re composing. The AI output becomes raw material that they can shape, extend, and combine because they understand the underlying system well enough to see connections that aren’t obvious on the surface.

“I start by modeling the decision, not the outcome.

That means explicitly writing down:
what is chosen, when it is chosen, what information is available at that moment, and what can be revised later. If you can’t answer those four questions cleanly, no amount of math will save you. Many systems silently assume perfect information and one-shot decisions, which is almost never true.

Next, I separate constraints into three classes: physical, policy, and preference.

Physical constraints are inviolable. Policy constraints are negotiable. Preferences are directional, not absolute. Most failures come from collapsing all three into hard constraints. The moment uncertainty hits, the system snaps. Introducing slack, penalties, and priority ordering is not “watering down” the model, it is acknowledging how decisions are actually made.

Then I intentionally stress the formulation.

I perturb inputs, loosen bounds, shift weights, and rerun. I’m not looking for a better answer; I’m looking for stability. If small changes in assumptions cause large swings in decisions, the formulation is overfit to a fictional world. A technically sound system should fail softly and predictably.

After that, I tune tolerances to meaning, not precision.

Numerical exactness is rarely the objective. What matters is whether two solutions are operationally different. If a system reacts violently to microunits, rounding, or noise, the issue is a mismatch between the mathematical surface and the business reality.

Finally, I design for iteration.

Any system that pretends it will be “right” the first time is already wrong. Decisions are revised, data improves, and incentives shift. The goal here is controllability over time. Systems that can be nudged outperform systems that demand obedience.

This approach applies whether you’re planning inventory, pricing products, allocating budgets, staffing teams, or tuning an ML pipeline.

The math matters. The algorithms matter.

But the dominant technical skill is learning how to build systems that survive contact with reality.

Welcome to engineering.”

This Year Panelists:
– Alan Fish, FICO
– Gary Hallmark, Oracle
– Guilhem Molines, IBM
– Denis Gagne, Trisotech
– Carlos Serrano-Morales, Sparkling Logic
– Adam DeJans Jr., Gurobi

Register for free at https://decisioncamp2026.wordpress.com/free-registration/
If you plan to present, see Call For Presentations: https://decisioncamp2026.wordpress.com/call-for-presentations/

• What is the real value you bring?
• Why am I paying for time instead of outcome?
• How do you use AI internally to be faster and sharper?” Link

Ian Fletcher: Real-Time Orchestration Has Begun. And It’s Always On. Link