Guardrails: What It Does and What It Does Not

SIGNLD proposes; a person confirms. Proactive Knowledge Graph building is in beta in SIGNLD as of October 2026, with general availability planned for early 2027. The guardrail behind it is simple: nothing SIGNLD infers from connected systems becomes a fact in the graph until someone with context has looked at it.

That distinction matters because a graph that builds itself faster is also a graph that makes more proposals per hour than a person can review line by line. The guardrails exist to make sure speed does not turn into silent error.

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

Why guardrails exist at all

Before proactive building, the Knowledge Graph grew mostly from chat and direct user interaction, so review was baked into the workflow: someone asked a question, saw the answer, and implicitly corrected course by asking a follow-up. Proactive building removes that natural checkpoint because the graph now expands from connected systems on its own schedule, not from a question someone typed.

Guardrails replace that lost checkpoint with an explicit one. Every proposal SIGNLD generates from a new system, a schema change, or a newly discovered field carries a status: proposed, confirmed, or rejected. Only confirmed items feed a Decision Brief without a caveat attached.

What triggers a review request

Not every inference needs a human. SIGNLD only routes something for review when the confidence in an automated match falls below its threshold, or when the inference affects something with downstream consequences, like a metric definition that multiple Decision Briefs will depend on. High-confidence matches, such as an exact ID match between two systems, still get logged, but they do not block anything while they wait for a routine pass.

The review queue is prioritized by impact. A proposed relationship that only affects one narrow report sits lower than a proposed entity match that would merge two customer records used across finance, support, and sales data.

This prioritization is what keeps the review workload manageable as more systems connect. Without it, a team connecting five systems in a week could face hundreds of low-stakes proposals mixed in with the handful that actually matter, and the important ones would get lost in volume. Sorting by impact means the first thing a reviewer sees is the proposal most likely to affect a real decision, not the one that happened to be generated first.

Entity matches: what SIGNLD proposes and what you confirm

Entity resolution is the clearest example of the propose-and-confirm pattern. When SIGNLD sees "Meridian Group" in a CRM and "Meridian Group LLC" in an accounting system, it proposes that these are the same underlying customer, based on name similarity, shared contact fields, and overlapping activity timing. It does not assume they are the same and quietly merge them.

The proposal shows both source records side by side, the fields that support the match, and a confidence score. A person on the team confirms the match, rejects it, or leaves it pending. Until confirmed, any Decision Brief that touches that customer flags the entity as still resolving, rather than presenting a merged view as settled fact.

This matters most for edge cases: subsidiaries with shared names, franchises, or customers who changed their legal name after an acquisition. Automated matching is good at the common case and honest about the ambiguous one.

The confirmation step also creates a record that improves future proposals. When a person confirms or rejects a match, SIGNLD keeps that decision as context for similar future cases involving the same systems, so a naming pattern a team has already ruled out once is less likely to resurface as a fresh proposal every time a new record comes in.

Metric definitions: proposed versus locked

The same pattern applies to metrics. When SIGNLD connects a new finance system, it proposes a definition for something like "monthly recurring revenue" based on how the fields are labeled and how the numbers behave over time. Two connected systems can define a metric differently, one including one-time fees and the other excluding them, and SIGNLD will surface that conflict rather than silently pick one.

A person with domain knowledge, usually finance or operations, confirms which definition is correct for the business, or reconciles the difference explicitly. Once confirmed, that definition is locked and every future Decision Brief referencing the metric uses the same one, until someone changes it.

Metric definitions are one of the highest-value guardrails in the whole system, because a wrong metric definition propagates into every answer that touches it. Locking it behind human confirmation is deliberate, not a limitation to be worked around.

It is also one of the places where the tradeoff between speed and review is most visible. Proactive discovery can propose a metric definition the moment a new system connects, well before anyone has asked a question that depends on it. That is a real gain in how early a definition conflict surfaces. But surfacing the conflict early only helps if someone actually resolves it before the metric gets used in a Decision Brief, which is why SIGNLD holds the definition as proposed rather than defaulting to whichever system connected first.

Relationships between records

Relationships are the connective tissue of the graph: which deal belongs to which account, which invoice ties to which contract, which support ticket relates to which subscription. SIGNLD proposes these links from foreign keys, naming patterns, and timing correlation across systems. Direct foreign keys are usually high-confidence and get logged automatically. Inferred relationships, like linking a support ticket to a renewal based on timing alone, are flagged for review because timing correlation is suggestive, not proof.

Reviewing a relationship proposal is quick precisely because SIGNLD shows the evidence it used to infer the link, not just the conclusion. A person can look at the underlying records and confirm or reject in seconds, rather than starting from a blank investigation.

Relationships also compound. Once a person confirms that support tickets relate to renewals through timing correlation for one account, SIGNLD can propose the same kind of relationship for other accounts with a similar pattern, still as a proposal each time, not as an automatic rule applied silently across the whole graph.

Source trust and conflicting data

When two connected systems disagree about the same fact, SIGNLD does not pick a winner on its own. If a customer's status shows active in the CRM and canceled in the billing system, both records are held in the graph with the conflict visible, not resolved into a single silent answer. A Decision Brief touching that customer will note the conflict directly rather than pretend one system is automatically right.

Someone on the team sets source trust rules, deciding which system should generally be treated as the source of truth for which kind of fact, such as billing status coming from the billing system and account ownership coming from the CRM. Those rules apply going forward, but individual conflicts can still surface for a manual look when the rule does not cleanly resolve them.

This is a deliberate difference from systems that pick a winner by default, such as whichever source was connected first or whichever value is more recent. Recency and connection order are not reliable proxies for accuracy, and treating them as if they were would trade a visible conflict for an invisible error. SIGNLD would rather show two numbers and let a person decide than quietly present one as correct.

Comparison: proposed state vs confirmed state

Aspect	Proposed (unconfirmed)	Confirmed
Entity match	Shown with confidence score, not merged	Treated as one entity across all briefs
Metric definition	Flagged if sources disagree	Locked and applied consistently
Relationship	Logged with supporting evidence	Used without a caveat in briefs
Source conflict	Both values visible, no default winner	Resolved per source trust rules
Decision Brief treatment	Marked as based on unconfirmed data	Treated as settled evidence

Where SIGNLD fits

SIGNLD is built for teams who want the graph to grow ahead of their questions, not just in response to them, without giving up the ability to check what the system assumed. Read /how-it-works for how a Decision Brief traces every finding back to source records, and /roadmap for where guardrail review is headed next, including more automated confirmation for repeat patterns a team has already approved once.

This is the mechanism behind the broader idea of a proactive knowledge graph: speed on the building side, review on the confirming side. For a full walkthrough of the concept and how the pieces fit together, see the Proactive Knowledge Graph FAQ.

Key takeaways

Before proactive building, the Knowledge Graph grew mostly from chat and direct user interaction, so review was baked into the workflow: someone asked a question, saw the answer, and implicitly corrected course by asking a follow-up.
Entity resolution is the clearest example of the propose-and-confirm pattern.
Relationships are the connective tissue of the graph: which deal belongs to which account, which invoice ties to which contract, which support ticket relates to which subscription.
When two connected systems disagree about the same fact, SIGNLD does not pick a winner on its own.
Proactive building runs alongside the existing pattern of the graph learning from chat and data connections.

FAQ

Does SIGNLD ever merge entities without confirmation?

No. SIGNLD proposes entity matches with a confidence score and supporting evidence, but a person confirms, rejects, or leaves the match pending. Only confirmed matches are treated as a single entity across Decision Briefs. Unconfirmed matches remain visible as separate records with the proposed link flagged.

What happens if nobody reviews the queue?

Unconfirmed proposals stay unconfirmed. Decision Briefs that touch unreviewed items are marked as based on unconfirmed data rather than treated as settled, so the system stays honest about what has and has not been checked, even if review is delayed.

Can I turn off proactive building and go back to manual?

Proactive building runs alongside the existing pattern of the graph learning from chat and data connections. You can choose how actively to review proposals, but the underlying discovery from connected systems keeps running so the graph does not fall behind as new data arrives.

How does SIGNLD decide what needs review versus what gets logged automatically?

Confidence and impact. High-confidence matches, like exact ID matches, are logged without blocking anything. Lower-confidence matches, or ones affecting a metric or entity used broadly across Decision Briefs, are routed for a human to confirm before they are treated as settled.

Is a confirmed match permanent?

No. Confirmed matches, definitions, and relationships can be changed later if new evidence contradicts them, such as a customer name change or a source system correcting a record. SIGNLD flags a confirmed item for re-review if new data conflicts with the earlier confirmation.

Try SIGNLD free or see how it works.

Guardrails: what SIGNLD asks you to confirm before it commits

In this article