Governance, quality & trust

TL;DR

A knowledge graph is a trust product. The moment one executive meeting catches it wrong — Acme listed twice, a dead subsidiary alive, revenue attached to the wrong parent — usage quietly collapses, and no amount of coverage wins it back. Trust is manufactured by four disciplines. Provenance: every fact carries where it came from, when, via what, and at what confidence. That's the difference between "the graph says" and "the graph shows." Quality metrics: coverage, correctness, freshness, and resolution precision, measured per domain and reported like product KPIs — because "is the graph good?" is otherwise unanswerable. Permissions: the graph aggregates your most connected view of customers and people, which means it aggregates risk. Access must be scoped at the node-and-edge level, and connection-making itself audited, because a graph can infer what no single source was allowed to say. Ownership: named stewards per domain and an ontology owner — or quality is everyone's job and therefore no one's. None of this is bureaucracy bolted on after launch. It's the operating system that keeps the asset an asset.

🎯 For the product leader

Why it matters — The graph's entire value proposition is being believable — to your teams, your AI features, and your auditors. Governance is what converts a pile of extracted facts into something a regulated enterprise will let near a customer. It is also, increasingly, what your buyers' security reviews grade.

What it changes in your decisions — Quality gets a dashboard and a bar, not a vibe. Features declare the confidence tier they consume. Launches gate on domain quality metrics. Privacy review treats inferred connections as data in their own right, not just the sources they came from.

Ask yourself — "If a customer, a regulator, or the DPO asked why the graph asserts this fact about them — can we show source, time, method, and who was allowed to see it?"

Risk if ignored — The quiet death: no incident, no postmortem, just teams drifting back to spreadsheets because the graph was wrong twice. Or the loud one: a re-identification or leakage finding, because nobody treated the connections as personal data.

Provenance: every fact shows its work

The unit of governance is not the dataset — it's the individual fact. Each edge carries its passport:

Four consumers justify the cost. Citations — an AI feature can ground every claim. Audit — in regulated domains, "how do you know this?" is a legal question with a deadline. Repair — when a source turns out wrong, provenance is the blast-radius map: find every fact and inference downstream and re-derive. Erasure — data-subject deletion must reach not just copied records but conclusions drawn from them. Without provenance, right-to-erasure over a graph is archaeology. Provenance is cheap at construction time and brutally expensive to retrofit. It goes in the pipeline from day one, or effectively never.

Quality: four numbers on a dashboard

"Is the graph good?" decomposes into four measurable questions, each with a different fix when it dips:

Three practices turn the numbers into governance. Report per domain, not globally. "94% correct overall" hides the 71%-correct supplier domain your risk feature reads. Tier the consumption. Features declare the quality bar they need — an internal explorer tolerates draft facts, while an AI answer to a customer reads only reviewed, fresh, high-confidence tiers. This one mechanism lets exploration and rigor share a graph without either poisoning the other. Gate launches on the metric. A graph-backed feature ships when its domain hits the bar, which converts quality from aspiration into a schedule input.

Permissions: the graph aggregates risk

The graph's superpower — connecting everything — is precisely its risk profile. Three problems are graph-specific, and standard database access control solves none of them:

• Aggregation. Each source was individually innocuous. Connected, they profile a person or expose a strategy. Fifty siloed facts about an employee were fine; the joined fifty are a dossier. Access must scope at node/edge level — which subgraph, which relationship types — not "graph: yes/no."
• Inference. Reasoning mints new facts — and can derive what no source was permitted to state ("these two 'unrelated' accounts share a beneficial owner"). Inferred facts need classification and review as data, with re-identification risk assessed on the connected whole. The DPDP/GDPR lens applies to conclusions, not just records.
• The AI backdoor. An assistant grounded on the full graph answers with anything it can reach. Retrieval-time permission filtering (lesson 6) is the enforcement point, and it must mirror source-system entitlements rather than inventing looser ones. The graph should never be the path by which someone learns what their CRM role hid — that's leakage with better tooling.

Ownership: the operating roles

Governance without names is a slideware ritual. The minimum viable cast: an ontology owner (arbitrates meaning, versions the contract), domain stewards (own correctness and the review queues for their entity types, sitting in the domain, not a central data office), a platform owner (pipeline, store, SLOs), and a privacy/security reviewer with standing over inferred data. Small graphs run this as hats, not headcount. What matters is that each question — "what does this mean?", "is this true?", "who may see it?" — has exactly one desk it lands on. It's the same lesson every data platform learns: assets without owners become swamps.

Failure modes

• The quiet death — no dashboard, no stewards. Two visible errors in front of the wrong audience, and the org routes back to spreadsheets without ever filing a ticket.
• Provenance retrofit — launched without source pointers "to move fast." The first audit, erasure request, or bad-source repair becomes a quarter-long dig.
• Global averages hiding local rot — the overall correctness number looks fine while the one domain your flagship feature reads decays below usability.
• Access modeled on sources, not aggregation — everyone who could see a source can see the joined view. The dossier problem ships as a feature.
• Inferred facts skipping privacy review — "we only derived it" is not a defense the regulator recognizes.
• Erasure that misses inferences — the record is deleted, but the conclusions built on it live on, citing a source that no longer exists.

Practitioner checklist

• Does every fact carry source, method, timestamp, confidence, and reviewer — from the pipeline's first day?
• Are coverage, correctness, resolution precision, and freshness on a dashboard, per domain, with named stewards behind each?
• Do features declare the quality/confidence tier they consume — and do customer-facing AI surfaces read only the top tier?
• Is access scoped at node/edge level, mirrored from source entitlements, and enforced at retrieval for AI features?
• Have inferred connections been through privacy review as data in their own right — including re-identification risk on the joined view?
• Can an erasure request propagate through provenance to derived facts — and has that path been tested, not just designed?

Related lessons

• Building the graph — where provenance and quality are manufactured (or forfeited).
• Knowledge graphs & LLMs — retrieval-time permissions and citation chains in action.
• Security & privacy sense — the broader privacy instincts this lesson sharpens for graphs.