Background
Phase 3 of the T-I-F RFC (dakera-deploy#161) is complete — node-level reliability scoring is live across MCP + all 4 SDKs. Phase 4 extends T-I-F from individual memories to graph structures: edges, paths, and neighborhoods.
Proposed by @SeCuReDmE-main-dev in PR #164 (Phase 4 handoff doc).
Problem Statement
Node-level T-I-F answers: "Is this memory reliable?"
Phase 4 answers: "Is the path that brought this memory into context trustworthy?"
A memory with confident_reuse reliability can still be misleading if the association that surfaced it is weak, the intermediate nodes are uncertain, or contradicting neighbors exist.
Existing Engine Surfaces (Research)
Dakera's graph engine (crates/engine/src/graph.rs) already provides the primitives:
| Surface |
Implementation |
Phase 4 Relevance |
| 5 edge types |
RelatedTo (cosine≥0.85), SharesEntity, Precedes, LinkedBy, Supersedes (cosine≥0.92) |
Each type carries different reliability semantics |
| Edge weights |
Cosine similarity for RelatedTo/Supersedes; 1.0 for explicit edges |
Weight → truth signal; low weight → indeterminacy |
| BFS traversal |
traverse(root, depth, namespace) up to depth 5 |
Path reliability degrades per hop |
| Associated recall |
include_associated=true, depth 1–3, min_weight filter |
Primary consumer of graph-aware reliability |
| Shortest path |
shortest_path(from, to, namespace) |
Path reliability scoring candidate |
| Cross-agent network |
Pairwise cosine across agent boundaries |
Higher indeterminacy than same-agent links |
| Superseded IDs |
superseded_ids(namespace) → HashSet |
Knowledge-update provenance |
| Knowledge graph |
Full pairwise similarity, Union-Find clustering |
Neighborhood reliability context |
Edge Weight Semantics (Current)
| Edge Type |
Weight |
Meaning |
related_to |
cosine similarity [0.85–1.0] |
Semantic closeness |
shares_entity |
1.0 (fixed) |
Shared entity tags |
precedes |
1.0 (fixed) |
Temporal ordering |
linked_by |
1.0 (fixed) |
Explicit user link |
supersedes |
cosine similarity [0.92–1.0] |
Knowledge update |
Gap: No Reliability Metadata on Edges or Paths
Currently, the min_weight filter on associated recall is a simple threshold — it doesn't carry T-I-F semantics. A related_to edge with weight 0.86 and a linked_by edge with weight 1.0 are treated identically once they pass the filter.
Proposed Approach
Phase 4a: Agent-Side Edge Reliability (No Engine Changes)
Derive edge T-I-F from existing graph output. No engine changes, no new endpoints.
Edge reliability heuristic:
linked_by: T=0.85, I=0.10, F=0.05 (explicit, high confidence)
shares_entity: T=0.55, I=0.30, F=0.15 (entity match, moderate confidence)
precedes: T=0.50, I=0.35, F=0.15 (temporal only)
related_to: T=weight, I=1-weight, F=0.0 (cosine similarity)
supersedes: T=weight, I=1-weight, F=0.0 (high-cosine update)
# Node contamination: if source or target falsity ≥ 0.50,
# edge falsity = max(edge_falsity, 0.50)
Deliverable: examples/tif-graph-reliability/validate_tif_graph_reliability.py
Phase 4b: Path Reliability
For path A → B → C:
path.truth = min(all node truth, all edge truth)
path.indeterminacy = max(all node indeterminacy, all edge indeterminacy, hop_penalty)
path.falsity = max(all node falsity, all edge falsity)
Hop penalty: [0.00, 0.05, 0.12, 0.20] for depths 0–3.
This ensures a path is no more reliable than its weakest link.
Phase 4c: Neighborhood Context (Contradiction Surfacing)
When include_associated=true returns neighbors with high falsity, surface them as contradiction evidence rather than hiding them. Expected behavior:
primary memory: confident_reuse
associated memory: surface_contradiction (falsity ≥ 0.50)
graph-aware action: reuse with surfaced contradiction evidence
Phase 4d (Future): Engine-Side Graph Reliability
If agent-side validation proves the model works, consider:
- Adding
edge_reliability field to GraphEdgeResponse
path_reliability field in GraphPathResponse
neighborhood_reliability in RecallResponse.associated_memories
- Optional
graph_aware_classification in recall results
Validation Scenarios
- Reliable node, weak edge: A memory with T=0.9 reached via a
related_to edge with weight 0.86 → node-only says confident_reuse, graph-aware says verify_before_use
- Contradiction neighbor: Primary recall + associated recall surfaces a high-falsity neighbor → diagnostic evidence
- Multi-hop uncertainty: Good memory at depth 3 via uncertain intermediaries →
verify_before_use
- Cross-agent caveat: Cross-agent network links carry higher base indeterminacy than same-agent explicit links
Non-Goals
- No engine changes in Phase 4a/4b
- No new MCP tools initially
- No quaternion/Euler/Riemann math
- No deletion of high-falsity memories (they're diagnostic evidence)
References
Suggested Build Order
- Agent-side edge reliability validator (Python script, no engine changes)
- Path reliability computation (Python script)
- Validate with 4 scenarios above
- If model proves useful → engine-side integration RFC
Background
Phase 3 of the T-I-F RFC (dakera-deploy#161) is complete — node-level reliability scoring is live across MCP + all 4 SDKs. Phase 4 extends T-I-F from individual memories to graph structures: edges, paths, and neighborhoods.
Proposed by @SeCuReDmE-main-dev in PR #164 (Phase 4 handoff doc).
Problem Statement
Node-level T-I-F answers: "Is this memory reliable?"
Phase 4 answers: "Is the path that brought this memory into context trustworthy?"
A memory with
confident_reusereliability can still be misleading if the association that surfaced it is weak, the intermediate nodes are uncertain, or contradicting neighbors exist.Existing Engine Surfaces (Research)
Dakera's graph engine (
crates/engine/src/graph.rs) already provides the primitives:RelatedTo(cosine≥0.85),SharesEntity,Precedes,LinkedBy,Supersedes(cosine≥0.92)traverse(root, depth, namespace)up to depth 5include_associated=true, depth 1–3,min_weightfiltershortest_path(from, to, namespace)superseded_ids(namespace)→ HashSetEdge Weight Semantics (Current)
related_toshares_entityprecedeslinked_bysupersedesGap: No Reliability Metadata on Edges or Paths
Currently, the
min_weightfilter on associated recall is a simple threshold — it doesn't carry T-I-F semantics. Arelated_toedge with weight 0.86 and alinked_byedge with weight 1.0 are treated identically once they pass the filter.Proposed Approach
Phase 4a: Agent-Side Edge Reliability (No Engine Changes)
Derive edge T-I-F from existing graph output. No engine changes, no new endpoints.
Edge reliability heuristic:
Deliverable:
examples/tif-graph-reliability/validate_tif_graph_reliability.pyPhase 4b: Path Reliability
For path A → B → C:
Hop penalty:
[0.00, 0.05, 0.12, 0.20]for depths 0–3.This ensures a path is no more reliable than its weakest link.
Phase 4c: Neighborhood Context (Contradiction Surfacing)
When
include_associated=truereturns neighbors with high falsity, surface them as contradiction evidence rather than hiding them. Expected behavior:Phase 4d (Future): Engine-Side Graph Reliability
If agent-side validation proves the model works, consider:
edge_reliabilityfield toGraphEdgeResponsepath_reliabilityfield inGraphPathResponseneighborhood_reliabilityinRecallResponse.associated_memoriesgraph_aware_classificationin recall resultsValidation Scenarios
related_toedge with weight 0.86 → node-only saysconfident_reuse, graph-aware saysverify_before_useverify_before_useNon-Goals
References
crates/engine/src/graph.rs(EdgeType, traverse, build_edges)crates/api/src/routes/memory.rs:4463–4546Suggested Build Order