How a Multi-Family Office Made Its Own Documents Answerable

The question a family office exists to answer

Strip away the sophistication and a family office does something simple: it knows what a family owns, what it has committed to, and what falls due. Every other service rests on that being reliably true.

In practice the answer was scattered. Accounting lived in one system, the paperwork that defines the commitments lived in a document drive, dates lived in a calendar, and the context for all of it lived in an inbox. Nothing was missing. It was simply that no one could see it at once.

So the answer to "what do we own through this entity" was not a lookup. It was an afternoon, and its accuracy depended on whoever last read the subscription agreement.

The number that causes the phone call

Of the questions a family office answers, the one that does damage is unfunded commitments — capital that has been legally committed to a fund or a deal but not yet called. It is not in the bank balance. It does not appear in a profit-and-loss statement. And it is drawn down on someone else's schedule.

An office that can see invested, committed, funded and unfunded in one place is managing liquidity. An office that has to assemble that view from subscription agreements when a call arrives is reacting to it. The same platform view that answers "what do we own" has to answer "what could be asked of us next quarter", or it has answered the easy half of the question.

Adjacent to it sits reconciliation: what the documents say a position is, against what the accounting says it is. Those two drift, quietly, and the drift is only ever found by someone comparing them. Making both readable by the same system is what turns that from an audit exercise into a view.

Why the paperwork is the hard part

The terms that actually govern a position are written in prose: a private placement memorandum, a subscription agreement, a SAFE, a cap table. They are the authoritative record, and they are unreadable at scale. A person extracting those terms by hand is slow and occasionally wrong, and neither failure announces itself.

So the documents are read automatically and turned into structured records. The effect is not that reading gets faster — it is that a term buried on page forty of a PDF becomes a fact the system can answer with, and can show its source for.

Those facts are then linked: this entity holds this position in this company, evidenced by this document. Ownership questions are rarely one hop deep, and a graph is what makes the second and third hop answerable instead of manual.

The constraint that shaped everything else

A platform serving several families has one absolute rule: one family's data must never reach another's, under any failure, ever. The comfortable way to guarantee that is to run a separate deployment per client.

It works, and it quietly caps the business. Every improvement ships as many times as you have clients, every client drifts onto a slightly different version, and the cost of serving the tenth family is the same as the first. The economics of software stop applying.

The alternative is to make isolation structural. Each organisation is bound only to the integrations it has actually connected — for that tenant, the others do not exist. All 70-plus endpoints sit behind that boundary, with more than sixty permission scopes across five roles. Cross-tenant access is not something the system detects and blocks; it is something the system has no route to.

Seven specialists, one question

Underneath, different questions need different competence — financial, legal, document, calendar, correspondence. Exposing that as five tools would push the work back onto the user, who now has to know which one to ask. A router in front of the specialists means a person asks their question and the system decides who answers it.

What transfers

If you are building software for an industry where each client's data is confidential from every other client's, you will be offered the per-client deployment early, and it will look like the responsible choice. It is worth understanding what it costs before you accept it — not in infrastructure, but in the rate at which you can improve the product for anyone.

The second lesson is about documents. In finance, law and insurance the authoritative record is prose, and most platforms treat it as an attachment — something to store and link to. Everything interesting starts when the contents of that prose become facts the system can reason over, with the document still attached as evidence.