What is the difference between filtering low-confidence edges during the walk versus filtering the final result set?

If filtering only happens on the final result set, a chain such as a high-confidence relationship from A to B, a low-confidence relationship from B to C, and a high-confidence relationship from C to D would still surface D as connected to A through the excluded B-C link, unless the traversal itself refuses to expand across that low-confidence edge. Excluding low-confidence relationships from the traversal path itself - not merely from the displayed results - prevents weak or ambiguous correlations from transitively pulling unrelated entities into an investigation's scope.

Why enforce hard node and depth ceilings regardless of the confidence threshold chosen?

A confidence threshold alone does not bound how far or how wide a traversal can grow if enough sufficiently-confident relationships happen to exist in a given dataset. Fixed, architecturally enforced maximum node counts and maximum traversal depth bound both the computational cost of a single query and the investigative blast radius it can reach, independent of how the confidence threshold is configured for a given investigation.

Confidence-Gated Bidirectional Graph Traversal Over a Relational Evidentiary Store

Q: Why run graph traversal as SQL over a relational store instead of using a dedicated graph database?

A dedicated graph database adds an entire second data store, a synchronization pipeline against the relational system of record, and a new source of consistency drift. Expressing multi-source, bidirectional breadth-first traversal directly as SQL over the same relational store that already holds the entity-relationship data avoids that duplication while still supporting the traversal patterns an investigation needs.

Executive Summary

JIL Sovereign's correlation graph stores entity relationships as rows in a relational table - source entity, target entity, relation type, and a confidence-rank value - and implements multi-source, bidirectional breadth-first traversal directly as SQL queries against that table, with no separate graph-database system in the architecture. Two properties distinguish the traversal itself from a conventional weighted-graph search.

First, edges below a specified confidence-rank threshold are excluded during each expansion step of the traversal, not merely filtered from the final result set - so a weak or ambiguous correlation cannot serve as a bridge that transitively pulls an otherwise-unrelated entity into an investigation's scope. Second, independent of whatever confidence threshold is configured, a fixed maximum traversal depth and a fixed maximum visited-node count are enforced architecturally, bounding both the computational cost and the investigative blast radius of any single traversal query.

Core Innovation: Low-confidence relationships are excluded from the traversal path itself during each expansion step - not filtered from a completed result set - so weak correlations cannot transitively pull unrelated entities into an investigation, and hard node/depth ceilings bound blast radius independent of the confidence threshold chosen, all expressed as SQL over the existing relational store with no separate graph database.

Problem Statement

Fraud, abuse, and clinical-correlation investigations frequently need to trace relationships between entities - claims, providers, members, events - several hops deep. Two common failure modes emerge in typical implementations. First, teams often reach for a dedicated graph database purely to support traversal queries, adding an entire second data store, a synchronization pipeline against the relational system of record, and a new axis of consistency drift between the two stores. Second, naive traversal algorithms treat every recorded relationship as equally trustworthy, so a single low-confidence or ambiguous relationship - a fuzzy name match, for instance - can pull an unrelated entity into an investigation's blast radius, while unbounded traversal depth or breadth can produce runaway queries and result sets so large they are impractical to review, and can improperly implicate parties whose only connection is several weak hops removed from any genuine signal.

Filtering weak relationships only after a traversal completes does not solve the second problem. A chain of relationships - strong, then weak, then strong again - can still connect two entities in the final result even when only the weak middle link made that path possible, unless the traversal itself is prevented from crossing that weak link in the first place.

Separate graph-database systems required

Relational table serving as both system of record and traversal substrate

Hard architectural ceilings bounding every traversal: max depth, max nodes

Why Common Approaches Fall Short

Dedicated graph databases (Neo4j, TigerGraph): provide native traversal primitives, but require a duplicated, separately-synchronized store alongside the relational system of record.
Weighted shortest-path algorithms: typically select the highest-confidence path between two points rather than architecturally excluding below-threshold edges from ever being walked at all.
Post-hoc result filtering: removes weak edges from what is displayed, but does not prevent those same weak edges from having already determined which entities were reachable in the first place.

Technical Architecture

Relational Edge Storage

Column	Purpose
`source_event_id`	Origin entity of the recorded relationship
`target_event_id`	Destination entity of the recorded relationship
`relation_type`	Nature of the relationship (e.g. shared identifier, shared address, temporal proximity)
`confidence_rank`	Strength/reliability of the correlation underlying this relationship
`evidence_basis`	Reference to the underlying signal(s) that produced the relationship and its confidence rank

Multi-Source, Bidirectional Traversal as SQL

Traversal is implemented as multi-source breadth-first search and bidirectional shortest-path expressed as recursive queries against the relational edge table, rather than as calls into a dedicated graph-database engine. Each expansion step applies a confidence-rank threshold filter before a candidate edge is allowed to extend the traversal frontier - the filter governs which edges the walk is permitted to cross, not merely which edges are shown in a final report.

Blast-Radius Bounding, Independent of Confidence Threshold

Regardless of how permissive or strict the confidence-rank threshold is configured for a given investigation, a fixed maximum visited-node count and a fixed maximum traversal depth are enforced architecturally at every expansion step. This ensures that even a dataset rich in sufficiently-confident relationships cannot produce an unbounded traversal - the ceilings are not merely a soft, configurable default but an architectural constraint on the traversal itself.

Traversal Algorithm & Blast-Radius Bounds

Consider a chain of three relationships: a high-confidence relationship from entity A to entity B, a low-confidence relationship from B to C, and a high-confidence relationship from C to D. Under a traversal that filters only its final result set, D can still appear as connected to A, because the walk was permitted to cross the low-confidence B-C edge to discover C and then D in the first place. Under confidence-gated traversal, the walk is refused permission to expand across the B-C edge at all once its confidence rank falls below the configured threshold - C and D are never reached from A via that path, regardless of what confidence the A-B and C-D relationships carry individually.

This distinction - excluding weak edges from the walk itself, rather than from the walk's output - is what prevents a single ambiguous correlation from silently expanding an investigation's reach to entities whose only connection to the subject of inquiry runs through that one weak link.

Prior Art Differentiation

Approach	Separate Graph-DB Required?	Confidence Filtering Point	Hard Node/Depth Ceilings?
Dedicated graph database (Neo4j/TigerGraph)	Yes	Query-time, typically post-traversal	Configurable, not architecturally fixed
Weighted shortest-path algorithms	Varies	Selects highest-confidence path, doesn't exclude below-threshold edges from the walk	Not inherent to the algorithm
Post-hoc result-set filtering	No	After traversal completes	Not addressed
JIL confidence-gated relational traversal	No	During each expansion step, before the walk proceeds	Yes - fixed, architectural

Patent Claim

Independent Claim 154: A computer-implemented method for confidence-gated relationship traversal over a relational evidentiary data store comprising: storing entity relationships as rows in a relational table, each row specifying a source entity, a target entity, a relation type, and a confidence-rank value; executing a multi-source, bidirectional breadth-first traversal expressed as queries against said relational table without reliance on a separate graph-database system; during each expansion step of the traversal, excluding from further traversal any relationship row whose confidence-rank value falls below a specified threshold, such that low-confidence relationships are excluded from the traversal path itself rather than filtered from a final result set; and enforcing, independent of the confidence-rank threshold selected, a fixed maximum traversal depth and a fixed maximum visited-node count, thereby bounding both the computational cost and the investigative blast radius of any single traversal query.