Practical summary
Build document recall and decision-history prototypes with explicit source ownership.
CORE ARCHITECTURE · Implemented
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
Inspect how a candidate ranking can expose the factors that influenced it.
Build document recall and decision-history prototypes with explicit source ownership.
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.
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.
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.
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.
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.
source · revision e45410356ceb4e96f0dc26a83b02e1c18cf94860
source · revision e45410356ceb4e96f0dc26a83b02e1c18cf94860
source · revision e45410356ceb4e96f0dc26a83b02e1c18cf94860