How SIGNLD builds your Knowledge Graph in the background

When you connect a system to SIGNLD, work starts in the background immediately: reading the schema, identifying entities, and proposing how records across systems relate to each other. Proactive Knowledge Graph building is in beta in SIGNLD as of October 2026, with general availability planned for early 2027.

By SIGNLD Editorial · · 9 min read · Product explained
How SIGNLD builds your Knowledge Graph in the background

In this article

Step one: the read-only connection

The background process starts with authentication. You connect a system, spreadsheet, or database with read-only access, which takes about 15 minutes. Nothing is written back to the connected system at any point, and this holds true for every step that follows. SIGNLD only reads what's already there.

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

Once the connection is authenticated, SIGNLD has access to the system's schema, meaning the structure of its tables, fields, and any existing relationships defined in the source system itself, such as foreign keys in a database or object relationships in a CRM.

Step two: schema discovery

With access established, SIGNLD reads the schema: table names, column names, data types, and record counts. This step doesn't yet interpret what anything means. It's closer to an inventory, cataloging what exists in the connected system before any judgment is made about what it represents.

This inventory becomes the raw material for everything that follows. A system with clean, descriptive table and column names gives SIGNLD more to work with at this stage than one with cryptic internal naming, which is one reason why proposals coming out of this process carry a confidence level rather than being treated as certain.

Step three: entity candidate detection

Next, SIGNLD looks through the discovered schema for fields and tables that behave like entities, meaning they represent a real-world thing such as a customer, vendor, employee, product, or account, as opposed to fields that hold a metric, a date, or a status.

A customer ID column that's referenced across multiple tables in a CRM is a strong entity candidate. A one-off field that only appears in a single table and holds a free-text note is not. This step produces a working list of what the graph will treat as nodes, distinct from the attributes and metrics that will hang off those nodes.

Step four: cross-system matching

Once more than one system is connected, SIGNLD compares entity candidates across systems to find likely matches. This is the hardest part of the process, because real-world data is inconsistent. A company might appear as "Meridian Group" in a CRM and "Meridian Group LLC" in an accounting system. A vendor might have a slightly different spelling in a procurement tool than in an expense system.

SIGNLD proposes matches based on name similarity, shared identifiers where they exist, and patterns across other linked records. It does not require an exact string match to propose a connection, but it also doesn't treat a proposed match as confirmed just because it found one.

Step five: confidence scoring

Every proposed entity match and every proposed relationship gets a confidence score, reflecting how certain SIGNLD is that the proposal is correct. A match based on an exact shared identifier, like a matching email domain or account number, scores higher than a match based on similar but not identical names.

This scoring exists specifically because proactive discovery works with less certainty than a graph shaped by months of confirmed usage. Lower scores are a signal to a person reviewing the graph that a particular match deserves a closer look before it's relied on.

Step six: proposals wait for you

Nothing from steps two through five gets treated as final on its own. SIGNLD surfaces proposed entities, proposed cross-system matches, and their confidence scores for a person to review. A person can confirm a proposal, which locks it in for use in future Decision Briefs, or reject and correct it if the proposal is wrong.

This review step is what keeps a proactively built graph from silently encoding a bad match. If "Meridian Group" and "Meridian Group LLC" are actually two different companies with a coincidentally similar name, a person catches that at this stage, before a Decision Brief starts pulling evidence from both as if they were one account.

What this looks like with multiple systems connected

With three or more systems connected, the background process runs across all of them, not just pairwise. An entity like a customer might show up in a CRM, an accounting system, and a support platform, and SIGNLD attempts to resolve all three references to the same underlying entity, with a confidence score reflecting how strong the combined evidence is.

The more systems that are connected, the more evidence there tends to be for or against a given match, which is why confidence in older, more established matches in a graph tends to be higher than confidence in a match that was proposed the same day a system was connected. Time and additional connected data both feed into how reliable a given proposal turns out to be, even within a process that starts working the moment a connection is made.

Why this runs in the background instead of on demand

Running this process in the background, rather than only when a question is asked, changes what's available by the time someone actually needs an answer. If entity matching only happened at query time, the first cross-system question a team asked would have to wait on that matching work before it could return anything. By doing the discovery and matching proactively, as systems are connected, the heavier work of comparing entity candidates across systems is largely done ahead of time, and a new question can draw on proposals that already have a confidence score attached.

This also means the background process doesn't need to be triggered manually. There's no step where someone has to tell SIGNLD to "rebuild the graph" or "re-scan a connected system." The moment a new system is connected, or an existing connection's schema changes, the same discovery and matching steps run again on whatever is new, and any resulting proposals go through the same review step as before.

Comparison: what happens automatically vs what needs a person

Step Handled automatically Needs a person
Read-only authentication You authorize the connection -
Schema discovery Yes -
Entity candidate detection Yes -
Cross-system match proposals Yes -
Confidence scoring Yes -
Confirming or rejecting a match - Yes
Using a confirmed match in a Decision Brief Yes -

What you can check while proposals are pending

While proposed entities and matches are waiting for review, they aren't hidden from view. A person can see what SIGNLD has proposed, including the confidence score and, for cross-system matches, which specific records in each system led to the proposed connection. This means reviewing the background work doesn't require guessing at why a match was suggested; the underlying evidence is visible alongside the proposal itself.

This visibility is part of why the background process is designed to run continuously rather than as a one-time setup step. As more systems get connected and more matches get confirmed or corrected, the pool of proposals waiting for review changes too, and a team can check in on it at whatever pace fits how quickly they're bringing new systems online.

Related reading in this series: Manual vs proactive knowledge graph building and What proactive graph building does to time-to-first-answer.

Key takeaways

  • With access established, SIGNLD reads the schema: table names, column names, data types, and record counts.
  • Every proposed entity match and every proposed relationship gets a confidence score, reflecting how certain SIGNLD is that the proposal is correct.
  • With three or more systems connected, the background process runs across all of them, not just pairwise.
  • Schema discovery and initial entity and match proposals begin as soon as the connection is authenticated, which itself takes about 15 minutes.
  • No part of the proactive discovery process is treated as final without a person confirming it.

FAQ

Does connecting a system automatically change any data in it?

No. Every connection is read-only, and this applies to every step of the background graph-building process. SIGNLD reads schema and records; it does not write back to the connected system.

How long does the background process take after connecting a system?

Schema discovery and initial entity and match proposals begin as soon as the connection is authenticated, which itself takes about 15 minutes. The proposals then continue to refine as more systems are connected and as confirmed matches accumulate over time.

What happens if SIGNLD proposes a wrong entity match?

A person reviewing the graph can reject or correct it. The confidence score attached to each proposal is meant to flag matches worth a closer look, particularly ones based on similar but not identical names rather than a shared exact identifier.

Do spreadsheets go through the same background process as other systems?

Yes. Spreadsheets are treated as first-class sources, so a manually maintained tracker goes through the same schema discovery and entity detection steps as a database or CRM connection.

Is any part of this process final without review?

No part of the proactive discovery process is treated as final without a person confirming it. Proposals with any confidence level still wait for review before they're used to answer a real question in a Decision Brief.

Read the category primer in what is a proactive knowledge graph, and see more common questions in the proactive knowledge graph FAQ. Check current availability on the roadmap, and see the full mechanics in how it works.

Try SIGNLD free or see how it works.