Why customising Bloo shouldn't cost you every future improvement to it
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 better things we do.
But if you've modified a native Workbook, the next sync overwrites your changes. So the documented workaround is to clone it into a Custom Workbook first. Your clone then sits where you left it while ours keeps getting better.
Customise and fall behind. Stay native and accept 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 is the fork problem, inside our own platform, at the scale of a single rule.
Bloo Command is what we're building to end it.
The same problem, larger
Every enterprise software company has a sentence it uses to say no. 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.
What Bloo Command is
Bloo Command is a console spanning every Bloo product. Datafabric, Vantage, SynthAI, SpecterForce. Two things happen there.
Governance. One place showing what is 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 specifically 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 being described 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 is SynthAI. Command governs what is deployed. SynthAI does the reasoning. Keeping that line clean matters more to us than having one product that sounds like it does everything.
Why custom work doesn't have to fork the platform
The thing that makes this possible isn't a Command feature at all. It's a decision made much further down the stack.
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 is the second consequence, which that post didn't get to.
If interpretation happens at query time, then 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 that's identical for every tenant, which means that substrate keeps improving underneath it, several times a day, without any 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 also why the ATC problem at the top of this post is solvable rather than inherent. Nothing about the architecture requires that customising 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 is being built to deliver. 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 actually escalates rather than how escalation gets diagrammed. 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 a customer's own telemetry, tuned to that 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
Partners are the hardest case, 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 and their own derived signals, then ship those to their own customers, on infrastructure they didn't have to build. Their differentiation lives in what they add. The substrate is ours. The value they sell is theirs.
Command is being built so a partner can 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.
Why this compounds instead of accumulating
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 turns out to generalise 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 useful 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. In a promotion model, custom work is how the product finds out what it should have had.
We'd rather learn what to build from one customer's real problem than from a survey of many customers' approximate ones.
What doesn't exist yet
Blog one committed us in public to showing the unfinished work. This is the first post where that rule costs something, so here is the honest position.
Bloo Command is in development. Parts of what it will govern are shipped and in use. The thing that ties them together is not.
What already exists: partners running multiple tenants work 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.
What doesn't exist yet: a single cross-product view of what is deployed where and at what version across Datafabric, Vantage, SynthAI and SpecterForce. Release targeting that lets capability be built once and shipped to a named set of tenants. And the one that matters most to us, a way to customise native content without stepping off the sync path, so that tuning a Workbook stops costing you every future improvement to it.
We're announcing intent rather than availability, and doing it now for one reason. The argument above is why Command is worth building, and we'd rather be argued with while it's still being designed than applauded after it ships. If your estate has a shape that would break this, we want to know before the design hardens.
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 is the part that fixes the direction rather than the speed. It's how the platform moves for you specifically, without moving underneath you.