Graph and Structured Retrieval

A project overview mentions a contact entity, so the graph can draw a mentions edge between them. But the request asks for the project’s registered contact through its operating organisation. A path that jumps directly from the project to the mentioned name looks connected while omitting the relationship the question requires. In this case, connectivity is not sufficient evidence.

A second request exposes a different failure. Retrieval finds both positive assignment statements, but another current source contradicts the assignment. Hierarchical and Parent-Child Retrieval can select the positive source bundle; that establishes that the required text survived selection, not that the proposed relationship is acceptable in the presence of conflicting evidence.

Both cases turn a visually convincing path into a stricter engineering question: what must we verify about each edge, and about the path as a whole, before we expose it as retrieval evidence?

Start with an evidence graph, not a diagram of associations

The graph begins with entities identified by exact canonical IDs, not by display names. Two organisations called Rowan remain different nodes. Each relation edge records a subject, predicate, object, edge identity and supporting source anchor. That anchor carries the source, document, version, representation, body digest, raw span and expected quote. The graph can therefore say both which relationship is proposed and where its evidence can be checked.

For the contact need, traversal requests this explicit sequence:

project --operated_by--> organisation --contact--> contact entity

A returned edge is accepted only when its declared triple matches a literal clause in an eligible current source version. A wrong organisation cannot inherit a genuine quotation about another bridge; a missing or inconsistent support digest invalidates the record. The clause is checked as source data, not executed as an instruction. It cannot change the requested predicate sequence or enlarge the caller’s permissions.

The executable grammar is deliberately narrow: operated_by, contact, mentions and an opposing not_operated_by relation are among the declared predicates. Each fictional world supplies nine authored relation records whose supporting clauses already contain canonical entity IDs. Chapter 18’s multi-hop retriever consumes the same records, including invalid controls. The graph is constructed from this supplied catalogue; it is not extracted from unfamiliar prose.

The diagram shows the whole catalogue rather than only the accepted path. Solid edges are supported clauses; the marked control nodes carry the wrong bridge, the missing support and the mention-only shortcut, and each refusal has a different reason.

    %%{init: {"flowchart": {"wrappingWidth": 330}}}%%
flowchart TD
    MAIN["project:final:main (PR-84)"] -->|"operated_by · v1"| NORTH["org:final:north (Rowan)"]
    NORTH -->|"contact · v1"| DESK["contact:final:desk (Cedar)"]
    MAIN -->|"operated_by · v2, revised view"| SOUTH["org:final:south (Rowan)"]
    SOUTH -->|"contact · v1"| OTHER["contact:final:other"]
    MAIN -.->|"not_operated_by · current opposing assignment"| NORTH
    SHORT["project:final:shortcut (PR-89)"] -.->|"mentions only"| DESK
    DESK -.->|"contact · cycle control"| MAIN
    GHOST["project:final:ghost (PR-88)"] -.->|"operated_by · wrong bridge"| SOUTH
    GHOST -.->|"contact · missing support"| DESK
    classDef refused stroke:#b3261e,stroke-dasharray:5 4,fill:#fbe9e7;
    class SHORT,GHOST refused;
  

The two Rowan nodes are deliberately separate: a display name reaches both, and only canonical identifiers distinguish them. The marked control nodes carry the wrong bridge, the missing support and the mention-only shortcut; the cycle edge and the opposing assignment are refused by traversal rules rather than by their own evidence.

What we execute is therefore bounded traversal of declared relationships, retrieval of their supporting clauses and verification of current eligibility. Extracting unknown relations and constructing an independent graph are not measured. The previous chapter’s containment links form a separate, mechanically verified kind of structure; containment alone does not assert an operated_by or contact relation.

Do not promote weak relations into stronger ones

A mentions edge can be useful for finding material about an organisation, but it cannot answer a request for the organisation’s registered contact. Co-occurring names establish neither entity identity nor an assignment. Likewise, a citation edge in some other graph would show that a source references another source, not that it endorses its claims. Every predicate needs its own meaning and supporting evidence before it can satisfy a query obligation.

Even a path built entirely from allowed edges must be interpreted according to its requested pattern. Here project --operated_by--> organisation --contact--> contact entity permits one specific two-step lookup. It does not create an arbitrary new transitive relation, make contact transitive, or make every reachable node a valid answer. Path validity depends on matching the required predicates in order, not merely reaching a connected node.

The inspected Graph RAG preprint by Edge and colleagues examines a substantially different pipeline: language-model extraction of entities and relationships, community summaries and query-focused global summarisation. It is useful background for asking what a graph represents, but none of those extraction, clustering or generated-summary stages runs here. We transfer neither its quality findings nor its cost figures to this literal-clause graph.

Literal source backing lets us inspect whether the source says what the edge claims it says. It cannot establish that the source is authoritative or factually correct. A current document may contain a false assertion; a perfectly reconstructed edge would still reflect that assertion. Provenance makes a claim traceable, not automatically true.

Traverse a bounded, reconstructible path

HippoRAG illustrates another graph-based discovery mechanism: it links query entities, propagates personalised PageRank probability and aggregates node weights over passages. That can surface associated evidence without enforcing our explicit operated_by-then-contact sequence. A high propagation score is not a probability that a statement is true, current or authoritative. HippoRAG-style retrieval might propose material for later checking; it would not replace the typed, source-backed path validator. We execute neither PageRank nor HippoRAG extraction in this chapter.

Execution starts by resolving one canonical entity from the public catalogue; a display name that resolves ambiguously remains unresolved. For each required predicate, the algorithm considers currently eligible, source-backed edges, sorts them by edge identity and takes the first valid continuation. The trace retains that edge, its supporting evidence and the remaining budget. This is deterministic traversal of an asserted relation, not a semantic guess about the next entity.

The default request has a hard boundary: two predicate steps, two logical adjacency calls and at most six returned edge rows. It rejects revisiting an entity. A separate hand-controlled longer-path test demonstrates cycle rejection, but the default two-hop route does not turn into open-ended graph exploration. Its boundedness is part of the retrieval contract, not a property supplied by graph connectivity.

The traversal is greedy: once it chooses the first eligible supported edge, it does not backtrack through all other branches if a later hop fails. That can miss a complete path in another collection even when one exists. We must distinguish three questions: whether the catalogue contains enough edges, whether this search procedure finds the right path, and whether the supporting sources are correct. The small successful fixture settles none of those questions generally.

Before exposing a result, public projection checks the entire selected path against the trusted current view. If a supporting version is revoked, an edge loses its valid source unit or a current opposing assignment invalidates the path, the complete path is withheld. Public packets and traces do not reveal protected intermediate text, excluded identifiers or denial counts. The caller still supplies the trusted policy view; authentication and live production-policy discovery remain outside the demonstration.

Compare evidence paths with evidence rankings

In the final constructed relation requests, both graph traversal and lexical multi-hop retrieval recover all three accepted positive-path requests. Two requests use the same main assignment and the third uses its revised assignment. They represent only two distinct accepted paths. Counting request successes is appropriate for the declared metric; counting them as three independent confirmations of the relationship would not be.

Both mechanisms also return zero unsupported complete paths across seven deliberately constructed no-path challenges. The matching 3/3 positive-path and 0/7 no-path counts rely on the same nine-record catalogue and same-author evidence design. They show that both implementations honour these particular constraints; they do not provide independent experimental confirmation. The failure cases explain why apparently connected evidence is rejected:

Separate development controls exercise removed records, cycles, missing support and later-view projection. Passing them provides evidence that the code follows its declared validation rules on those fixtures. It is not a test of authentication, adversarial access-control bypasses or deployment security.

For the main request, graph traversal and lexical multi-hop ultimately select the same two supporting clauses: two exact source references occupying 106 characters. Each uses two logical retrieval calls. The lexical route returns six ranked passage rows, while the graph route returns two edge rows. Those row counts are not equivalent measures of work: they describe different operations, and the graph has its own construction, validation and maintenance costs.

Averaged over all twenty final requests, either specialised mechanism selects only 15.95 characters and uses .7 logical calls, largely because unrelated and unsupported requests return nothing. Those small means do not indicate broadly efficient or effective retrieval. On the three accepted relation requests, path recovery is 3/3; across all sixteen non-empty target bundles, overall structural coverage is only 3/16. The practical lesson is to route a request to this capability when its relation pattern fits, not apply it to every information need.

Coverage can succeed while a relationship remains unacceptable

The conflicting-chain request exposes the limit of structural coverage. Section retrieval and parent expansion can select both positive target anchors, meeting the declared source-bundle criterion. But the catalogue also contains a current opposing assignment, so graph traversal returns no accepted complete path. Both the graph and multi-hop conflict checks can inspect the eligible declared catalogue, including relation support outside the rows retrieved by lexical search. That is a stronger catalogue-backed validity test, not evidence that open-ended search would discover every contradiction.

The two results answer different questions. Structural bundle coverage says the positive source material was selected. Path validation says the relationship remains unacceptable under the fixture’s explicit conflict rule. A reader or consumer could benefit from seeing both facts, but this experiment does not measure whether a downstream model would explain or resolve the disagreement correctly.

One reporting limitation remains. After current-view projection, a public packet may still contain individually eligible clauses while no validated relationship path survives. The present public status does not always express that distinction. Chapter 21 needs to clarify stopping and insufficiency without exposing the existence or identity of any restricted relation or source. We do not add a new public status field or claim that this issue is already resolved here.

Revision illustrates the other side of the boundary. The historical project assignment still exists in retained records, but the current graph must follow the newer source version to a different organisation and contact. It preserves the old evidence as history; it neither treats the old bridge as current nor collapses the two organisations because their display names happen to match.

Carry a defensible path to the next boundary

Across these five chapters, each additional mechanism has introduced a different, checkable obligation. Routing chooses a capability; rewriting changes the search expression; multi-hop retrieval demands a supported bridge; parent expansion restores exact containing context; typed graph traversal demands the requested relation sequence. Each can help locate evidence, but each also has its own opportunities to lose identity, spend budget or overstate what a connection means.

Every local comparison in this part belongs to the same-author mirrored replication described in Understanding Queries and Routing. We have not measured generalisation to independently judged or unseen content, real-world relationship extraction, generated-answer correctness, admission, use or helpfulness. In particular, a connected graph is not necessarily a valid typed path, and a validated source-backed path is not yet a successful answer.

Bounded Adaptive Retrieval: When to Stop addresses a narrower next decision: when should observed evidence trigger one more predetermined text search, and when should retrieval stop? It introduces explicit budgets, stop rules and a fresh external comparison while preserving the current-view boundary. The implemented text path is lexical search followed, only when needed, by one dense search using the unchanged query. A failed graph path neither authorises unlimited searching nor turns retrieved assertions into instructions.

Capstone checkpoint: one implemented structural extension

python -B -m examples.capstone.milestones 4 --summary

This capstone milestone demonstrates a structural capability, not the typed graph itself. The facade runs child-first lexical search and expands exact child references into containing sections. Its summary compares the maintenance-mode order with flat blocks, identifies the first child-to-parent expansion and reports charged rows and returned text length. The full origins and references remain in .artifacts/capstone/runtime/milestones/04.json; omitting --summary preserves the original JSON status. Backend child rows remain charged even if several resolve to the same parent. No typed-graph or multi-hop validator is integrated into the facade, and no relationship extraction or planning model runs. Two related capstone passages must not be reported as a validated relation path.

References and further reading

Background and extensions for this chapter:

• Edge et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv preprint, v1. Extends graph retrieval to community summaries for global questions.
• Jiménez Gutiérrez et al. (2024). HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. arXiv preprint, v1. Explores associative retrieval through a knowledge graph and personalised PageRank.
• Buneman, Khanna and Tan (2001). Why and Where: A Characterization of Data Provenance. ICDT. Provides provenance background for tracing derived relationships to their contributing data.

Related chapters

• Pathways Through Memory. Continues graph navigation into associative recall while keeping memory responsibilities separate.