Capability domains, and what connects them.

Applied rather than general. The work is choosing a decision that is currently made by intuition, establishing what a correct answer looks like, and building a model that reaches it with stated confidence. A prediction a workshop manager cannot interrogate does not get acted on, so evidence and confidence are part of the output, not an afterthought.

Most operators run hardware from several eras and several vendors at once. The durable asset is not the device integration but the normalisation layer above it: one event model that survives a hardware change, so history stays with the operator rather than with the supplier they are trying to leave.

The value is rarely in the model and almost always in what happens next. Automation here means the ranked worklist, the exception that reaches the right person, and the audit trail that lets an organisation defend the decision afterwards.

Every other domain depends on this one. Telemetry compounds quickly, and a store that answers in milliseconds at ten million rows and in minutes at ten billion is not a store, it is a deadline. The engineering is in retention, partitioning and the shape of the queries the product will actually ask.

A correct model behind an interface nobody opens has no value. Platform work is the operations view, the permissions model, the bilingual interface, and the accessibility that decides whether the whole organisation can use it or only the person who commissioned it.

Where data residency is a legal or procurement constraint rather than a preference, a cloud pipeline ends the conversation before it starts. Edge-first is not a performance optimisation in that situation, it is the precondition for the architecture being viable at all.

Research is listed here with no metrics and no claims, because there are none to make yet. It is named at all because a capability model that shows only settled work says nothing about where the next capability comes from.