The audit you never ordered, already ran

The short version

Last time I wrote about the lake — the place all of a studio's history finally lives together. This post is about the layer on top: the ontology, the map that tells the system what every record is and how it connects to everything else. Palantir and Databricks built enterprise empires on this idea. We've brought it to boutique fitness. The outcome isn't an architecture diagram — it's found money: fraud hiding in 0.01% of activity, an intro plan capped one visit short of the habit threshold, and data gaps that silently overstate revenue. And every one of those findings compounds when you run more than one location.

• A data lake gathers your studio's records into one place, but a pile of connected records finds nothing on its own. Meaning requires a map.
• An ontology is that map: a member is a person, a visit belongs to a member, draws on a plan, was paid for by a sale, taught by a teacher, at a location.
• Once every record has a place on the map, the map tells you what should exist — and that's when the money starts turning up.
• The anomalies that matter don't live in any single system. They live in the relationships between systems, which is exactly what an ontology holds.
• In a studio, leaked revenue comes straight off the profit line, because the class ran and the teacher was paid regardless. Small leaks hit profit hard.
• The benefit multiplies with locations: one map, applied everywhere, makes drift comparable across sites — one question instead of five audits.

In the last post I made the case for the lake: bring all of a studio's history into one connected place, the way enterprises do, and run it for operators who could never staff it. That post ended with the linking — every visit tied to the plan it drew on and the sale that paid for it.

This post is about what the linking is for. Because here's the uncomfortable truth about data lakes: on their own, they find nothing. A lake is a very well-organised pile. The layer that turns the pile into answers has a name the enterprise world uses and nobody else loves.

An ugly word for a simple idea

Ontology. It sounds like a philosophy seminar. It means something a studio owner already understands: an agreed map of what things are and how they relate.

In a fitness studio, the map reads like this. A member is a person. A visit belongs to a member. The visit draws on a plan. The plan was paid for by a sale. The class was taught by a teacher, at a location, in a room, at a time. Every record that lands in the lake gets a place on that map — not just stored, but understood.

If this sounds abstract, look at who's built businesses on it. Palantir's moat has never been its models — it's the ontology its engineers spend months building inside each enterprise customer, at seven-figure prices. Databricks spent 2026 proving the same point from the other direction: AI agents fail on context, not intelligence, and the context layer is the fix. Y Combinator went as far as naming the "Company Brain" a Request for Startups. The pattern is validated at the very top of the market.

It has simply never been available at the bottom — for the same reason the lake wasn't. It takes a team to build, per customer, and a boutique studio can't hire that team. Our answer was the vertical: every boutique fitness studio shares the same primitives, so we built the fitness ontology once, and every studio that connects gets it on day one.

So what does it actually do? Here's the key sentence of this whole post: once every record has a place on the map, the map tells you what should exist. A visit should have a plan behind it. A plan should have a sale behind it. A sale should match a price on the list. A refund table at a busy studio should have rows in it. When reality doesn't match the map, that mismatch is a finding — and findings, it turns out, are frequently money.

Three stories.

The fraud: 0.01% of activity, none of it visible

At a multi-location operator we work with, the map surfaced a member who kept becoming a new member. A fresh sign-up, a slightly different email address every time — and the same credit card underneath. To the booking platform, each sign-up was a brand-new person, entitled to a brand-new, heavily discounted intro pass. To the payment data, it was one person on a loop, paying the new-member price forever instead of ever becoming a member.

Neither system could catch it alone — and this is the detail worth sitting with. The booking platform saw a stream of legitimate new faces; every record was valid. The payment platform saw routine charges on an ordinary card; every transaction was clean. The pattern only exists when identity is resolved across the two — when the map insists that a person is a person, however many email addresses they wear, and the credit card becomes the thread that ties the masks together.

(It wasn't the only pattern, either. A second one involved gaming the grace period between payments — that one deserves, and will get, a post of its own.)

Call it 0.01% of activity. That sounds like nothing. Studio economics say otherwise. Revenue that should have arrived and didn't comes off the bottom line dollar for dollar, because every cost was already sunk — the class ran anyway, the teacher was paid anyway, the lights were on anyway. At typical studio margins, a fraction of a percent of revenue leakage translates to a multiple of that off profit. The 0.01% punches far above its weight.

Nobody ordered an audit. The data just finally knew what it was supposed to look like.

Relationships are exactly what an ontology holds. That's the whole trick.

The cap nobody changed back

The second finding wasn't fraud. Nobody did anything wrong — which is exactly what makes this the more expensive category.

The operator's intro plan — the discounted pass that gives a new member their first taste of the studio — had been capped at a maximum of five visits. There was a good reason at the time: classes were running at high utilisation, and gating intro visits protected capacity for paying members. Then more classes opened, utilisation eased, and the cap stayed. Settings don't announce themselves. Nobody changed it back, because nothing looked wrong.

Here's why it mattered. Behavioural analysis of more than a thousand intro buyers at this operator shows a clear habit threshold: the members who stay are the ones who get to six to ten visits in their first 28 days. Below that, the habit doesn't form and the conversion doesn't happen. The intro plan was capped at five — one visit short of the bottom of that range. The product designed to create members was configured to stop people just before the point where they become one.

No single system could see this either. The plan setting lived in the booking platform. The habit threshold lived in attendance behaviour. The cost lived in conversion outcomes. Three different places, one finding — and it only exists when plan configuration, visit behaviour and conversion sit on the same map. A revenue report shows the intro pass earning nicely. Only the map shows what it's quietly preventing.

The gaps that read as zero

The third category is my favourite, because it's invisible by definition.

At one studio processing six figures a month, we found the refund tables completely empty. Not because there were no refunds — a business at that volume certainly issues some — but because refund events weren't flowing from the booking platform at all. Without a map, an empty refund table looks like good news. With one, it's a finding: the map says refunds should exist here, so their absence means net revenue is silently overstated, and every downstream number that depends on it inherits the error.

Same logic everywhere the map has expectations. A month with zero attendance at a studio that was open is a data gap, not a quiet month. A member with visits but no plan isn't a loyal ghost — it's a broken link worth chasing. An ontology is the only thing that makes absence visible, because absence is only detectable against a statement of what should be there.

Multiply by locations

For a single studio, everything above amounts to a very good audit that nobody had to commission. For a multi-location operator, the economics change shape.

The same map applies at every site. That makes drift comparable: "which location's pricing has moved furthest from the list?" is one question with a ranked answer, not five separate audits with five separate consultants. A finding at one site instantly becomes a question for every site — is any other location still carrying that intro cap from its own busy season? Leakage that rounds to nothing at one site compounds across ten. And the anomalies cluster — the map doesn't just find the leak, it shows you where the leaks concentrate, which is usually where the process is broken, which is the thing actually worth fixing.

This is also why the enterprise world paid so much for the pattern for so long. The value of an ontology scales with the surface area it covers. Studios were locked out not because the value wasn't there, but because the build cost was per-customer. Building it once for a vertical is what breaks that.

What it means

The lake was the plumbing. The ontology is the meaning. Together they're the thing YC is calling the Company Brain — the layer Databricks and Palantir proved at enterprise scale, running for a business that could never have bought it.

And the outcome, for an operator, isn't a report. It's that the audit never stops. Every night the data lands, takes its place on the map, and either matches what should exist or doesn't. The fraud, the misconfiguration, the gaps — none of them were found because someone went looking. They were found because, for the first time, something was always looking.

Studios are not short on dashboards. They're short on answers. It turns out some of the most valuable answers are to questions nobody thought to ask.