What you still control when the graph builds itself

The practical question for anyone evaluating this is not "does SIGNLD build the graph automatically," it is "which specific decisions stay mine."

For the wider context, see our explainer on what a proactive knowledge graph is.

In this article

• The line between discovery and decision
• You control entity match confirmation
• You control metric definitions
• You control which systems are trusted for which facts
• You control what gets connected in the first place
• You control how aggressively proposals get made
• What SIGNLD controls instead
• Comparison: control before vs after proactive building
• Where SIGNLD fits
• FAQ

The line between discovery and decision

Discovery is mechanical: scanning a schema, noticing that two fields probably refer to the same entity, spotting a pattern in how a metric is calculated. SIGNLD does this work continuously once a system is connected, and it is the part that used to require someone to ask a question first before the graph would even notice the pattern existed.

Decision is judgment: is this really the same customer, is this the right definition of the metric for this business, does this system's number take priority over that one. Judgment requires context a proactive scan cannot have on its own, like knowing that a subsidiary was recently acquired or that one team still uses a legacy definition of a KPI. That is the part that stays with a person, by design.

The honest tension in proactive building lives right at this line. Moving discovery to the background makes the graph grow faster than a team could grow it by asking questions one at a time, and that speed is real. It also means proposals arrive faster than they used to, which is exactly why the decision layer has to stay firmly with a person rather than getting automated along with the discovery. Faster proposing without a matching commitment to reviewing would just mean more unreviewed guesses sitting in the graph.

You control entity match confirmation

When SIGNLD proposes that two records across systems represent the same entity, that proposal sits as pending until someone confirms it. Nothing about proactive building changes this. The system got faster at finding candidate matches, not at deciding they are correct. A person still looks at the proposed match, the evidence behind it, and either confirms it or rejects it.

This control matters because entity matching is exactly where local knowledge beats pattern matching. A person who knows the company just spun off a division can reject a match that looks statistically strong but is actually wrong.

It also matters for accountability. If a Decision Brief is ever wrong because two records were incorrectly treated as one entity, there is a clear record of who confirmed that match and what evidence they saw at the time. That traceability would not exist if the system merged records automatically without a confirmation step attached to a person.

You control metric definitions

SIGNLD can propose a definition for a metric based on how it sees the field used across a connected system, but it will not silently lock in a definition when sources disagree, and even when they agree, the definition stays a proposal until someone with domain knowledge confirms it. If finance defines "active customer" one way and support defines it another, that conflict surfaces rather than getting resolved by whichever system connected first.

Once a definition is confirmed, it becomes consistent across every Decision Brief that uses it, but the choice of which definition is correct for the business is a human call every time.

This holds even when a definition seems obvious. Two systems might report what looks like the same number for months before a specific transaction type reveals that they were never really counting the same thing. SIGNLD proposing a definition early gives a team the chance to catch that gap before it quietly skews a quarter's worth of Decision Briefs, but catching it still depends on someone confirming rather than accepting the first proposal by default.

You control which systems are trusted for which facts

Two connected systems will occasionally disagree about the same fact. SIGNLD does not pick a winner automatically. Someone on the team sets the rule: billing status comes from the billing system, account ownership comes from the CRM, and so on. Those trust rules apply consistently once set, but setting them, and revisiting them when they stop making sense, is a decision that belongs to the team, not the graph.

You control what gets connected in the first place

Proactive building only works on systems you have connected, using read-only access you granted. SIGNLD does not go looking for data outside the systems it has permission to read, and adding a new system is still something a person initiates. Faster graph building has not changed the boundary of what SIGNLD can see.

You control how aggressively proposals get made

Teams can tune how much gets surfaced for review versus logged quietly in the background. A team early in adoption might want to see every proposed entity match to build trust in the process, while a team that has already reviewed hundreds of matches from the same two systems might raise the confidence threshold so only the genuinely uncertain cases interrupt anyone. This tuning is a team decision, not something SIGNLD decides on its own.

Tuning the threshold changes volume, not authority. Raising it means fewer proposals interrupt a reviewer's day, but every proposal below the threshold still waits for confirmation before it is used as settled fact. No threshold setting turns an unconfirmed proposal into a confirmed one automatically.

What SIGNLD controls instead

SIGNLD controls the mechanics: scanning connected schemas as they change, proposing candidate matches with supporting evidence and a confidence score, flagging conflicts between sources, and keeping the graph current as new fields or tables appear. It does the repetitive pattern-finding work that used to require someone to notice a gap and go looking for it manually. It does not decide that a proposal is correct, and it never presents an unconfirmed inference as settled fact in a Decision Brief.

Comparison: control before vs after proactive building

Decision	Before (manual growth)	After (proactive building)
Who initiates discovery	A person asks a question first	SIGNLD scans connected systems continuously
Who confirms entity matches	A person, after being prompted by a question	A person, from a review queue
Who sets metric definitions	A person, when a metric first comes up	A person, when SIGNLD proposes one
Who resolves source conflicts	A person, if they notice the discrepancy	A person, because SIGNLD surfaces it directly
Who approves new connections	A person	A person

Where SIGNLD fits

SIGNLD is designed so proactive discovery does the scanning while a person keeps every judgment call. Read /how-it-works to see how a Decision Brief carries evidence and a confidence score back to the source records behind it, and /roadmap for what is planned next for review tooling.

This split between discovery and decision is central to what a proactive knowledge graph actually is: automation on the finding, human judgment on the confirming. See the Proactive Knowledge Graph FAQ for more on how the pieces work together.

Related reading in this series: How proactive discovery finds the entities you never mapped and How proactive graph building changes your first week.

Key takeaways

• Discovery is mechanical: scanning a schema, noticing that two fields probably refer to the same entity, spotting a pattern in how a metric is calculated.
• Two connected systems will occasionally disagree about the same fact.
• Proactive building only works on systems you have connected, using read-only access you granted.
• SIGNLD controls the mechanics: scanning connected schemas as they change, proposing candidate matches with supporting evidence and a confidence score, flagging conflicts between sources, and keeping the graph current as new fields or tables appear.
• A person sets source trust rules, deciding which connected system is generally authoritative for which kind of fact.

FAQ

Does proactive building remove the need for a human reviewer?

No. It changes when review happens, from reacting to a question to reviewing a queue of proposals, but the review itself still requires a person. SIGNLD never treats an unconfirmed entity match, metric definition, or relationship as settled fact in a Decision Brief.

Who decides which system wins when two disagree?

A person sets source trust rules, deciding which connected system is generally authoritative for which kind of fact. SIGNLD applies those rules consistently once set and flags individual conflicts that the rule does not cleanly resolve.

Can SIGNLD connect to a system without my approval?

No. Every connection is initiated and authorized by someone on the team, using read-only access. Proactive building only works within the systems already connected. It does not expand access on its own.

What if I disagree with a proposed entity match?

You reject it. The two records stay separate in the graph, and SIGNLD will not treat them as one entity in any Decision Brief. You can also leave a note on the rejection so a similar future proposal is scored differently.

Does tuning the review threshold change what SIGNLD is allowed to do?

No. It only changes how much gets surfaced for manual review versus logged automatically at high confidence. Even at the lowest review threshold, SIGNLD still requires confirmation before treating a low-confidence match or a disputed metric definition as settled.

Try SIGNLD free or see how it works.