We'd Been Building a Knowledge Graph for a Month Before We Said the Words

We once had four copies of the same brand's DNA, and they disagreed.

Everything we build runs on deep, structured knowledge of a brand: its facts, voice, products, positioning, design decisions. And we build multiple products, each of which needs that knowledge. So each product, reasonably and independently, grew its own store of it. Four products, four stores, four slowly diverging versions of the truth about one brand.

Nobody chose that. Nobody would. It's just what happens when "ship the feature" meets "the data's right here" four separate times. Every copy was correct the day it was created. Copies don't stay created — they age, alone.

Before you file this under engineering problems that aren't yours: this is your brand's situation today. Your agency holds one version of your brand's truth. Your ads account holds another. Your email platform, your packaging copy, your founder's head — each a store that was accurate the day it was filled, each aging alone. The only difference between your four copies and ours is that ours were close enough together to notice them disagreeing.

The fix started as a series of purely tactical moves: a bridge here, a shared read there. It ended somewhere we didn't plan: a month of shipped changes later, someone finally said the obvious out loud. We're building a knowledge graph. A knowledge graph, if the term is new to you, is just a store of facts plus the connections between them (who said each fact, what it applies to, which facts depend on which), built so machines can traverse it. We'd shipped all of that under deadline pressure without once using the term.

I find the sequence more interesting than the destination, because the constraints found the architecture, not the other way around.

The shape the constraints forced

Look at what each "tactical" fix actually was, with the labels we'd have used if we'd been honest about the shape earlier.

One canonical store, everything else reads from it. Brand facts got a single home. Products still keep local working data, but a read that matters resolves against canonical truth — verified facts are overlaid onto whatever the product holds at read time, so a correction propagates everywhere without anyone syncing anything. Fix the founding year once, and every product that ever mentions the founding year is fixed.

Here is what that read looks like in practice. Every field in a brand's record comes back with a label: generated, verified, or absent. A founding year the machine pulled off your About page shows as generated. The day someone on your team approves it, the same field shows as verified, and the approved value is what every product sees from then on. And when a brand has no verified facts at all, the overlay changes nothing; the record reads exactly as the machine produced it, which is what made it safe to move every product onto one store without a visible change on day one. The absent label matters just as much. A record that knows what it doesn't know can tell an agent asking about your brand that the question has no answer on file, so the agent says so instead of guessing.

Provenance on every fact. Each fact carries where it came from and how it earned its status: extracted by a machine, or confirmed by a human. And the gate is blunt: only human-confirmed facts enter the verified store. AI proposes; people ratify. The trusted tier of the graph is human-writable only.

A fact, in this design, is a heavier object than a cell in a spreadsheet. Each one carries the claim itself, keyed so the same claim can't exist twice in the active record; a snapshot of the evidence captured when it was proposed, stored with the fact rather than linked somewhere and lost; where it came from, so a machine-proposed fact stays labeled that way forever; who proposed it and who approved it, with timestamps; a status on one life cycle; and an expected shelf life, because a price moves faster than a founding year. Say an import from one of our products proposes that your brand's parent company is such-and-such. That proposal lands in an inbox, labeled unverified, with its origin attached. It sits there until a person says yes.

The arrows point one way, by law. Product stores may promote knowledge into the canonical store. The canonical store never silently writes back down: "canonical never silently writes back into a product store — consumers adopt/suggest." One direction means no loops, no sync storms, no two-writers-one-fact ambiguity. Anyone who's ever watched two systems try to keep each other updated knows exactly which graveyard this rule fences off.

The rule has a concrete face. Our writing product keeps its own brand-level lists: safe vocabulary, banned words, tonal attributes, messaging pillars. Its compliance engine reads those lists live while it checks drafts. A silent overwrite from canonical could change what that engine enforces with nobody reviewing it. So canonical proposes: the writing product's screen shows what the canonical record suggests, labeled verified or generated, next to the value it currently holds, and a person on that side decides whether to adopt it.

Facts are not artifacts. The taxonomy fight that mattered most: a generated report about a brand is not knowledge of the brand. Reports, run logs, evaluation results (operational artifacts) are banned from the canonical store, which stays pure knowledge. Skip this distinction and your knowledge graph silts up into a data swamp with better marketing.

The line gets tested constantly, and the cases are instructive.

Each of those decisions was argued once, written down, and stopped being argued.

Even deletion is governed. Retiring a fact is human-only, and "a retired claim key never resurrects" — a fact a human killed can't be quietly re-created by the next automated import that stumbles over the same stale source. The retired fact stays on record as retired; that's part of the design. We learned to care about that the annoying way.

Two more governance moves ride with deletion. A load-bearing fact can be pinned, so nothing, human or automated, can retire or replace it until a person explicitly unlocks it; that guard lives in the store itself, which means it binds every writer, not just the polite ones. And facts age on purpose. On the shelf life it carries, a verified fact drops to "needs another look" and queues for a fresh approval, so last year's positioning doesn't get dragged into this year's work by a record that never doubts itself. Correction is deliberate rather than quiet: the wrong fact is retired with its history intact, and the corrected claim goes through the same inbox and the same human yes as everything else. You can always answer what we believed, and when.

Any one of these is a reasonable engineering call. All five together are a knowledge graph with governance. We made all five before using the phrase.

What naming it actually bought

Before the name, every one of those rules was a local decision some working session made and the next session might unmake. After the name, they compressed into law: a written contract, six rules, checked before any plan proceeds. The heart of it: any feature that stores brand knowledge product-locally must, in the same change, either promote that knowledge to the canonical store or open a tracked promotion-debt row. The contract's phrasing: "a plan that does neither is incomplete."

That debt ledger is my favorite clause. It concedes that teams under deadline will create local copies — of course they will; pretending otherwise is how architecture docs become fiction. So instead of forbidding the divergence, it makes divergence visible and interest-bearing: every debt has a row, and any later plan that touches a debtor store must restate or execute the promotion path. Copies still happen. Silent copies can't.

Some rows from the ledger, to make it less abstract. Our ad-creative product stores per-slot creative-direction overrides and a brand's chosen expressiveness default, both set by a human in settings. That's durable brand knowledge another product could act on, so it has a debt row, with the promotion path named: it crosses into canonical when that product moves onto the shared store. Other rows exist specifically to say no promotion is owed. A one-page read of a cold prospect's site, assembled for outreach, is unverified machine output about a brand that has never seen a Jinn screen; the row records that the canonical write is refused by design, so nobody later mistakes silence for permission.

This sounds like bureaucracy for a company of our size. It's the reverse. The inbox is what lets four products propose facts as fast as they like without any of them being able to corrupt the record. Speed at the edges, one gate in the middle. The alternative isn't fewer rules, it's the same rules re-argued in every session by whoever happens to remember them.

None of that was writable before the name; you can't write laws for a thing you haven't admitted you're building. The name turned a pile of bridges someone should probably document into a system whose rules hold across working sessions, products, and AI agents.

The transferable bit

There's a pattern here I now actively hunt for: convergent evolution in your own operation is a signal, and it fires before the industry hands you the vocabulary. When three or four independent fixes keep producing the same shape (the same rules, the same one-way arrows), you've stopped making tactical decisions and started building a thing, anonymously, and every week it goes unnamed you're paying the unnamed-thing tax: re-deciding settled questions, in every meeting, forever.

The pattern holds outside software, too. If you've ever built a master doc because three teams kept asking the same questions, then a change-log because people kept editing the master doc, then a rule about who's allowed to edit it — you were building governance for a brand truth store, anonymously. The move when you catch it: stop, name the shape, write down the laws the shape implies, and make something check them on every change. Ours went from "huh, another bridge" to a six-rule contract enforced at plan review in about a week, and the arguments stopped, because the rules stopped depending on who was in the room.

You've probably read essays about knowledge graphs being the substrate AI products need. Mostly, I buy it. But I'd flip the advice: don't set out to build a knowledge graph. Set out to make divergence of truth unacceptable, in your product or in your brand; follow that constraint wherever it drags you, and check what you have in a month. If it's a knowledge graph, it'll be one shaped like your actual problem, which is the only kind worth having.

The constraint was the architect. We just eventually learned its name.