CORE ARCHITECTURE · Implemented

WDBX Graph Weights for Traceable Neural Retrieval

Inspect how a candidate ranking can expose the factors that influenced it.

MLAI Research · WDBX Core · MAY 2026 · 2 min read · research note

Practical summary

Build document recall and decision-history prototypes with explicit source ownership.

Status

The described source behavior is implemented; customer outcomes and deployment readiness are not established.

Reviewed 2026-09-30

Practical context

Inspect how a candidate ranking can expose the factors that influenced it.

Build document recall and decision-history prototypes with explicit source ownership.

Implementation and research boundary

The hybrid retrieval API first obtains vector candidates and then applies graph and caller-provided persona factors. Ranked results include observable score components alongside the borrowed vector and stable identifier.

A ranking factor can explain an ordering without proving a source is true. The caller supplies graph context and persona affinity; the library does not establish that an application captured a complete causal history.

Representing relationships without overstating them

A retrieval graph supplies record identifiers, timestamps and adjacency to the ranking layer. The temporal module builds an undirected reachability view from persisted causal records. This is useful for finding nearby context, but it deliberately loses the directional distinction needed for a causal explanation. A product should display the actual relationship available, such as proximity to a selected record, rather than relabel every edge as established causation.

Weight behavior and a worked example

For a reachable record at h hops, causal weight is the larger of a floor and decay raised to h. Default decay is 0.6 and floor is 0.25. A one-hop record receives 0.6, a two-hop record 0.36, and a three-hop record the floor because 0.216 is smaller. Missing reachability within the bounded search also returns the floor. These arithmetic examples explain the function; they are not measured retrieval-quality results.

\gamma(h)=\max(c_{\mathrm{floor}},c_{\mathrm{decay}}^h)

Evaluate factors and ranking stability

Construct equal-semantic candidates with different timestamps, reachability and persona factors so each influence can be isolated. Keep the original candidate set when comparing two weighting policies; otherwise a change in approximate search can be mistaken for a reranking effect. Record the complete factors and final order, including missing-node cases. Test zero persona affinity and stale records, because multiplying factors can suppress a semantically strong candidate. A decision-review interface should let the reviewer inspect the underlying source rather than treating a high combined score as an endorsement.

Evaluation before adoption

Start with a synthetic or authorized corpus. Check recovery, source identifiers, update behavior and retrieval relevance. Treat application permissions, data retention and deployment evidence as additional requirements.

Limitations

  • Storage integrity establishes consistency, not the truth of stored statements.
  • The reference cluster protocol does not establish production multi-host operation or sharding.
  • A ranking factor can explain an ordering without proving a source is true. The caller supplies graph context and persona affinity; the library does not establish that an application captured a complete causal history.

Supporting sources