ProductContext Graph
A graph of how your company actually works — not a pile of passages.
Trail parses your source material into a graph with named edges: which policy governs which account, which SOP owns which exception, which record proves which number. Agents traverse that structure instead of guessing from retrieved text, and every node points back to the document it came from.
SYSTEM — CONTEXT PASTED INTO THE PROMPT Collections policy (v4, extract): 1. France-based distributors are on net-60 terms. 2. Dunning begins at 90 days past due. 3. Legal hold requires AR lead approval. 4. Accounts on an active payment plan are exempt. 5. Parent accounts inherit the strictest term. Open items (pasted from the ERP export): INV-88412 €120,400 112 days ACME FR INV-88530 €64,900 96 days ACME FR / ship-to 2 INV-88604 €54,700 91 days ACME DISTRIB. FR INV-88771 €18,200 34 days ACME FR / ship-to 4 Correspondence: 14 Mar — "we'll clear both invoices by month end" 02 May — "payment run moved, sorry — next week" 19 May — call: promised again, no date given Question: how do we proceed with this account?
Parses the sources you already have
Parsed into structure, not flattened into vectors.
The graph is built by reading your source material the way a person would — finding the entities, the relationships between them, and the sentence that establishes each one.
- 01
Parse the source material
Contracts, decks, PDFs, tickets, threads and system records are read structurally. Clauses, thresholds, owners and exceptions come out as things the graph can hold, rather than as chunks of text with a similarity score.
- 02
Resolve the entities
The same customer named four ways across four systems becomes one node. Accounts, parents and ship-tos, plans, plants, payers and suppliers are reconciled, so a question about one of them reaches everything the company knows about it.
- 03
Keep the citation attached
Every node and edge carries the document, page and text it was drawn from. Provenance is part of the structure, not a lookup performed afterwards.
What the graph holds
One decision usually needs all five kinds at once — and no single system holds them.
These are the five kinds of context Trail resolves and connects. A real question — a credit decision, a denial, a deduction — normally touches every one of them, which is why answers assembled from a single source keep coming out subtly wrong.
Policy context
Documents & decks · What do the rules say?
Clauses, thresholds and the approvals they require
System-of-record context
ERP & CRM · Which entity is this, exactly?
Accounts, parents, plans and their real identifiers
Computed context
Calculated at question time · What do the numbers say right now?
Exposure, ages, variances and coverage from your records
Conversation context
Email, threads & call logs · What was said, promised or amended?
Commitments and written exceptions, with who made them
SOP context
Playbooks & procedures · What happens next, and who owns it?
The step, the tool it needs and the approver
A named edge, drawn from a sentence.
The graph's value is that its relationships are explicit and checkable. Here is a clause, and the edge Trail proposes from it.
…distributors domiciled in France are subject to net-60 payment terms, with dunning commencing at ninety days past due…
Policy “net-60 terms, dunning at 90 days” applies_to → distributors, region: France · cited to §2.
- Named edges, not similarity scores
- Entity resolution across systems
- Citations to document, page and line
- Re-parse on source change
- Role-scoped reads
- MCP, REST & GraphQL access
Parse-don't-embed isn't a claim you have to take on trust. Graft, our open-source context layer, applies the same mechanism to code: tree-sitter AST parsing across 20+ languages into a dependency graph with typed relationships, running entirely locally. It's the one place the mechanism can be checked line by line. Graft — open source ↗
Consumed by the agent your team already runs.
Trail isn't a destination app. Point Claude, ChatGPT, Copilot or your own stack at one Trail brain through a native Model Context Protocol server, native retrievers, or plain REST and GraphQL.
Security built in, not bolted on.
Your data and your company brain never leave your boundary. Independently audited every year, with compliance controls enforced by the platform — not promised on a page.
The graph can be built and served entirely inside your own boundary — managed, single-tenant, or in your VPC with storage pinned to a region.
SOC 2 Type IIOngoing security controls
GDPREU data protection
ISO 27001Global ISMS standard
HIPAABAA on enterprise plansContext Graph questions.
How is this different from vector search or RAG?
Retrieval finds passages that look similar to a question and leaves the reasoning to the model. A graph states relationships explicitly — this policy governs that account, this record proves that figure — so the agent follows structure your team can inspect instead of inferring it from nearby text.
What happens when a source document changes?
Trail re-parses it and re-proposes the nodes and rules it affects for review. Earlier versions are retained, so a decision made last quarter stays explainable against the document that was live then.
Can we query the graph directly?
Yes — through the native Model Context Protocol server, retrievers for LangChain and LlamaIndex, or plain REST and GraphQL APIs.
Does Trail need to store our documents?
It needs to read them. Where the graph and its sources live is your choice: managed, single-tenant, or fully inside your own VPC, with storage and processing pinnable to a region.
See it built on your own context,
with your agents.
Bring one policy document and one real decision. We'll show you what Trail parses out of it, and where each piece came from.
Looking for your team's use case? See all solutions →