THE GAUGEPLAYBOOK

Shared infrastructure is the point

Four companies in the portfolio — Largo, Richie, OnChainMind, PLAY.PAUSE.PLAI. — in four unrelated markets. Ambient software, tax, autonomous trading, and a record label. Nothing about their customers overlaps.

Their plumbing overlaps almost completely.

That's not a coincidence and it isn't luck. It's the direct consequence of building every company as segments with defined fittings: when four businesses all expose the same shape of joint, the same infrastructure snaps onto all four.

What shares

Identity and permissions. One system. Every company needs to know who a user is and what they're allowed to touch, and there is nothing differentiating about any company's answer to that question.

The action ledger. This is the big one. Every portfolio company records agent decisions the same way: trigger, inputs consulted, reasoning, action taken, outcome, human override if any. Largo logs a drafted email. Richie logs a proposed deduction. OnChainMind logs a trade. Same schema, same query interface, same replay tooling.

Building that four times would have been four times the work and produced four incompatible things. Building it once meant that a debugging tool written for Largo works on Richie's pipeline the day it ships.

The gauge layer. Throughput, latency, quality, and override rate at every joint — computed by the same service, posted to the same weekly digest format, with the same target-and-delta presentation. A new company gets instrumented on day one instead of in month six, which means it's never dark, which means its first real problem shows up as a number instead of a crisis.

Evaluation harness. Feed a segment historical inputs, compare its outputs against what actually happened, report the drift. Domain-agnostic by construction, because it operates on the fitting rather than on the contents.

Publishing. This site, the feed, the docs, the status pages. One static pipeline, four sets of content.

What doesn't share

This is the more useful list, because the failure mode of a portfolio is over-sharing, and it's a much more expensive mistake than under-sharing.

Domain models. A transaction in Richie and a transaction in OnChainMind have almost nothing in common beyond the word. Every attempt I've seen to build a "universal entity model" across genuinely different domains produces an abstraction so loose it carries no meaning and so central that nobody can change it. We didn't try.

Judgment. How Richie decides a position is defensible has no relationship to how OnChainMind decides a trade is permitted. This is the actual product in each company. Sharing it would mean none of them is any good.

Interfaces. A tax review screen and an ambient assistant surface answer to totally different rhythms. We share design tokens and a component library. We don't share layouts, and we don't share flows.

The test

Before anything becomes shared infrastructure, it has to pass one question:

Does this depend on what the business does, or only on the shape of the joint?

The action ledger depends only on the shape: something decided, something happened, a human agreed or didn't. That's true in every domain, so it shares.

A deduction classifier depends entirely on what the business does. It doesn't share, and any version of it that did would be so generic it'd be useless in tax and unusable everywhere else.

This test is cheap to apply and it has been right nearly every time. When we've violated it — twice, both times because a thing looked general — we ended up with an abstraction that grew a special case per company until it was four systems wearing a trench coat. Both got split back apart, and the split was more expensive than the original duplication would have been.

Duplication is cheaper than the wrong abstraction. Old advice. Still true. Worth restating because the pull toward premature sharing is strongest exactly when you have several companies and a tidy mind.

What it actually buys

The obvious answer is cost, and cost is the least of it.

A new company starts instrumented. Day one, it has identity, a ledger, gauges, and a publishing path. The first version of a new product is the version most likely to go dark, because everything is urgent and instrumentation always feels like it can wait. Shared infrastructure removes that choice — the gauges are there because they came with the fittings.

Lessons transfer. The override-rate insight from Largo — that clustered overrides pointed at a permissions problem, not a model problem — was directly applicable to Richie, because both measure the same joint the same way. That transfer is only possible because the measurement is identical. Four companies each measuring their own thing their own way would have learned that lesson four separate times, or three times too few.

People transfer. Someone who has worked on one company's pipeline can read another's. Not the domain logic — that takes months in any company — but the structure, the ledger, the gauges, the deploy path. That's most of the ramp-up cost in practice.

The honest caveat

Shared infrastructure creates shared failure modes. When the ledger service has a bad day, four companies have a bad day. We accept that, and we pay for it with the boring things: hard SLAs on the shared layer, graceful degradation in every consumer, and a rule that no company's critical path can be blocked by a shared service that's merely slow.

The alternative — four companies each building their own version of the same undifferentiated plumbing, four times as much surface area, four times as many places to be dark — is worse in every direction that matters.

Pipes connect. That's the first law, and a portfolio is just the largest available demonstration of it.

  • playbook
  • portfolio
  • infrastructure