How proactive discovery finds the entities you never mapped

In this article

• What "never mapped" means in a query-driven graph
• What proactive discovery actually looks at
• The kinds of matches it tends to find
• A concrete example
• Why confirmation still matters
• What it's likely to miss
• How this compounds as more systems connect
• Comparison: query-driven discovery vs proactive discovery
• Where SIGNLD fits
• FAQ

What "never mapped" means in a query-driven graph

In a graph built entirely from usage, an entity or relationship only gets mapped once a question exposes the need for it. If nobody has ever asked a question that connects the shipping system to the finance system, the graph has no reason to know that a "warehouse code" in one and a "fulfillment location" in the other refer to the same physical site. The relationship exists in the data. It just hasn't been surfaced, because nothing forced it to be.

This is not a flaw in query-driven building so much as a natural limit of it: the graph only grows where someone has pointed it. Large parts of a connected system, especially the parts tied to questions nobody happens to ask often, can stay unmapped indefinitely even after months of regular use.

What proactive discovery actually looks at

When a system connects, SIGNLD pulls its schema and a sample of its data, the same starting point as before. Proactive discovery then compares that schema and data against what's already in the graph: field names, data types, value patterns, foreign key relationships within the new system, and record-level similarity against entities already known from other connected systems.

This comparison surfaces candidates: two tables that likely describe the same kind of entity, a field whose values overlap heavily with values already seen elsewhere, a naming pattern that strongly suggests a match. None of this requires a question to trigger it. It runs as part of bringing the system into the graph.

The kinds of matches it tends to find

Three patterns come up often. The first is naming variants of the same real-world entity, like a vendor listed under a legal name in the accounting system and a shortened trade name in the procurement system. The second is structural links that were never explicit, like a shipping system's "location code" matching a facilities system's "site ID" by value overlap even though the field names share nothing in common. The third is entities that exist in one system but were never represented at all in another, such as a product SKU tracked in inventory but absent from the CRM's product list, which discovery flags as a gap rather than a match.

A concrete example

Say a company connects a support ticketing system after already having a CRM and an accounting system in place. Proactive discovery looks at the support system's customer field and compares it against known customer entities from the other two systems. It finds that "Meridian Group" in the support system's account field lines up closely, by name and by overlapping contact email domains, with "Meridian Group LLC" already resolved between the CRM and accounting system. It proposes merging all three as one entity.

Nobody had to ask a question that touched support tickets and invoices together for that proposal to appear. It showed up because the systems were connected and the pattern matched. Whether the merge is correct is still a judgment call, since a large company can have multiple resolved subsidiaries with lookalike names, which is exactly why the proposal goes to a person rather than merging automatically.

Why confirmation still matters

Pattern matching finds strong candidates, not verified facts. A shared name, a shared domain, or overlapping field values are evidence, not proof. Two unrelated customers can share a name. A shared "region" field can carry different meanings in different systems even when the values look similar. SIGNLD surfaces what the match is based on alongside the proposal, so the person reviewing it can see the reasoning, not just a yes-or-no prompt.

This confirmation step is what keeps proactive discovery from turning speed into false confidence. A proposal that sits unconfirmed does not get treated as settled graph structure, and any Decision Brief that would depend on it reflects that with a lower confidence score or a note that the relationship needs review.

What it's likely to miss

Proactive discovery works from patterns in schema and data, so it tends to miss relationships that depend on context outside the data itself. Two entities that are genuinely the same but use completely different naming conventions, with no shared identifiers like email domains or account numbers, may not surface as a strong candidate at all. Business logic that lives in someone's head rather than in a field name or foreign key, like knowing that "Tier 2" in one system corresponds to "Priority" in another, also tends to go unmapped until a question or a manual correction brings it forward. Proactive discovery narrows the gap between connection and full mapping; it does not close it on its own.

How this compounds as more systems connect

The value of proactive discovery grows with the number of systems already in the graph, not just the number being added. A second connected system gives discovery one other source to compare against. A fifth or sixth connected system gives it several sources, which means a new connection can be checked against a much richer set of known entities and patterns right away. This is part of why teams that connect several systems in the same week tend to see more proposals surface sooner: there's simply more existing structure for a new system to be compared against.

This also means the quality of early confirmations matters more than it might seem. If a person confirms a match that's actually wrong early on, later proposals that build on that same entity inherit the mistake, since discovery treats confirmed structure as a reliable anchor for future comparisons. This is another reason SIGNLD shows the evidence behind a proposal rather than just asking for a click. A reviewer who can see that a match is based on a shared email domain, versus one based only on a loosely similar name, can make a better call, and that better call carries forward into everything discovery proposes afterward.

Comparison: query-driven discovery vs proactive discovery

	Query-driven discovery	Proactive discovery
Trigger	A question that touches the relationship	Connecting the system, regardless of questions asked
Coverage	Only what's been queried	Broad scan across schema and data
Timing	After the need is exposed	Before the need is expressed
Confirmation	Implicit, resolved while answering	Explicit, reviewed as a proposal queue
Blind spots	Anything nobody has asked about	Relationships with no shared identifiers or pattern in the data

Where SIGNLD fits

SIGNLD is a decision intelligence platform that unifies connected business systems, through read-only connections, into a private knowledge graph and returns ranked Decision Briefs with evidence linked to source records. Connecting a system still takes about 15 minutes and a first answer typically follows in minutes. Proactive discovery is the mechanism behind how that graph now proposes structure ahead of specific questions, with a person still confirming what gets kept.

Related reading in this series: How proactive graph building changes your first week and How SIGNLD builds your Knowledge Graph in the background.

Key takeaways

• In a graph built entirely from usage, an entity or relationship only gets mapped once a question exposes the need for it.
• When a system connects, SIGNLD pulls its schema and a sample of its data, the same starting point as before.
• Pattern matching finds strong candidates, not verified facts.
• Proactive discovery works from patterns in schema and data, so it tends to miss relationships that depend on context outside the data itself.
• The value of proactive discovery grows with the number of systems already in the graph, not just the number being added.

FAQ

Does proactive discovery replace the need for someone to check the graph?

No. It surfaces candidates for review; it does not commit them automatically. A person still confirms or rejects each proposed entity match or relationship before it counts as established graph structure.

Can proactive discovery find relationships across systems that were connected months apart?

Yes. It compares a newly connected system against everything already in the graph, regardless of when those other systems were connected, so a system added months later is still checked against existing entities.

What kind of evidence does SIGNLD show for a proposed match?

It shows what the proposal is based on, such as matching names, overlapping values, or a shared identifier like an email domain or account number, so the person reviewing can judge the match rather than accept it blindly.

Will proactive discovery ever merge two entities without asking?

No. Proposed matches go into a review queue. An unconfirmed proposal is not treated as accepted graph structure, and Decision Briefs that would depend on it reflect that with a lower confidence score.

What happens to entities discovery can't confidently match?

They stay separate and unmapped rather than being forced together. Low-confidence candidates are still surfaced, but SIGNLD does not guess past the point its evidence supports.

Try SIGNLD free or see how it works. Shipping status and what comes next are tracked on the roadmap. Read more in the proactive knowledge graph overview and the full FAQ.