Which Connected Records Can the Assistant Use?

The assistant has found P7, but its own manual does not explain a supply fault. Botie could follow P7’s dependency to S1 and retrieve the supply’s manual too. That connected context might explain what the isolated document misses.

There are limits. One route passes through another tenant’s asset, and one manual was uploaded after the decision we are evaluating. Relevance alone does not make either route acceptable. We need an explicit retrieval policy before handing records to a model.

Future documents and routes through another tenant must not enter the context.

The request concerns P7. Entity resolution must connect that mention to a stable permitted asset, rather than treating a similar display name as sufficient. Vector search can suggest candidates, but an approximate similarity score does not establish identity or access.

For this lesson the starting ID is already supplied. We also receive the tenant, decision hour and maximum dependency depth. Those inputs define the retrieval question; the model does not get to silently widen them.

A known start keeps this exercise focused on connected evidence rather than language-based entity resolution.

Construct the permitted graph before expanding. Keep nodes in the requested tenant and only relationships whose endpoints both remain. This prevents a route through an excluded asset from revealing an otherwise permitted endpoint.

Real policies can also restrict relationship types, individual records or properties within a tenant. The browser receives invented multi-tenant fixtures so we can see the failure. In a deployed system, enforce the policy on the server before forbidden records are exposed to the client or model.

A traversal depth limit controls work. It does not grant permission.

Require the start and every intermediate dependency node to have kind Asset. Starting at P7, follow DEPENDS_ON up to the chosen depth and retain each reached asset once. Include P7 at depth zero so its own manual remains eligible. Then follow HAS_MANUAL from those assets to document records.

This separation prevents a general “follow every edge” search from wandering through technicians, unrelated claims or other relationship types. Inspect the reached asset IDs before inspecting document content.

Each stage has a different row meaning: assets reached, document IDs attached, then eligible evidence.

g={"nodes": [{"id": "P7", "kind": "Asset", "tenant": "red"}, {"id": "S1", "kind": "Asset", "tenant": "red"}, {"id": "X", "kind": "Asset", "tenant": "blue"}, {"id": "D1", "kind": "Document", "tenant": "red", "available_at": 2}, {"id": "D2", "kind": "Document", "tenant": "red", "available_at": 8}, {"id": "D3", "kind": "Document", "tenant": "red", "available_at": 1}], "edges": [{"id": "d", "source": "P7", "target": "S1", "type": "DEPENDS_ON"}, {"id": "cross", "source": "P7", "target": "X", "type": "DEPENDS_ON"}, {"id": "m1", "source": "P7", "target": "D1", "type": "HAS_MANUAL"}, {"id": "m2", "source": "S1", "target": "D2", "type": "HAS_MANUAL"}, {"id": "m3", "source": "X", "target": "D3", "type": "HAS_MANUAL"}]}
allowed={n['id'] for n in g['nodes'] if n['tenant']=='red'}
print(sorted(e['id'] for e in g['edges'] if e['source'] in allowed and e['target'] in allowed))

['d', 'm1', 'm2']

The supply manual D2 becomes available at hour eight. It cannot support a response evaluated as of hour six. Check availability after resolving document records, and retain version information so a later revision does not leak backward into an old evaluation.

For training features, apply the same point-in-time discipline to graph edges and node properties. A future relationship can leak an outcome even when the final label column is absent. This exercise assumes the graph topology is the authorised snapshot for the decision and varies document availability only.

Real historical evaluation needs the graph snapshot and evidence versions that existed at the time.

The bounded path begins at the asset, permits zero dependency hops and then matches a manual. all over nodes(p) checks the tenant of every asset along that path. The document has its own tenant and availability predicates.

These query conditions illustrate the policy. A server must derive the permitted tenant from authenticated context and enforce its full access rules. Never accept an arbitrary user-selected tenant as authorisation.

The example fixes a two-hop query template and parameterises data values.

MATCH p=(a:Asset {id:$asset,tenant:$tenant})-[:DEPENDS_ON*0..2]->(x:Asset)
MATCH (x)-[:HAS_MANUAL]->(d:Document)
WHERE all(n IN nodes(p) WHERE n:Asset AND n.tenant=$tenant)
  AND d.tenant=$tenant AND d.available_at <= $at
RETURN DISTINCT d.id AS document
ORDER BY document

Return source IDs and relevant passages, rather than an unlabelled bundle of graph text. The answer should cite support for its claims and acknowledge missing or conflicting evidence. Documents can contain hostile instructions; retrieved content remains untrusted data rather than instructions to the application.

Bound expansion, document count and context size using documented policies. If a bound truncates potentially useful evidence, expose that limitation rather than claiming a complete search. A graph makes relationships available; it does not guarantee a factual model response.

Graph retrieval and graph neural network training are separate uses of graph data.

Use held-out maintenance questions with known supporting records. Check whether required evidence is retrieved, whether forbidden or future evidence is excluded and whether citations support the answer actually given. Include an unresolved question where the correct behaviour is to ask for more information.

Compare this retrieval policy with a simpler document search on the same questions. Measure latency and failure cases alongside answer quality. More connected context can add irrelevant material or repeated claims, so improvement needs evidence.

The workshop tests the evidence-selection mechanism. It makes no claim to evaluate a live language model.