Private markets have always been relational. What's changing is that the systems around them now need those relationships as data, not buried in documents and separate registers.
Your operation holds a lot of data and it also holds a lot of relationships.
Who controls an investor. Which entity owns a position. What rights attach to it. Which event changes those rights. Who else is affected when one of them moves. All of that is relationships and data.
However, most operational questions aren't lookups - but they are relationship questions.
And the relationships they depend on are usually stored indirectly: some in the application forms, some in the register, some in the administrator's records, some in the CRM. Answer the question, and you've usually had to rebuild the relationship first.
This piece is about that shift. And about one technique, the knowledge graph, that's making connected information practical to hold and query. The graph is the mechanism. The change needing to be understood is that relationships are becoming operational data in their own right.
What Is A Knowledge Graph?
A knowledge graph holds two things: entities, and the relationships between them.
An entity is something: an investor, a trust, a fund, a position, an entitlement, a capital call.
A relationship is the link between two of them: controls, holds, is entitled to, triggers.
A knowledge graph is a way of modelling information around entities and their relationships. It can sit over the systems you already run, or form part of an operational data model, and doesn't have to be a separate graph database.
A relational database can model these relationships through keys and joins. What a graph changes is emphasis. In a conventional store, the relationship is inferred at query time, usually by logic someone writes and maintains. In a graph, the relationship is a first-class fact: stored with its own type, alongside the things it connects, and available to systems that need to query it.
That's what makes a question traversable.
"What is this investor entitled to?" can be followed as a path: from the investor, to the structures they control, to the positions those structures hold, to the entitlements attached.
Why Private Markets Are Unusually Relational
The structures the industry runs on are relational by construction:
- An individual controls a trust.
- A trust and an SMSF hold units in a fund.
- A unit class carries an entitlement.
- A distribution triggers that entitlement.
- A transfer changes eligibility for some parties and leaves others untouched.
An adviser sits across many of these at once.
Beneficial ownership is the clearest case, and it's getting more formal. In October 2025 the Australian Government confirmed it intends to establish a Commonwealth-operated beneficial ownership register for unlisted companies, with work on a corresponding trusts regime continuing and detailed policy still in development (Treasury, October 2025).
Beneficial ownership is a relationship by definition: who controls whom, through which structure. Holding that explicitly, and keeping it current, is getting harder to do with documents and separate registers. The same relational shape runs through the register itself, which we looked at in "The End of Manual Registers?".
A Graph Doesn't Establish Authority
Knowing how things connect is only one part of the problem. There are three other parts that are equally important: authority, currency and evidence.
Authority. A graph can show that your register and your administrator disagree about a holding. It can't tell you which one is allowed to be right. That's assigned domain by domain, and we set it out in "Building a Single Source of Truth".
Currency. Is the relationship current, or a picture of last quarter? A graph derived from other systems inherits their lag.
Evidence. Can the relationship be traced back to the record that established it? That's what lets an auditor or an LP rely on it. We made that case in "Why Every Workflow Should Produce Evidence".
Put those together and you get: a relationship becomes dependable to the degree its authority, currency and provenance are governed.
Representing it explicitly, instead of rebuilding it each time a question crosses systems, is the operational gain. Governing it is what makes the gain safe to act on. Without those three, connected data can make an incorrect answer easier to produce, not easier to detect.
What This Means In The Context of AI, APIs and Tokenisation
Why now? Because of a pattern across several technologies, not just any one of them on their own individual merits.
APIs, tokenisation and AI all consume operational state directly. Each one inherits the quality of the state it reads.
And the questions being put to machines are increasingly relationship questions.
Ask an agent "which investors need to be notified about this distribution," and the answer runs through a chain: distribution, fund, class, holdings, entities, notification obligations.
Ask "what changes if this entity transfers its position," and it runs through: holder, structure, position, eligibility, transfer restrictions, affected parties, downstream obligations.
Same shape both times: the answer is a path, not a field.
Point a model at scattered records and it inherits the reconstruction. Point it at explicit, governed relationships and it has something it can traverse. The wider version of this is in "Before AI Acts, Your Fund Needs a Governed Operating State".
Graph-based representation is one industry response to that pattern. Gartner listed GraphRAG, the combination of knowledge graphs and large language models, among its 2026 data and analytics trends, predicting that 40% of enterprises will have used the technique by 2029 (Gartner, 2026). Treat that as a directional prediction. The underlying signal is more useful: giving machines the context carried by relationships is becoming a mainstream data concern.
Where Tranche:source Fits In
Tranche:source is authoritative for one domain: ownership and entitlement. The administrator may be authoritative for accounts and NAV. The bank may be authoritative for cash. The valuation process establishes valuations, and the governing documents establish terms.
What Tranche:source holds is a governed, relational record of who holds which position, in what structure, with which rights, and the transactions that change that state over time, exposed so other systems can read and act on it. Everything else stays where it already sits.
Inside that domain, the relationships are treated as data, rather than left implied between records. Tranche:route carries that state through the operation and orchestrates the work that acts on it, across the systems you already run.
That extends the point from "The Modern Fund Is Becoming Data Native": facts are more useful when they carry their meaning at the point they're created. So are the relationships between them.
What To Check Before Reaching for Graph Tech
If you're a tech lead or COO weighing whether connected representation would help, a few questions tend to sort the relationships worth modelling from the incidental ones:
- Which relationships does your team rebuild repeatedly to answer routine questions?
- Which of those materially affect ownership, entitlement or obligations?
- Where is each one sourced, and which system is authoritative for it?
- How does a change reach the parties it affects?
- Can another system read the relationship without rebuilding it?
- Can it be traced back to the evidence that established it?
The relationships that are repeatedly rebuilt, materially affect operations and can't be reliably queried are the strongest candidates for explicit, governed representation.
Private markets already contain the relationships that matter. They're represented indirectly, across documents, registers and separate systems, which is why answering a relationship question means rebuilding it first. Make those relationships explicit and governed, and ownership and entitlement state becomes something other systems can query, act on and rely on.
That is where a knowledge graph is most powerful: relationships become data in their own right, typed, current, traceable, and usable by the systems that act on them.
