Knowledge graphs in depth
A Knowledge Graph (AMPG) turns your documents into a structured graph that agents can draw on when they answer. This page follows one document through its full lifecycle — where it is uploaded, where it is processed, where the resulting graph lives, and how it is retrieved at query time — with a focus on what happens to your data and where it lives. It explains the retrieval model at a conceptual level but deliberately does not describe the proprietary mechanics of how the graph is built. The end-user workflow is covered in Knowledge Graphs (AMPG).
What this page does and does not cover
This is a data-residency and lifecycle reference. It tells you, for an audit, exactly where your document and its derived graph reside at each stage, and that nothing leaves your account. It also explains, at a conceptual level, how retrieval works, so you can understand and trust the answers an agent gives.
What it does not document is the proprietary mechanics of how the graph is built — the exact methods that read a document and turn it into entities and relationships are intellectual property and are intentionally out of scope here. What you can rely on is the conceptual model below, together with the residency and handling guarantees.
The lifecycle of your document
1. Upload — your S3
When you add a document to a Knowledge Graph, it is uploaded to an S3 bucket in your own AWS account. The original file resides there; it is not sent to Prometheus Research Labs.
2. Processing — in your account
Adding a document starts a build job that runs inside your account. Studio shows the job's progress as it moves through a series of visible stages, with live logs, so you can watch it advance and see when it completes or needs attention. All compute for this job runs in your account, and any model inference it uses runs on Amazon Bedrock pinned to your residency zone (see Data residency and security).
What happens inside those stages — how the document's content is analyzed and how the graph is assembled — is proprietary and not documented here. What matters for residency is that it all happens in your account and your zone.
3. Storage — your Neo4j
The resulting graph is stored in your self-hosted Neo4j, which lives in your account: Studio runs single-node Neo4j Community on Fargate inside your VPC, backed by encrypted multi-AZ EFS. The graph is not stored in any Prometheus Research Labs system. Because Neo4j is in your account, the graph's storage, backup, and access controls are under your control.
4. Retrieval — at query time, from your Neo4j
When an agent uses a Knowledge Graph to answer a question (this happens in Deep Traversal mode, where the graph is consulted first), it retrieves relevant context from your Neo4j at query time. The retrieval is bounded so that only a focused amount of graph content is brought into the answer, and the agent's response can cite what it drew on. As with everything else, retrieval and the inference that uses it stay in your account and your residency zone.
The conceptual model behind that retrieval is described in How retrieval works below; the exact ranking algorithms remain proprietary. What matters for residency is that the source of truth is your Neo4j and that nothing about the query or the graph leaves your account.
How retrieval works (conceptually)
A Knowledge Graph is more than a place to keep text — it is built to be searched by meaning. Two ideas make that work, and both are safe to describe even though the exact algorithms are proprietary.
Multiple levels of detail
Your document is represented at several levels of resolution at once — from the whole document, through its sections and passages, down to a single decisive phrase. Retrieval can start broad for context and then narrow to the precise piece of text that answers a question, rather than being locked to one fixed chunk size. This is what the "Multi-Resolution" in AMPG refers to, and it is why the Thought Map color-codes results by level of detail.
Recall, then relation-aware precision
Retrieval happens in two passes:
- Recall. A fast, meaning-based search gathers a wide set of candidate passages in one step. Because it matches on meaning rather than keywords, it still finds the right passage when the wording is a paraphrase, a synonym, or a misspelling — and even when an entity was never named the same way in the source.
- Precision. Those candidates are then re-ranked according to the specific relationship the question is about, so the passage that matters for this question rises to the top. A bounded walk over the graph's real connections adds structural context around the chosen passages.
The result is retrieval that finds meaning, not strings, and that can defend every answer by pointing at the passages it actually used.
Bounded and auditable
Retrieval is deliberately bounded: it works within an explicit budget, so a single answer cannot wander the whole graph or run up unbounded cost, and every step it takes is recorded. That record is what the Thought Map replays — an inspectable path through the graph, shown alongside the documents the answer cited. The retrieval layer only ever assembles context; it never authors the answer, and the source of truth remains your Neo4j.
Why a multi-resolution graph, not a strict ontology
A traditional knowledge graph relies on a hand-authored ontology — a fixed schema of entity types and relationship types defined up front. That is excellent for exact lookups when the question matches the schema, but it struggles in exactly the places regulated, document-heavy work lives:
- Paraphrase and synonym. A strict schema keys on exact terms, so it misses the disclosure that answers the question in different words.
- Out-of-vocabulary entities. It cannot reason about an entity, product, or counterparty that was never added to the schema.
- Overloaded relationships. One entity often plays many roles, and a fixed schema forces every role to be anticipated and modelled up front.
- Schema rot. Hand-authored ontologies need constant re-curation as the corpus grows, which turns the system into a services effort rather than a product.
AMPG keeps the deterministic, exact-match strengths of graph traversal where they win, and adds a learned, relationship-aware layer exactly where strict ontologies fail — with no schema to author or maintain. Add a new corpus and quality improves on re-ingestion; there is no hand-built schema to keep in sync.
One entity, many roles — a worked example
Consider a major bank inside a capital-markets knowledge base. It can be an underwriter on a bond issuance, a counterparty on a swap, a prime broker for hedge-fund clients, and a holder in its own asset-management funds — all at once.
A strict knowledge graph has to either split this into several disconnected entities (losing every cross-context insight) or model one entity with many relationship types that every query must then filter by — and the curator has to have anticipated each role in advance.
AMPG keeps a single node for the bank and reshapes how that node is scored for the relationship in play — underwriter versus counterparty versus prime broker — with no schema change. It even extends to roles that were never configured (say, advised on a transaction) when your documents mention them.
Where this earns its keep
This relationship-aware retrieval is built for regulated, document-heavy domains:
- Capital markets — a term like "exposure" means different things across a derivatives book (net mark-to-market, potential future exposure, notional); retrieval picks the sense from the relationship in play.
- Banking and KYC — finds the disclosure that answers a question even when it never uses the question's words, across messy filings.
- Insurance — heterogeneous policy and claims documents, where relationship-aware ranking cuts through noisy source material.
- Payments — generalizes to counterparties, products, and rails the corpus never named explicitly at the time it was ingested.
Where your data lives, stage by stage
| Stage | Where the data is | Whose system |
|---|---|---|
| Uploaded document | S3 uploads bucket | Your AWS account |
| Build job (processing) | Compute and intermediate artifacts | Your AWS account |
| Model inference during build | Amazon Bedrock, your residency zone | Your AWS account |
| Finished graph | Neo4j | Your account (self-hosted on EFS) |
| Query-time retrieval | Neo4j | Your account (self-hosted on EFS) |
Residency summary
- Your document never leaves your account.
- The graph is built in your account and stored in your Neo4j.
- All inference, during both build and query, runs on Amazon Bedrock in your chosen residency zone.
- Nothing about your documents, the derived graph, or your queries is transmitted to Prometheus Research Labs.
Where to go next
- Knowledge Graphs (AMPG) — building and managing knowledge graphs as an end user.
- Data residency and security — the account boundary and zone pinning that this lifecycle relies on.
- What runs in your account — where Neo4j and Bedrock sit in the overall picture.