Build it for one customer. Ship it to them. Keep every upgrade.
Something has bothered us for a while.
Customise a detection in Bloo today and you stop getting our improvements to it.
That isn't a bug, it's documented. Active Threat Content synchronisation pushes improved Workbooks, dashboards, reports and native Extractors into customer environments as new threats appear. No upgrade project, no change request. It's one of the best things we do.
But modify a native Workbook and the next sync overwrites your changes. So the documented workaround is to clone it into a Custom Workbook first. Your clone then sits exactly where you left it while ours keeps getting better.
Customise and fall behind. Stay native and take the generic version. Every customer who has ever cloned a Workbook to adjust a threshold has made that trade, usually without being told they were making it.
That's the fork problem, inside our own platform, at the scale of a single rule.
We started pulling on it about a year ago. The fix turned out to be much bigger than the bug, and it's the most interesting thing we're building right now.
It's called Bloo Command.
What this makes possible
Start with what changes, because the architecture only matters if the outcomes are real.
You tune a detection and keep every future improvement to it. Adjust a threshold on a native Workbook because your environment isn't the average environment. Next week we ship a better version of that Workbook. You get it, with your tuning intact. No clone, no drift, no choosing.
You get a Connector for the system nobody else runs. Every estate has one. A homegrown ticketing system, a regional payments processor, an OT protocol from 2009. Today that's a feature request that dies in prioritisation because you're the only one who needs it. With Command it's scoped work that ships to your tenant, and the platform underneath it carries on improving at full speed.
Your MSSP ships their own detection pack to their own customers. Not ours with their logo on it. Theirs. Built once in their practice, released to the subset of their tenants it was built for, running on infrastructure they never had to build.
Your SOC's escalation model stops being a workaround. The Workbook matches how your team actually escalates, not how escalation gets diagrammed in a vendor's default.
Every one of those is a thing that current enterprise software says no to. The rest of this post is why we can say yes.
The word every vendor uses to say no
Every enterprise software company has a sentence for this. It's usually a version of that isn't on the roadmap. Sometimes it's softened into a question about how many other customers have asked for the same thing, which is the same sentence in a better suit.
We've used it too.
A roadmap isn't really a plan. It's a rationing mechanism.
It exists because building something for one customer used to be genuinely dangerous. Bespoke work meant a branch. A branch meant divergence. Divergence meant the next upgrade either broke the custom work or skipped that customer entirely, and in practice it skipped them, quietly, for years.
The customer who got exactly what they asked for became the customer who stopped getting everything else.
So the industry settled on a trade. Nobody gets exactly what they need, everybody keeps getting upgrades. Requests go in, get weighed against every other customer's request, and come out two to four quarters later in a generalised form that fits nobody precisely.
That trade was correct for a long time. It isn't now, for the reason set out in Engineering Against Drift: a four-quarter delivery cycle assumes the need you describe in the first quarter is still the need you have in the fourth.
That's a stability assumption, the same species as the two-year procurement cycle. A three-year commitment can still make sense, but only as a bet on how fast a vendor changes, never on what they happened to ship at signature. A roadmap is a bet on the second thing. By the time a generalised version of your request arrives, the threat that prompted it has changed shape and the source that produced the telemetry has renamed half its fields.
The roadmap has become a way of delivering, on schedule, the thing you needed a year ago.
We'd rather not have one.
What Bloo Command is
A console spanning every Bloo product. Datafabric, Vantage, SynthAI, SpecterForce. Two things happen there.
Governance. One place showing what's actually deployed across your estate. Which capabilities are live, in which tenants, at which versions, and what changed since you last looked. Today that question gets answered by asking several people. It should be answered by looking.
Delivery. Command is how capability built specifically for you, or for your partner practice, reaches your environment without becoming a branch that strands you on an old version.
Customers and partners log into it. This isn't an internal tool we're describing for interest.
What Command is not is an investigation tool. Hypothesis generation, query building, root cause work, the whole business of turning a question into an answer over your telemetry: that's SynthAI. Command governs what's deployed. SynthAI does the reasoning. Keeping that line clean matters more to us than having one product that sounds like it does everything.
Why this doesn't fork the platform
Here's the part we find genuinely satisfying, and it isn't a Command feature at all. It's a decision made years earlier, much further down the stack, that turned out to unlock something nobody designed it for.
Bloo binds late. The previous post explains why, and draws one consequence from it: late binding is what lets us ship daily without breaking anybody's detections.
Here's the second consequence, which that post didn't reach.
If interpretation happens at query time, a customer-specific interpretation is just another interpretation.
It isn't a branch. It doesn't touch the storage layer. It doesn't create a version of Bloo that has to be maintained separately from every other version of Bloo. It sits above a substrate identical for every tenant, which means that substrate keeps improving underneath it, several times a day, with none of that improvement needing to be reconciled against your custom work.
Vendors who bind at write time can't do this. Not for lack of will. In a write-time-bound system, customer-specific interpretation genuinely is a fork, with everything that follows.
Which is why the problem at the top of this post is solvable rather than inherent. Nothing in the architecture requires that tuning a Workbook takes you off the sync path. That's a gap in the tooling, not a law of physics, and Command is the tooling.
Two kinds of custom
"Custom" does a lot of work in vendor sentences, so it's worth separating the two things Command delivers. They're different in kind, and confusing them is how people end up disappointed by both.
Custom capability is new product surface, scoped to one tenant or one partner practice. A Connector to a system nobody else runs, and the Extractor that makes sense of what it emits. A Workbook shaped around how a specific SOC escalates. A case workflow built for a regulator who wants evidence presented a particular way.
This is engineering work. It gets scoped, estimated and released like engineering work. The only difference is that the release is targeted.
Custom derived signals is feature engineering in the data sense rather than the product sense. Worth being precise, because "feature" means two unrelated things in this industry.
Here it means deriving new inputs from your own telemetry, tuned to your environment. The attributes, aggregations, enrichment and baselines that make a signal accurate in this estate rather than accurate on average. What counts as anomalous authentication in a bank with a fixed workforce and what counts in a business with heavy contractor churn are not the same question, and a model trained on the average of both is worse at each.
The output isn't new surface. It's accuracy. And it only works because the raw telemetry is retained in full. You can't derive a new signal from data that was sampled away at collection, and you can't backfill a new feature across three years of history you no longer have.
Neither of these is a fork.
What a partner does with it
This is the case we're most excited about, and the one where the current model breaks most obviously.
An MSSP or MDR partner doesn't want our features. They want their own. Their commercial position depends on offering something competitors can't, and "we resell the same platform, configured the same way" is not a position. If the only differentiation available is whose logo sits on the portal, the partner is a reseller, and reselling gets squeezed every year.
What a partner actually needs is to build their own detection content, their own workflows, their own derived signals, then ship all of it to their own customers on infrastructure they never had to build. Their differentiation lives in what they add. The substrate is ours. The value they sell is theirs.
Command is how they do that directly. See their tenants. Build capability once. Release it to the subset of customers it was built for.
That's a channel strategy expressed as architecture rather than as a discount schedule, and we think it's the right way round.
Where we are
Blog one committed us in public to showing the unfinished work. This is the first post where that rule costs something, so here's the honest position.
Command is in development. A good deal of what it will govern is already shipped and running. The layer that ties it together isn't.
Working today: partners running multiple tenants operate from a single console across their customers, with access defined per user and per tenant. Active Threat Content synchronisation already pushes new detection content into tenants continuously. Custom Extractors and cloned Workbooks already let a tenant diverge from native content. Per-tenant scoping, role-based access and organisation structure are shipped and documented.
Still to build: a single cross-product view of what's deployed where and at what version across all four products. Release targeting that lets capability be built once and shipped to a named set of tenants. And the one we care most about, a way to customise native content without stepping off the sync path.
We're announcing intent rather than availability, deliberately, and doing it now for one reason. We'd rather be argued with while this is still being designed than applauded after it ships. If your estate has a shape that would break it, that's worth more to us today than it will be in six months.
Why this compounds
There's a version of per-customer engineering that's just an expensive services business wearing a product's clothing. We know the risk. What separates the two is what happens to the work afterwards.
Custom capability that generalises gets promoted. A Connector built for one organisation becomes a Connector. A Workbook built for one SOC's escalation model becomes a template. A derived signal that proves itself in one contractor-heavy environment becomes available to every contractor-heavy environment.
That inverts the usual economics. In a fork model every piece of custom work is a permanent liability, maintained forever by someone at a cost that never goes away. Here, custom work is how the product finds out what it should have had all along.
We'd rather learn what to build from one customer's real problem than from a survey of many customers' approximate ones. Every engagement makes the platform better for everyone who never asked.
What this is really about
The previous post argued that what you're buying from a vendor now is a rate of change rather than a product. That's true, and on its own it isn't enough.
A vendor can change quickly and still never change toward you. Speed set by the average of everyone who asked is still an average. It arrives on schedule, in a generalised form, and fits nobody precisely.
Command fixes the direction, not just the speed.
Your estate is not the average estate. It never was. The platform should move toward yours specifically, and it should do that without ever moving underneath you.
That's what we're building.