Knowledge graph data quality: what good looks like

Knowledge graph data quality is measurable, not a feeling. The signals that matter are entity match rate, orphan node count, relationship coverage, freshness lag, definition conflicts, and the rate of questions the graph cannot yet answer. A knowledge graph does not need perfect data to be useful, it needs data good enough to answer the questions that matter this quarter.

Why "clean data" is the wrong target

Most data quality conversations start with an abstract goal like "clean data" or "trusted data," and that framing is part of why quality work stalls. Clean compared to what standard, trusted by whom, for which decision. Without a measurable definition, quality work becomes an open-ended project that never finishes, because there is always another field that could be more complete or another record that could be more consistent.

For the wider context, see our knowledge graph glossary of 40 terms.

A better starting point is to define quality in terms of specific, countable signals tied to what the graph is actually used for. A signal like entity match rate can be measured this week and again next month, and a change tells you whether quality is improving or degrading, unlike a vague sense of trust.

Entity match rate

Entity match rate is the percentage of records from source systems that get correctly linked to a single entity in the graph, rather than sitting as duplicates or unmatched fragments. If a customer named "Acme Corp" exists in the CRM, "Acme Corporation" exists in the ERP, and "Acme Corp." exists in the support tool, a high match rate means all three resolve to one node. A low match rate means the graph has three separate, disconnected representations of the same customer, and any question that depends on a complete view of that customer, total spend, open tickets, contract status, will return an incomplete answer without anyone noticing it is incomplete.

Match rate should be tracked per entity type, not as one blended number, because customer matching can be strong while product matching is weak, and averaging the two hides which one needs attention. The mechanics behind this matching are covered in more detail in entity resolution explained for business data.

Orphan nodes

An orphan node is an entity in the graph with no relationships connecting it to anything else, a customer with no linked orders, an employee with no linked tickets or projects. Some orphan nodes are legitimate, a brand new customer genuinely has no order history yet, but a high or growing orphan rate usually signals a broken connection somewhere: a join that used to work stopped matching after a source system changed a field, or a new system was connected without its relationships being mapped to the rest of the ontology.

Orphan nodes matter because they fail silently. The node exists, so a search or a listing will show it, but any question that requires traversing from that node to related information returns nothing, and the person asking the question has no way to tell whether "nothing" means "there is genuinely no related data" or "the relationship failed to link." Tracking orphan node counts by entity type and investigating spikes is one of the cheapest quality checks available.

Relationship coverage

Relationship coverage measures how many of the relationship types defined in the ontology actually have populated edges in the graph, and what fraction of eligible entity pairs are linked. An ontology can define that an Invoice links to a Ticket, but if that link is only populated for ten percent of invoices that should have one, questions about billing disputes will systematically undercount the problem.

Low relationship coverage is usually a source system issue rather than a graph issue: the underlying systems were never designed to record that link explicitly, and it has to be inferred from timestamps, shared identifiers, or matching logic. Measuring coverage tells you where that inference work is worth doing and where it is not, because a relationship that is rarely queried does not need the same investment as one that sits behind a question leadership asks every week.

Freshness lag

Freshness lag is the time between something changing in a source system and that change appearing in the graph. A deal that closed yesterday but has not yet shown up in a pipeline question has a freshness lag of at least a day for that entity type. Lag tolerance is not the same across entity types: a change to a customer's industry classification can lag by weeks without causing harm, while a change to an invoice's paid status lagging by days can lead someone to chase a payment that already came in.

The useful practice is setting a maximum acceptable lag per entity type based on how the data is actually used, then measuring against it, rather than aiming for real time everywhere. Real time synchronization for data that is queried monthly is wasted engineering effort, and stale data for something queried daily is a real risk. Time-aware structure, including how a graph tracks changes over time rather than just current state, is covered in temporal knowledge graphs.

Definition conflicts

A definition conflict is when two source systems, or two teams, use the same term to mean different things, and the graph has not resolved which meaning applies where. "Active customer" defined one way by sales and another way by finance is the classic case, and if the graph blends both without marking the distinction, any answer using that term is only correct for whichever definition the asker assumed. This exact conflict, and how a graph should represent competing definitions rather than silently picking one, is worked through in when finance and sales define revenue differently.

Definition conflicts are a quality signal worth tracking explicitly, as a count of terms with more than one active definition in use, because the number tends to grow quietly as more systems and teams get connected, and each unresolved conflict is a source of answers that look confident but rest on an assumption nobody stated out loud.

Unanswerable question rate

The most direct quality signal is not a property of the graph itself but of what happens when someone asks it a question. Unanswerable question rate is the share of real business questions that the graph cannot currently answer, whether because of missing entities, missing relationships, or conflicting definitions. Tracking this rate over time, and logging why each unanswered question failed, turns quality work into a backlog of specific, prioritized fixes rather than an abstract improvement project.

This is also the signal that should drive investment decisions. A graph with mediocre scores on every structural metric but a low unanswerable question rate for the questions leadership actually asks is doing its job. A graph with excellent structural scores but a high unanswerable rate on real questions is not, no matter how clean its numbers look on paper.

Good enough to answer versus perfect data

Perfect data quality, complete match rates, zero orphan nodes, full relationship coverage, is not a realistic target, and chasing it delays value. The more useful target is "good enough to answer the questions that matter now," which is a moving bar that expands as new questions come up rather than a fixed destination reached once and left alone.

In practice this means quality work should be triggered by a specific unanswered or wrongly answered question, not by a general audit schedule. When a question fails because of a low match rate on one entity type, that is the signal to invest in improving matching for that type specifically, not a reason to launch a company-wide data quality initiative. This keeps quality spend proportional to the value of the questions it unlocks, and it avoids the over-engineering trap described in the ontology primer, where structure gets built ahead of any real demand for it.

Comparison: quality signal, what it measures, and what a problem looks like

Signal	What it measures	Sign of a problem
Entity match rate	Percent of records correctly linked to one entity	Duplicate or fragmented entities per type
Orphan nodes	Entities with no relationships attached	Rising count, especially after a source system change
Relationship coverage	Populated edges versus eligible entity pairs	Low coverage on a relationship a real question depends on
Freshness lag	Time between a source change and graph update	Lag exceeding the tolerance set for that entity type
Definition conflicts	Terms with more than one active meaning in use	Growing count of unresolved conflicting terms
Unanswerable question rate	Share of real questions the graph cannot answer	Rate not falling as more systems get connected

Where SIGNLD fits

SIGNLD surfaces these signals as part of the private knowledge graph it builds from connected systems, rather than treating data quality as a separate audit exercise. Every Decision Brief SIGNLD returns includes a confidence score and evidence linked back to source records, so a low-confidence answer points directly at the entity or relationship behind it instead of leaving quality issues invisible. Connections are read-only across 800+ integrations, spreadsheets are treated as first-class sources alongside core systems, and quality improves incrementally as more systems connect and more questions get asked, matching the "good enough to answer" approach rather than requiring an upfront cleanup project.

Key takeaways

Most data quality conversations start with an abstract goal like \"clean data\" or \"trusted data,\" and that framing is part of why quality work stalls.
Relationship coverage measures how many of the relationship types defined in the ontology actually have populated edges in the graph, and what fraction of eligible entity pairs are linked.
A definition conflict is when two source systems, or two teams, use the same term to mean different things, and the graph has not resolved which meaning applies where.
Review them when a question fails or returns a low-confidence answer, and check the summary numbers on a regular cadence, monthly is reasonable for most mid-market companies.
Yes, in the sense that investing heavily in perfect coverage for entity types nobody queries is wasted effort.

FAQ

Do I need to fix every data quality issue before using a knowledge graph?

No. Fix the issues behind the questions that matter now. A graph with imperfect coverage everywhere but strong coverage on the entities your leadership actually asks about is more useful than one that delays launch chasing completeness nobody currently needs.

How often should these signals be reviewed?

Review them when a question fails or returns a low-confidence answer, and check the summary numbers on a regular cadence, monthly is reasonable for most mid-market companies. Frequency matters less than tying the review to real questions rather than running it as a standalone audit.

What causes definition conflicts to appear in the first place?

Different teams built their own definitions for the same term before ever comparing notes, usually because each team's system enforced its own logic in isolation. Connecting systems into one graph is often the first time the conflict becomes visible at all.

Is a rising orphan node count always a bug?

Not always. New entities with no history yet are expected to be temporarily orphaned. It becomes a problem when the rate grows steadily instead of leveling off, or when orphaned nodes are ones that should clearly have relationships, like a customer with no linked orders after months of activity.

Can data quality be too good for a small company's needs?

Yes, in the sense that investing heavily in perfect coverage for entity types nobody queries is wasted effort. Quality spend should track the value of the questions it unlocks, not an abstract completeness score.

Try SIGNLD free to see confidence scores and evidence attached to your own data, or see how it works. Related terms are defined in the knowledge graph glossary.

Knowledge graph data quality: what good actually looks like

In this article