You have the data. You don’t have the meaning.
Semantics, or ontology if you want the technical word, is what tells a system how your things connect and what can never be true at once. It’s the difference between data that records the past and data that can tell you what’s possible.
Nothing to write down. It gets derived from what you already have.
A thing has meaning if you can get more out of it than you put in.
Data is what you were told. Meaning is everything that follows from it. That’s not a metaphor. It’s the working definition, and it’s the only one you need.
Here is a symbol: 0.42. It has no meaning. It isn’t true and it isn’t false; there’s nothing here to agree or disagree with. Now watch it climb.
That third rung is the whole subject. And it gives us a test that is sharper than any definition:
Something has meaning to a system exactly to the extent the system can derive things it was never told.
By that test, most of what companies call their “data” has almost no meaning at all. It is inert. You get out precisely what you put in, minus what got lost. A filing cabinet with a very fast index.
Four facts in. Twelve facts out.
Philosophers borrowed ontology from the Greeks, where it means the study of what exists. In software it means something far more modest, and far more useful: a written-down account of what exists in your world, how those things connect, and what can never be true at once.
Three ingredients. Nothing mystical. Watch what happens when you have all three.
Look closely at what just happened, because it is the entire idea.
You typed four facts and the system holds twelve. The extra eight were not stored, retrieved, or predicted. They were derived, squeezed out of the relations by rules. That surplus is what meaning is. It’s the return on the model.
And the second column matters even more than the first. The system refused a statement it had never been warned about. Nobody entered a rule saying “Sam is not Anil’s father.” It simply follows from the shape of the world. And a system that knows the shape of the world can reject a lie it has never seen before.
A system that cannot say no should never be trusted when it says yes.
This is not new. It is the oldest thing we have.
Every time this works, we stop calling it an ontology and start calling it something plainer: a map, the accounts, the table on the wall. Which is exactly why nobody notices how much of civilisation runs on it.
Its genius was never the recording. It was one constraint: every entry must have a matching counter-entry. From that single prohibition, an error becomes structurally visible and a lie becomes expensive. Half a millennium later the world economy still runs on a rule you can state in one line.
He arranged the known elements by their relations, and then left holes, and described the properties of elements no human had ever seen. He was right. That is derivation from structure alone, and it remains the most spectacular demonstration ever staged of what meaning buys you.
A map is worse than a satellite photograph in every way but one. It throws away colour, texture, weather, ninety-nine percent of reality, and keeps only what connects to what. That mutilation is the point. You cannot reason with a photograph.
Notice what all three have in common. None of them is a bigger pile of data. Each is a smaller, harder, more opinionated account of what exists, and each one paid for itself a thousand times over precisely because of what it left out.
Meaning comes from what you refuse to include.
This is the part that surprises people, and it is the part that matters most.
The instinct, when you set out to model something, is to be generous. Capture everything. Leave nothing out. Add a field for it, just in case. This instinct is wrong, and it is wrong in a way that quietly destroys most modelling efforts before they produce anything.
Think about what a constraint actually does. To say these two things can never be true at once is to delete an enormous number of possible worlds in one sentence. The more a model forbids, the more it tells you. And the reverse is exactly as true, and much less comfortable:
A model that forbids nothing has told you nothing.
This is why the generous model fails. It accommodates every case, permits every combination, and offends no one. And it has, as a direct mathematical consequence, no power to conclude anything. It cannot derive, because nothing follows. It cannot refuse, because nothing is forbidden. It has become a filing cabinet with a philosophy degree.
The useful model is the mean one. Twelve things exist. They connect in six ways. Four things can never be true together. Everything else is noise, and we are choosing, deliberately and with our eyes open, to throw it away.
A model is not a copy of the world. It is a decision about what to ignore, and that decision is where all the value is created.
Once you can say impossible, the problem turns inside out.
Here is how most people imagine a hard decision gets made. There are many possibilities. You search them, score them, and pick the best one. It sounds obviously correct, and it is almost always hopeless, because the number of possibilities is never large. It is astronomically large.
Seat twenty people at one long table. That’s twenty factorial: two and a half quintillion seating plans. Check a million a second and the heat death of the universe arrives first. Nobody has ever “searched” a problem like this, including you, at your own wedding.
What you actually did was say what couldn’t happen.
Look at what you did not do. You never looked at a single seating plan. You never scored anything, ranked anything, or compared two options. You stated five things that couldn’t be true, and quintillions of possible worlds evaporated for free.
This is the inversion, and it is worth sitting with. A good decision is not something you go and find. It is what’s left standing once everything impossible has been removed. Constraints are not the obstacle to the answer. Constraints are the only reason there is an answer at all.
The technique has a name, constraint programming, and once you’ve seen the wedding table you already understand it. You name the decisions. You name what each one could still be. You state the rules. And then the machine does the only thing it ever does: it narrows. Every rule deletes futures, and the deletions cascade into corners nobody touched. Fix one thing, and six other things you never mentioned quietly lose half their options.
It doesn’t guess and check. It doesn’t sample and score. It eliminates. And when nothing survives, it doesn’t shrug and offer you its best attempt. It proves that you were asking for something that cannot exist, and it names the sentence that made it so.
Three powers, and nothing else has all three.
Facts nobody entered. Mendeleev’s missing elements. The eight relatives you never typed. Most of what an organisation needs to know, it already knows implicitly. Nobody has ever drawn the conclusion, because the premises were sitting in different rooms.
The ability to reject a statement it has never seen before, because the statement is the wrong shape. This is the one that makes a system trustworthy, and it is precisely the one a statistical system cannot have. A probability can be low, but it can never be impossible.
Because the answer arrived by a chain of reasons, the chain is the explanation. You get it for free, and you get it as a cause rather than a confidence score. Which means you can disagree with it, which is the only kind of disagreement worth having with a machine.
Derive, refuse, explain. It’s worth noticing that when a person can do these three things about a subject, we don’t say they have data about it. We say they understand it. That isn’t a poetic flourish. It’s the closest thing to an operational definition of understanding that anyone has managed, and it happens to be buildable.
Language became free. Ground did not.
For thirty years the scarce thing in software was expression. Building the interface, writing the query, wiring the report. That was the work, and meaning was a luxury nobody could afford after paying for the plumbing.
That constraint is gone. A language model will now write the query, build the interface, and explain the result in three languages before lunch. Expression is free.
But notice what it cannot do, no matter how large it grows. A model that has read everything ever written still knows nothing about your world, because your world was never written down. It lived in the heads of people who never had to explain it, in the exceptions they make without being able to say why, in the thing they always double-check on a Friday.
So the bottleneck moved, and it moved to a place almost nobody is looking. The scarce thing is no longer someone who can build the system. It is a truthful, written account of what is actually the case.
And there is a distinction here worth carrying around, because it is sharper than most of what gets said about AI: a statistical model can be wrong. A model of the world can be contradicted. Those are not the same thing. You can argue with the second one. You can point at the sentence that’s false and fix it, and everything downstream corrects itself. With the first, all you can do is believe it or not. That is not a relationship in which anybody should be making decisions.
Fluency was never the constraint. Ground was.
Two ways to waste four years.
This idea has been tried before, at enormous expense, and it mostly didn’t work. It would be dishonest not to say why, and the reasons are not incidental. They follow directly from everything above.
It tried to be universal.
The great semantic-web projects of the 2000s set out to model everything, for everyone, once. They produced standards of real beauty and almost nothing anybody used. The failure was not effort or talent. It was arithmetic.
A vocabulary broad enough to cover every domain must be loose enough to offend none of them. And a vocabulary that forbids nothing has, as we established, no meaning at all. Universality and meaning are in direct trade. Meaning is local, sharp, and slightly rude, or it isn’t meaning.
It asked human beings to type it in.
The second failure is more mundane and kills more projects. Somebody produces a magnificent model and then asks the organisation to populate it by hand. Nobody does. Nobody was ever going to. Six months later the model describes a company that no longer exists, and everyone quietly goes back to the spreadsheet.
A model that must be maintained by hand is already dead; it just hasn’t been told. The rules have to be derived from what the organisation already produces: its documents, its exceptions, its history of what actually happened. Otherwise the model will not survive contact with a Tuesday.
Three questions. Ask them about anything you decide badly.
You don’t need a platform to begin. You need to take one decision your organisation makes over and over, imperfectly, and ask three questions about it. They are not difficult questions. They are just questions nobody has written the answers to.
You will find, doing this, that the knowledge was never missing. It was in someone’s head, and in the exceptions they make without being able to explain, and in the reason they always check that one thing before they sign. It was never written down because they were never asked, and they were never asked because everybody assumed it was obvious.
Which is why this exercise is so much harder, and so much more valuable, than it looks. Writing down what is true is not a data-collection project.
It is the act of finding out what your organisation actually believes.
This is the whole of what we build.
PatternLab Cortex is these three moves — derive, refuse, explain — aimed at one hard domain: the factory that has to keep its promises.
Derive. The semantic model of your plant — products, lines, materials, routings, and the rules that bind them — is read out of the data you already keep, not authored by hand. The model you don’t build. Ask it what can make an order by Friday and it answers by walking the graph, because it knows what connects to what.
Refuse. The plan is written by a solver that narrows — the wedding table at the scale of a plant. A finite-capacity, constraint-programming solver never searches for a good schedule so much as it deletes every impossible one, and re-solves the instant a machine falls over, a material slips, or a rush order lands. It can prove a promise is unkeepable and name the constraint that broke it — which is why a date it gives you is a date the floor can hold.
Explain. Because every answer arrives by a chain of reasons, the chain is the explanation. One plan, one solver — so every team sees the same answer, and it’s an answer you can argue with rather than a confidence score you can only believe. The agents propose; the solver decides; you weigh in on the calls that matter.
You have the data. Now you can have the meaning.