Constraints Don’t Define Meaning. They Police It.
Meaning is not constraint-based.
I have spent a long time trying to name a distinction that shows up everywhere in software, business, data, science, and formal systems.
The distinction is not “rules vs reality.” It is not “logic vs meaning.” It is closer to this:
Constraints do not define meaning. They police the use of terms after meaning has been supplied.
That sounds abstract, so start with a deliberately simple example.
Imagine we define a thing called a Trippy. A Trippy is a closed polygon with three edges. A Righty Trippy is a more specific kind of Trippy: a Trippy with one 90-degree angle. In a Righty Trippy, we give names to the sides. The longest side is the Stretchy. The other two sides are the Shorties.
Then we define a property called ItsTrueItsTrue.
ItsTrueItsTrue is true when Stretchy² equals Shorty¹² plus Shorty²².
Now we can make a stronger claim:
Every Righty Trippy has ItsTrueItsTrue equal to true.
The silly names help reveal the structure. “Stretchy” does not mean anything by itself. “Shorties” does not mean anything by itself. “ItsTrueItsTrue” definitely does not mean anything by itself. The meaning appears only after the terms are named, connected, and used in a claim.
Now make it concrete.
The VIP Flag Is the Last Step, Not the First
A database constraint can tell you:
IsVIPmust be true or false.
But that only means: “The value must be one of two allowed answers.” It does not mean: “We know what a VIP is.”
To know what a VIP is, the business has to say what counts. Maybe VIP means the customer spends a lot. Maybe VIP means the customer has executive influence. In this company, VIP means something specific:
A customer is VIP when the customer is high value and low risk.
Now we are closer, but we are still not done. We have introduced two new business terms: high value and low risk. The constraint did not create those meanings. The business did.
The Shape of a Claim Is Not the Meaning of a Claim
This is where constraints can create the appearance of rigor while leaving the important meaning unresolved. A constraint can validate the shape of a claim. It cannot supply the meaning of the claim’s terms.
IsVIP must be true or false. That is constraint-based truth. But the meaning of VIP appears only when the business defines the named steps that produce the answer.
So we continue. Maybe high value means high revenue. Maybe high value means high margin. In this company, it means this:
A customer is high value when total sales in the last 18 months are greater than 500, or the customer is a strategic contact.
Now the business can say more than it could say before. Before, it could only say, “This customer is VIP.” Now it can say, “This customer is VIP because the customer is low risk and high value.” And if someone asks why the customer is high value, the business can answer, “Because total sales in the last 18 months are greater than 500, or the customer is a strategic contact.”
Each named term expands what the business can say. Each definition pins down what the business means. Each step makes the answer easier to inspect. That is where meaning starts to appear.
The Definition Has to Reach the Source Facts
The dangerous mistake is treating the final field as if it were the concept.
IsVIPmust be true or false.
That looks official. It is in the database, the dashboard, and the CRM. But the field is not the meaning. The field is just where the meaning lands after the business has done the work.
In our example, the work looks like this:
A customer is VIP when the customer is high value and low risk.
A customer is high value when total sales in the last 18 months are greater than 500, or the customer is a strategic contact.
Total sales in the last 18 months means the sum of all completed orders during the last 18 months.
A customer is a strategic contact when the customer is on the board or golfs with CEO Bob.
At the bottom, we finally reach source facts: orders, low-risk status, board relationships, and golf relationships. That is very different from saying IsVIP must be true or false.
The constraint tells us what shape the final answer must have. The definitions tell us what the answer means.
“Strategic Contact” Is Not Vague Once You Pin It Down
This is the part that often gets missed. A business term can sound vague without being useless.
Strategic contact could mean a public reference. Strategic contact could mean influence in a target market. But in this company, we pin it down:
A customer is a strategic contact when the customer is on the board or golfs with CEO Bob.
That may sound funny. It may even sound a little too fuzzy or imprecise. But that is the point. Businesses are human systems and often imprecise. Sometimes a meaningful business distinction includes a relationship, an exception, or a judgment made by leadership.
The issue is not whether the definition sounds elegant. The issue is whether the definition is clear enough that the business can inspect it, challenge it, and reproduce it. If “golfs with CEO Bob” is really part of how VIP treatment happens, then hiding it does not make the system more rigorous. It only makes the system less honest.
Constraints and Meaning Work Together
The point is not that constraints are bad and meaning is good. They work together.
The definition creates the business meaning. The calculation produces the answer. The constraint checks that the answer is allowed.
Constraint-based truthEmergent truthIsVIP must be true or falseA customer is VIP when the customer is high value and low riskHighValue must be true or falseA customer is high value when sales are over 500 or the customer is strategicTotalSalesLast18Months must be a numberTotal sales means completed orders during the last 18 months
The left side keeps the system coherent. The right side gives the business something to mean. Both matter, but they are not the same thing.
The Same Structure Was in the Geometry Example
The Trippy example had the same structure.
First, we named the parts: Trippy, Righty Trippy, Stretchy, and Shorties. Then we defined the parts: a Trippy has three edges, a Righty Trippy has one 90-degree angle, and the Stretchy is the longest side. Then we made the claim: every Righty Trippy satisfies the Stretchy-and-Shorties equation.
Now we are no longer just checking shape. We are saying something that should always hold. And if that claim fails, something has to give. Maybe the object was not really a Righty Trippy. Maybe the Stretchy was labeled wrong. Maybe the measurement was wrong.
The constraint can tell us the system broke. It cannot, by itself, tell us which piece of meaning failed.
The Same Thing Happens in Business
Now go back to VIP. There are also three layers.
Get eejai42’s stories in your inbox
Join Medium for free to get updates from this writer.
First, we name the business terms: VIP, high value, and strategic contact. Then we define the business terms: a customer is VIP when the customer is high value and low risk; a customer is high value when total sales in the last 18 months are greater than 500 or the customer is a strategic contact; and a customer is a strategic contact when the customer is on the board or golfs with CEO Bob.
Then we check the final answer:
VIP must be true or false.
That is the difference. The constraint says, “The final answer must be allowed.” The definitions say, “Here is why the final answer is true or false.”
One polices the answer. The other creates the answer.
BEGIN TRANSACTION
This is where the database analogy becomes useful. A business concept can be treated like a transaction.
Read the source facts: orders, risk status, board membership, and Bob’s golf list. Compute the named terms: total sales, strategic contact, high value, and VIP. Check the final answer: required facts exist, definitions were followed, and VIP is true or false.
If the transaction passes, commit. If it fails, rollback.
But rollback does not always mean the final constraint was wrong. It might mean an order was missing. It might mean the 18-month window was applied incorrectly. It might mean Bob’s golf list was stale.
The check tells us something broke. It does not replace the definitions. That is the important part.
Constraint-Based Truth vs Emergent Truth
This is the distinction I keep coming back to:
Constraint-based truth says the answer is allowed.
Emergent truth explains how the answer came to exist.
Constraint-based truth says: “IsVIP is a valid true-or-false value.”
Emergent truth says: “This customer is VIP because the customer is low risk and high value. The customer is high value because total sales in the last 18 months are greater than 500, or because the customer is strategic. The customer is strategic because the customer is on the board or golfs with CEO Bob.”
That second answer is longer, but it is meaningful. And because it is meaningful, it can be debated.
Should the threshold be 500? Should golf with Bob count? Should low risk be a source fact or a computed term? Those are business questions. The constraint cannot answer them. But once the business answers them, constraints can help keep the system honest.
Constraints Are Not Useless
This is not an argument against constraints. I use SQL every day. If my databases lost their constraints, I would be out of business immediately.
Foreign keys matter. Required fields matter. Validation rules matter. These things are not decorative. They are load-bearing.
But they are load-bearing in a particular way. They prevent collapse. They do not create meaning from nothing.
A foreign key can prevent an orphan order. A true-or-false field can prevent invalid values. A validation rule can reject inconsistent data. Those things are essential. They are just not omniscient.
They can tell us when something is invalid. They cannot tell us what the business should mean. They cannot tell us whether the business picked the right definition.
The Walking Stick and the Eyes
A useful analogy is the difference between a walking stick and eyes.
A walking stick does not show you the landscape. It tells you when you have hit something, when the ground drops, and when a boundary is nearby.
Eyes do something different. They disclose the scene. They help you orient. They let you choose direction.
Constraints are more like the walking stick. Emergent meaning is more like sight.
The walking stick is not useless. It may save your life. But it is not vision. That is the point.
The Risk of Fake Rigor
The danger is that constraints can make a system look rigorous before the meaning has been supplied.
You define:
IsVIPmust be true or false.
And suddenly everyone feels like VIP is part of the business model. But what happened?
You did not define VIP. You only made sure every customer record must take a position on an undefined idea.
That is where systems become dangerous. Not because they are loose. Because they are precise about the wrong layer. They are precise about the value shape. They are vague about the meaning.
The Better Question
When we see a field, rule, check, or classification, the better question is not only:
“Is this valid?”
The better question is:
“At what layer is this valid?”
Is it valid as a stored value? Is it valid as a named business term? Is it valid as a real-world claim?
Those are not the same. And when we collapse them, we get confused.
The Cleanest Version
Here is the distinction as simply as I can say it:
Constraints can tell you when a definition breaks. They cannot, by themselves, tell you what the definition should mean.
That is the whole thing.
Constraints are not meaning. Constraints are guardrails around meaning. They are the part of the system that says:
“Not that.”
But something else has to say:
“This is what we mean.”
And that meaning appears through named steps: VIP, high value, and strategic contact.
Each name expands what the business can say. Each definition pins the term down. Each check keeps the answer honest.
Only then does the constraint have something real to protect.
That is the difference I was trying to name.
