What Is a Topic Graph?
The breadth layer. Continuously indexes code, repos, PRs, tickets, docs, owners. The substrate the Decision Graph sits on top of.
What a Topic Graph is
A Topic Graph is the substrate layer beneath Uvi's Reasoning Layer. It continuously indexes the customer's enterprise dataset across every connected source system (code, tickets, PRs, docs, Slack, monitoring), links documents to each other through explicit references (foreign keys, ticket IDs, PR numbers) and implicit references (Slack mentions, branch-name conventions), resolves identities across tools (one person maps to one node everywhere), and enforces document-level permissions on every node at retrieval time.
What it is not
A Topic Graph is not a vector database - it does not retrieve by semantic similarity. It is not a knowledge graph in the traditional entities-and-relationships sense - it does not require an ontology design before ingestion. It is not enterprise search - it does not return ranked document lists for human consumption. It is infrastructure for AI agents that need to traverse a connected corpus while respecting source-system permissions.
How the Topic Graph supports the Decision Graph
The Decision Graph (decisions as first-class nodes with owners, triggers, blockers) is built on top of the Topic Graph (the corpus, linked and ranked). Decisions reference evidence - a PR, a ticket, a Slack thread - and the Topic Graph is what makes those references retrievable. When an agent asks 'what's blocking checkout v2,' the Decision Graph returns the chain of decisions; the Topic Graph supplies the supporting evidence each decision points at. The two are different layers solving complementary problems.
Implicit-reference linking - the part RAG misses
Most decisions in an enterprise are joined by references no schema captures: a branch name that carries a ticket ID, a flag key hard-coded in a PR, a Slack thread that references both. RAG indexes each source independently and finds documents by content similarity; the implicit join between them is invisible. A Topic Graph reads these implicit references as first-class edges in the graph, so an agent traversing from 'this stack trace' can reach 'the PR that introduced the regression' and 'the Slack thread where the team debugged it' through their actual relationship - not through coincidental word overlap.
FAQ
Is a Topic Graph a knowledge graph?
Topologically yes - it's a graph of nodes (documents, entities, people) and edges (references between them). Architecturally it's different: a knowledge graph typically requires an ontology designed up-front by a data engineering team, while a Topic Graph bootstraps from the customer's tools without an ontology project. The Decision Graph layer adds the typed, decision-shaped semantics on top.
How is permission-aware retrieval enforced?
Source-system ACLs (GitHub teams, Jira projects, Slack channels, Confluence spaces, internal RBAC) are mirrored into the graph and checked at every traversal. Documents whose ACL excludes the requesting user are not retrievable for that user - not 'retrieved and then filtered out,' but never included in the candidate set. This is the architectural difference from RAG's typical post-retrieval permission filtering.
What's the ingestion cadence?
Continuous. Uvi connects via APIs, webhooks, and event streams - CDC where supported, polling at the right cadence elsewhere. New PRs, ticket updates, Slack messages flow into the graph in near-real-time. Stale-snapshot freshness (daily, weekly) is a non-starter for production AI agents.
Do customers need to model their data first?
No. The Topic Graph layer bootstraps from the customer's existing tools without a data-modeling project. The Decision Graph layer (the typed semantic overlay) is where the elicitation happens - typically 2-4 weeks via Forward Deployed Agent.
Go deeper
The full architecture and customer story live on the dedicated page.