Knowledge graph maintenance: what it takes

Maintaining a business knowledge graph means keeping data synced with source systems, catching schema changes before they break entity matching, onboarding new systems as they get adopted, and periodically reviewing definitions and stale entities. Most of this runs on automation; a smaller set of judgment calls still needs a person.

Sync cadence and what actually needs to be current

Not every entity in a knowledge graph needs the same freshness. Order status, ticket priority, and inventory counts change constantly and are usually worth syncing frequently, often near real time for systems that support it. Org structure, product catalog, and customer contract terms change rarely and can sync on a much longer cycle without anyone noticing a gap. Treating every entity type as if it needs identical sync frequency wastes compute and API calls on data that was not going to change between syncs anyway.

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

The practical approach is to set cadence by how often each entity type actually changes in the source system, not by a single company-wide default. This is a decision made once per entity type, and revisited only when a system's behavior changes, such as a CRM starting to support webhooks where it previously required polling.

Schema drift in source systems

Source systems change their own structure without warning: a CRM adds a new required field, a spreadsheet owner renames a column, an ERP vendor pushes an update that splits one field into two. Every one of these can break the mapping between the source system and the graph's entity model, and none of them come with advance notice to whoever maintains the graph.

The realistic response is not to prevent drift, which is not possible when someone else owns the source system, but to detect it quickly. A sync that suddenly returns a field of the wrong type, or stops finding a field it previously found, is a signal that should surface immediately rather than silently degrading the data quality of everything downstream. Left undetected, schema drift tends to show up first as a subtle data quality problem, a metric that looks slightly off, rather than an obvious failure, which is why detection matters more than prevention here. See knowledge graph data quality for how drift shows up downstream.

Onboarding a new system

Adding a new source system to an existing graph is a distinct maintenance event, not a one-time setup task that only happens at the start. Each new system brings its own entity types, some of which map cleanly onto entities the graph already has, Customer in a new billing tool probably maps onto the existing Customer entity, and some of which are genuinely new, a support tool's Ticket entity might not have existed in the graph before.

The work here is mapping the new system's entities against the existing ontology, deciding what maps to what already exists and what needs a new entity type defined, and then running entity resolution to match the new system's records against records already in the graph, using the approach described in entity resolution. Companies that adopt new tools regularly, which is most growing mid-market companies, should expect this to be a recurring task, not a one-time project completed when the graph was first built.

Entity match review

Automated entity matching, deciding that "Acme Corp" in the CRM and "Acme Corporation LLC" in the accounting system are the same customer, is not perfect. It gets the easy cases right almost automatically and produces a smaller set of ambiguous cases where confidence is lower, two records that might be the same entity or might genuinely be two different ones. Someone with business context needs to review these ambiguous matches periodically, because getting a match wrong in either direction has a cost: merging two entities that are actually different corrupts the record for both, and failing to merge two records that are actually the same entity fragments that customer's history across two silos.

The volume of matches needing manual review usually decreases over time as the matching logic learns from prior decisions, but it rarely reaches zero, especially for a company that keeps adding new systems or acquiring other companies. This review is a recurring, if shrinking, task rather than something completed once.

Definition changes

Business definitions are not static. What counts as an "active customer" or a "qualified lead" changes as a company's strategy changes, sometimes deliberately, following a policy decision, and sometimes informally, as different teams start using a term slightly differently without any single decision being made. A graph that stores a definition once and never revisits it will eventually diverge from how the business actually uses the term.

The realistic maintenance task is a periodic review, not a constant one, checking whether stored definitions still match how the business actually applies them, and updating the definition with a clear record of when the change took effect, using the same versioning discipline described in how a knowledge graph stores business rules. This review does not need to happen constantly, but it does need to happen on some regular schedule, because definitions drift quietly and nobody is likely to flag it until two reports disagree.

Deprecating stale entities

Entities accumulate. A product that was discontinued three years ago, a vendor the company stopped using, a project that closed out, all remain in the graph as nodes unless someone actively marks them inactive or removes them. Left unmanaged, this accumulation does not usually break anything outright, but it degrades the usefulness of certain questions, a "which vendors are we currently working with" query that includes vendors nobody has used in years is technically accurate and practically unhelpful.

The maintenance task is periodic, not continuous: identify entities that have had no new activity for a defined period, confirm with whoever owns that domain that the entity is genuinely inactive rather than just quiet, and mark it deprecated rather than deleting it outright, preserving the historical record while excluding it from current-state questions by default.

What is automated versus what needs a human

Sync execution, schema drift detection, and the initial pass of entity matching are all tasks a system can run without a person watching each one happen. What still needs a human is judgment on ambiguous cases: is this schema change meaningful enough to require remapping, is this entity match correct, has this definition actually changed or is one team just using it loosely, is this entity truly inactive. None of these decisions can be fully delegated to automation without accepting a real error rate on cases that matter.

A realistic way to think about the time commitment is that most weeks require no active maintenance work at all, because syncing and drift detection run in the background, and the recurring human tasks, reviewing ambiguous matches, confirming a deprecation, checking a definition, tend to arrive in short bursts tied to events like a new system going live or a policy change, rather than as a constant daily workload. Companies that expect zero ongoing attention are usually surprised by an occasional review need; companies that expect a full-time role dedicated to it are usually overstaffed for what the work actually requires.

Comparison: maintenance tasks by frequency and owner

Task	Typical frequency	Automatable	Who is needed
Data sync execution	Continuous to daily, by entity type	Fully	No one, runs unattended
Schema drift detection	Continuous	Fully	Alerts a person only when drift is found
New system onboarding	Per new system adopted	Partially	Someone to map entities and confirm matches
Entity match review	Ongoing, in a shrinking queue	Partially	Someone with business context on ambiguous cases
Definition review	Periodic, scheduled	Manual	Whoever owns the definition, finance or operations
Stale entity deprecation	Periodic, scheduled	Partially	Domain owner confirms before marking inactive

Where SIGNLD fits

SIGNLD automates the continuous parts of graph maintenance, sync execution, schema drift detection, and the initial pass of entity matching across 800+ read-only integrations, so the ambiguous cases that reach a person are a small, reviewable set rather than the entire dataset. Spreadsheets are treated as first-class sources, which matters for maintenance because spreadsheet structure tends to drift more often than a database schema. When a definition or a match needs a human decision, SIGNLD surfaces the specific case rather than requiring a general audit, and every Decision Brief shows its evidence with links back to source records, which makes it easier to notice when something in the underlying graph has gone stale. More on the overall approach is in how it works, and related terms are in the knowledge graph glossary.

Key takeaways

Not every entity in a knowledge graph needs the same freshness.
Adding a new source system to an existing graph is a distinct maintenance event, not a one-time setup task that only happens at the start.
Sync execution, schema drift detection, and the initial pass of entity matching are all tasks a system can run without a person watching each one happen.
There is no universal cadence, but a periodic scheduled review, tied to a quarter or a major planning cycle, catches most drift before it causes disagreement between reports.
Marking an entity deprecated rather than deleting it preserves the historical record for audit and trend analysis while excluding it from current-state questions by default.

FAQ

Does a knowledge graph require a dedicated maintenance team?

No, not for most mid-market companies. The continuous tasks, syncing and drift detection, run without a dedicated team when built on automated infrastructure. The tasks that need a person are periodic and judgment-based, which a data lead or operations owner can typically absorb alongside other responsibilities.

How often should entity definitions be reviewed?

There is no universal cadence, but a periodic scheduled review, tied to a quarter or a major planning cycle, catches most drift before it causes disagreement between reports. Waiting until two teams notice conflicting numbers is a more expensive way to find the same problem.

What happens if schema drift goes undetected?

Undetected drift typically shows up first as a subtle data quality issue, a metric that looks slightly wrong rather than a clear failure, because the sync keeps running but starts feeding in data that no longer matches what the mapping expects. This is why detecting drift quickly matters more than trying to prevent it entirely.

Is entity match review a one-time task after the graph is built?

No. New records keep arriving from every connected system, and some fraction of new matches will always be ambiguous enough to need review. The volume tends to shrink as matching logic improves, but it does not disappear.

Should stale entities be deleted or just deprecated?

Marking an entity deprecated rather than deleting it preserves the historical record for audit and trend analysis while excluding it from current-state questions by default. Deletion is rarely necessary and removes information that later analysis might need.

Try SIGNLD free to see how much of your own knowledge graph maintenance runs without manual work, or see how it works.

Knowledge graph maintenance: what it actually takes to keep one current

In this article