Context GraphHow it works
Sources, and cited rules, so your agents stop guessing, and don't make the same mistake twice.
Trail parses the material your company already produced into entities and named edges, stores your rules on that structure, walks it when an agent asks a question, and returns only the rules that govern the case — each cited, each scored. What a person corrects afterwards goes back in through review, and anything that contradicts a rule you already approved is flagged rather than quietly overwritten.
Phase one · Build
Everything your team already wrote, read as structure.
The graph isn't authored. It's parsed out of the material your company produced while doing the work — and each piece keeps the document, page and line it came from.
- 01
Take in every source
Connectors read the systems the context already lives in — Notion and Drive, Slack threads and Gmail, SAP and Salesforce records, Snowflake tables, Jira and Zendesk — alongside the PDFs and decks somebody emails you. Nothing is chunked and embedded on the way in; each source arrives whole, with its structure intact.
- 02
Find the individual entities
Every thing a decision can be about becomes a node: an account, a parent, a ship-to, a plan, a plant, a payer, a supplier, a clause, a threshold, an approver, a step of a procedure. The same customer named four ways across four systems resolves to one node, so a question about it reaches everything the company knows.
- 03
Work out the relationships, and name them
Between those nodes Trail derives the relationships and types them as edges — child_of, governed_by, supersedes, exempt_when, approved_by, proves. An edge is a stated claim with the sentence it was drawn from attached, which means your team can read it, argue with it and correct it. A similarity score is none of those things.
- 04
Store the rules on the graph
A rule doesn't sit in a prompt library. It's stored as a node wired into what it governs — the entities, the SOP step it belongs to, the approver who signed it, the clause it came from — so the rule and its scope travel together. Your team approves it before any agent can reach it.
Phase two · Serve
An agent asks. Trail walks the graph and answers with its reasoning shown.
Questions arrive over the native MCP server, a LangChain or LlamaIndex retriever, or plain REST and GraphQL. What comes back is a short, ordered set of rules — each cited, each scored — not the graph and not a page of retrieved text.
- 05
Traverse from the entity, not from the wording
The question is resolved to its entry nodes — this account, this invoice, this payer — and Trail walks outward along named edges: up to the parent, across to the policy that governs it, down to the exceptions that policy carries. It follows structure rather than looking for text that reads like the question.
- 06
Collect the relevant nodes, edges and rules
Traversal stops where the edges stop bearing on the question. What it returns is a connected subgraph — the nodes, the edges between them and the rules hanging off them — so the rules arrive with the reason they apply, not as a ranked list of unrelated passages.
- 07
Decide which of them actually govern this case
Trail weighs each candidate on how tightly its scope fits the case, how far the traversal had to travel to reach it, whether it is approved and how recent its source is, and whether anything else in the graph corroborates or contradicts it. Each surviving rule carries a confidence and the reason it ranked where it did.
- 08
Return only what governs — with the confidence attached
The agent gets the rules that decide the case, each with its citation and its score, and a count of what was considered and left out. Where confidence is low, Trail says so and names what's missing — an unapproved exception, a stale source — instead of filling the gap with something plausible.
- 09
The agent does the job
Inside Claude, ChatGPT, Copilot or your own stack. Trail isn't where the work happens; it's what the agent consulted, and the citations ride along into whatever the agent produces so a reviewer can check the answer against the clause.
What step 07 weighs, when more than one rule could apply
Scope fit
A rule scoped to this account, region or plan outranks the general default it sits under.
Path distance
How many named edges the traversal crossed to reach the rule from the entity in question.
Standing
Approved beats proposed; a current source beats one that a later document superseded.
Corroboration
Whether other nodes support the rule — or contradict it, in which case it is flagged, not averaged.
“Acme FR is 112 days past due on €120,400 across four invoices. Do we place a legal hold?”
The traversal- 01entryAcme FR · ship-to 2resolved from the invoice
- 02child_ofAcme Distribution SAthe parent account
- 03governed_byCollections policy v4 · §2region: France
- 04contains_ruleLegal hold at 90 days past dueapproved 11 Mar
- 05exempt_whenPayment plan · none activeexemption doesn't apply
- 06approved_byAR leadthe step needs a person
14 nodes reached · 6 rules considered · 2 dropped as out of scope (region DE, US) · 1 superseded
Dunning escalates to a legal hold at 90 days past due.
0.94Collections policy v4 · §2
Scope matches the parent account and its region; two hops from the entity; approved and current.
A parent account inherits the strictest term across its ship-tos.
0.91Terms · §7
Reached through child_of; decides which of the four open invoices count toward the threshold.
A legal hold is placed only with AR lead approval.
0.88Collections SOP · p.15
Attached to the SOP step the action belongs to; names the approver the agent must stop for.
An emailed extension may have been granted on 14 March.
0.42Email thread · unapprovedBelow threshold
One uncorroborated source and no approved rule covers it. Returned flagged, below the threshold — the gap is reported, not filled.
Phase three · Learn
What a person corrects goes back into the graph — through review.
This is the half that makes the graph worth keeping. An agent that is corrected and forgets is a demo; the correction has to land somewhere the next agent will read it.
- 10
Feedback comes back with the run attached
When a reviewer edits the answer, rejects a step or overrides a rule, the agent sends that back to Trail together with the run it belongs to: which rules were read, which one was applied, what the person changed and where they were when they changed it.
- 11
It becomes a proposal, and a person makes it a rule
Trail turns the correction into a proposed change — a new rule, a tightened scope, an edge that was wrong — shown next to the run that prompted it. Your team approves, edits or rejects. Approved, it joins the graph and every connected agent reads it from the next question on; scoring shifts too, because paths that keep producing corrections carry less weight. Nothing an agent reports changes what other agents see until someone signs it off.
- 12
Anything that contradicts an approved rule is flagged
If the proposal answers the same case differently from a rule you already approved, Trail flags the conflict and shows both with their sources rather than letting the newer one quietly win. Most turn out to be scope — two rules governing different regions or account types — and the rest are a decision your team records. The rule that loses is versioned, not deleted, so a decision made last quarter still replays against what was live then.
Dunning escalates to a legal hold at 90 days past due.
Collections policy v4 · §2
For distributors on an active payment plan, hold at 120 days.
AR lead override · run log
Trail doesn't pick. Both rules stay visible with their sources, the approved one keeps governing until someone decides, and the decision is recorded against whoever made it. In practice most conflicts like this one resolve as scope — the two rules govern different account types, and both end up in the graph with their scopes tightened.
An answer is only useful if it can be checked.
Every response the graph returns carries the same things, whether it was read by Claude, by ChatGPT, or by a service of your own over REST.
- The rules that govern, in rank order
- A citation to document, page and line
- A confidence on every rule returned
- The traversal that found it
- What was considered and left out
- Conflicts flagged, never resolved silently
- Role-scoped reads, fully audited
The loop runs entirely inside your boundary — managed, single-tenant, or in your own VPC with storage and processing pinned to a region. Reads are role-scoped for agents exactly as they are for people, and every read, proposal and approval is logged, so what an agent applied on a given day can be reconstructed. What the graph holds →
Questions about the mechanism.
Is this retrieval with extra steps?
No. Retrieval scores passages against the wording of a question and hands the model whatever came back. Trail resolves the question to entities and walks named edges from them, so the rules arrive with the reason they apply — and the same question about a different account traverses a different part of the graph rather than matching similar-sounding text.
How long does it take to answer?
A traversal is a graph walk over a bounded neighbourhood, not a scan of your corpus, so the work is proportional to how connected the question is rather than to how much material you have. We'd rather show you it on your own graph than publish a number here.
What does the confidence score actually mean?
It's a per-question judgement about how well the graph supports that rule for that case — scope fit, path distance, approval and recency, and whether anything corroborates or contradicts it. It is not a published accuracy figure, and your team sets the threshold below which an agent must stop and ask rather than proceed.
Can an agent write to the graph?
It can report. It cannot approve. Feedback from a run arrives as a proposed change with the run attached, and a person on your team approves, edits or rejects it before any other agent can read it.
What happens to the old rule when a conflict is resolved?
It's versioned, not deleted. Both rules stay visible with their sources while the conflict is open, and once your team decides, the superseded version is retained — so a decision made against last quarter's rule can still be explained against the rule that was live at the time.
What if a source document changes?
Trail re-parses it and re-proposes the nodes, edges and rules it affects for review. The graph moves when your source material moves, through the same approval gate as everything else.
Run the loop once
on your own material.
Bring one policy document and one real decision. We'll show you the entities and edges Trail parses out of it, the traversal a question causes, and the citation behind every rule that comes back.
Prefer the shorter version? Read the Context Graph overview →