The Garden Nobody Else Could Read

With the rise of AI, you probably heard about Knowledge graphs (maybe without deep understanding), but what about Ontology and Semantic Layer?

They answer a very fundamental question: where does the knowledge of your company lies. And how do you retain that knowledge. And make it actionable assets for AI agents or other systems.

Let's illustrate this in simple terms with the experience of a gardener, M. Michou.

Mr. Michou retired from his corner of the community garden on a Tuesday in October. By the following spring, three of the four families who inherited his old plot had lost their tomatoes to blight, and nobody could say why.

Nothing had changed. Same soil, same seeds, same sun. The only thing missing was Mr. Michou.

A second bed sat half-empty because nobody agreed on which corner it even was, and a rumor about bad soil had been treated as fact long enough to waste a planting.

Act One: the rules nobody wrote down

For thirty years, Mr. Michou never wrote much down. He didn't need to. He knew, without thinking about it, that tomatoes and basil are good neighbors (the basil keeps the parasites away), and that tomatoes and potatoes are bad ones (they share a disease, and planting them side by side all but guarantees a ruined season for both). He knew which corner caught the morning sun, which one dried out by July, and which combination had failed on him back in 2015, and why.

None of that lived in a notebook. It lived in his head, refined over three decades of closely watched seasons.

The notebook his successors did inherit said things like "planted six tomato plants, May 12." That's accurate. It's also almost useless on its own. It tells you what happened. It doesn't tell you what's allowed to happen next.

"A database stores what occurred. An ontology defines what's structurally true about a domain: which categories of things exist, how they're allowed to relate to one another, and which combinations are simply invalid."

Mr. Michou's real knowledge, the part that made his garden work, was never the log of what he planted. It was the rule set behind it: basil pairs with tomato, tomato never sits beside potato, the east bed goes to whatever needs morning sun. That rule set is what let him make a hundred good decisions a season without consulting anything. It is also exactly what left with him when he retired.

The same failure, at company scale

Replace the garden with almost any organization past a certain size, and the pattern repeats with uncomfortable precision.

The rules that actually govern how a business runs—which discount thresholds need a director's sign-off, which customer segments can't receive a given promotion, why a specific exception process exists for enterprise renewals—rarely live in one structured, discoverable place. They're split across a wiki page nobody has opened since the last reorg, a Slack thread in a channel that's since been archived, three conflicting versions of a policy document on a shared drive, and the memory of the person who wrote the original process and has since moved to another team, or another company.

That's tolerable, barely, as long as that person is still reachable. It stops being tolerable the moment any part of that decision-making gets handed to a system that can't ask a clarifying question, including, increasingly, an AI system.

"Feed clean data without the rules that govern that data, and AI doesn't reason. It pattern-matches, confidently, on precedent that no longer applies, or that was never quite right to begin with."

A model can read every document your company has ever produced and still get your business wrong, not because the model is weak, but because the rules were never written down anywhere it could read them. The output looks like judgment. It is closer to Mr. Michou's plot the season after he left: same inputs, no idea which combinations were ever meant to work.

Writing the rules down, not just the facts

Mr. Michou's successors eventually did what he never had to. The garden committee's first fix, after that bad spring, was exactly this: they sat down and wrote the rule set out properly. Not "six tomato plants, May 12," but "tomato pairs with basil, never with potato; east bed gets morning sun and takes the sun-hungry crops."

A living reference, not a diary. Revised each time a new rule was learned the hard way, that anyone taking over the plot could actually reason from instead of losing another season to rediscovering it.

The corporate equivalent is the same reference, scaled to a business: a single, version-controlled source stating which relationships and constraints hold true for your domain. In modern software and data architecture, this isn't just another text wiki. It is a machine-readable data model—often powering Knowledge Graphs, API semantic layers, or AI guardrails—that structures your business logic so both humans and automated systems can evaluate decisions against it.

It is unglamorous work, and it rarely shows up on a roadmap next to the features customers can see. That is exactly why it tends to get skipped, until the day a new hire, a growing team, or a newly deployed AI system needs an answer nobody centrally owns, and gets a confident, wrong one instead.

It felt like the problem was solved. It wasn't, not yet.

Act two: the shorthand only he understood

The committee's new rulebook was, on paper, complete. And almost immediately, three volunteers reading the same line, "plant basil at A3, keep clear of the potato bed", went to three different places. One thought A3 was the northeast corner. Another thought it was the raised bed by the gate. A third had never heard the plot referred to by letter-number codes at all and just guessed.

The codes weren't wrong. They were Mr. Michou's own private shorthand, developed over thirty years of talking to himself, never once translated for anyone who hadn't been standing next to him when he coined them. The rule was real. What it referred to wasn't shared.

This is the gap a semantic layer exists to close, and it's a different gap than the rules themselves. A semantic layer sits between raw, technical labels, usr_id, created_at_utc, tax_excl_amt, or in the garden's case, A3, N-row, S/P, and the plain business concepts everyone actually needs to act on: Customer, Signup Date, Revenue, or Northeast Bed, Morning Sun, Basil Row. Its job is translation, and its value shows up exactly at the moment two different people, or two different systems, need to mean the same thing by the same word.

Picture a large restaurant kitchen: supplier codes, cook times in seconds, induction plate assignments, a wall of jargon that means nothing to the person sitting at the table. The diner doesn't want RECIPE_ID_804_BATCH_3. They want to read "mushroom risotto" on the menu. The server's real job isn't carrying plates, it's translation: turning a diner's plain request into a precise kitchen order, and making sure that when two tables order the same thing, they get the same thing. Take the server away, and every diner has to walk into the kitchen and negotiate directly with the cooks, in the cooks' own vocabulary, guessing at what each code means.

That's what the garden committee had built without meaning to: a rulebook with no server standing between it and the volunteers trying to use it. The fix wasn't a new rule. It was a shared legend, one document mapping every code to one plain, agreed name, so "basil at A3" meant the same physical patch of dirt to everyone who read it, human or, increasingly for this committee, the small planting-reminder app one of the volunteers had started feeding the rulebook into.

In a company, the same failure shows up as finance and marketing each calculating "active customer" from the same underlying tables and arriving at two different numbers, confidently, in the same meeting.

A rule nobody can read the same way twice isn't a rule. It's a rumor with better formatting.

With the rules written and now translated into one shared vocabulary, the garden committee had a rulebook anyone could act on consistently. Still, one thing kept going wrong.

Act three: the rumor and the row

A new volunteer, a few weeks into the season, mentioned in passing that the north bed's soil "seemed pretty acidic this year." Nobody checked. It sounded plausible, it got repeated at the next two meetings, and by the time someone finally tested the pH, an entire round of planting had been routed away from a bed that turned out to be fine.

The rulebook hadn't failed. The vocabulary hadn't failed. What was missing was any way to tell a confirmed fact from a passed-along impression, and by the third meeting, nobody could remember which one the acidic-soil claim had started as.

This is the layer a knowledge graph adds, and it answers a different question than the first two: not "what's the rule" (ontology), not "what do we mean by this term" (semantic layer), but:

"what, specifically, is true on the ground right now, and how sure are we."

A knowledge graph connects real instances to each other as facts, this tomato plant, in this bed, next to this basil plant, in this square, rather than storing them as isolated rows in separate lists. The connections are what make it useful: ask "where should the next basil go" and the graph can trace the actual, current layout, not a rule in the abstract.

The discipline that makes a knowledge graph trustworthy, and the one the garden committee skipped, is keeping two tiers clearly separate.

1. A validated graph holds facts that are confirmed: this bed, this plant, this date, checked and certain.

2. A candidate graph holds signals that are only probable: a comment in a notebook, an inference, a "seemed like" claim, flagged as unconfirmed until someone actually verifies it.

The rule is simple and, under any real deadline pressure, the first thing teams quietly stop enforcing: no relation gets treated as fact without evidence.

Let an unverified signal sit at the same confidence level as a checked one, even once, and the whole map becomes something nobody can fully trust, which means every decision built on top of it inherits that same uncertainty without anyone choosing to accept it.

The corporate version of the acidic-soil rumor is an inferred label sitting in a CRM field, unverified, that an automated workflow later treats as settled fact, a customer marked "enterprise tier" from a stale sync, a lead marked "qualified" from a single ambiguous email, a churn-risk flag raised by a keyword match nobody reviewed. Confidence is not the same thing as evidence, in a garden or in a knowledge graph, and a system that can't tell the two apart will act on both with exactly the same certainty.

When a business needs all three at once

None of the garden's three fixes, on its own, would have gotten the next season right.

• The rulebook alone, without a shared vocabulary, is what the committee already tried: correct rules, three different interpretations of what they referred to.

• The shared vocabulary alone, without verified facts, would have had every volunteer agreeing perfectly on what "the north bed" meant while confidently planting around a soil problem that never actually existed.

• And a perfectly maintained map of verified facts, without the rules in the first place, is just an accurate record of a garden nobody knows how to plant, Mr. Michou's original notebook, dressed up with better data.

Picture an AI copilot inside a sales organization, asked whether it can approve a discount for a specific customer. Getting that one answer right requires all three layers to be doing their job at once. It needs the rule (the ontology): which discount tiers require a director's sign-off, and for which segments. It needs the shared vocabulary (the semantic layer): a single, consistent definition of "enterprise customer" computed the same way whether the system checks the CRM, the billing platform, or the support desk. And it needs the verified fact (the knowledge graph): whether this specific account is actually, currently, confirmed to sit in that segment, not inferred from a field that hasn't synced correctly in two quarters.

Miss any one of the three, and the copilot still answers. It just might be wrong, with exactly the same tone of confidence it would have used if it were right.

The bill always arrives

Mr. Michou's blighted tomatoes cost a season. A misapplied discount rule, a compliance exception waived by mistake, or an AI-assisted decision built on rules nobody ever wrote down rarely stays that small once an organization is operating at scale, and the person explaining it upward is never the one who skipped writing the rule down in the first place.

Data tells you what happened.

Rules tell you what's allowed to happen next.

A shared vocabulary makes sure that when two people, or two systems, use those rules, they mean the same thing by every term in them.

And a living, evidence-graded map of facts tells you what's actually true right now, not what seemed true when someone mentioned it in passing.

Skip any one of these, and what looks like a reasoned decision, from a volunteer, a director, or an AI system acting on the company's behalf, is a real gap quietly filled with a guess dressed up as confidence.

Every organization already has some version of all three. Most of them are incomplete in different places: rules that were never written down, terms that mean five different things across five teams, or facts nobody has verified since the tool that generated them was replaced two systems ago.

➡️ Where do your organization's actual business rules live today: in a single place your teams, and your systems, can reliably find, or in the head of whoever has been there the longest?

➡️ Of the three, which one is missing first in your organization: the rules nobody wrote down, the vocabulary nobody agrees on, or the facts nobody has actually verified?