MOSAIK — capabilities

MOSAIK — Multiple Operating Styles, All In Kumulus.

Providers are not interchangeable. One node has a GPU; another can boot a virtual machine per workload; a third is a perfectly good container host and nothing more. If the platform ignored that, it would place work onto machines that cannot run it and discover the problem at the worst possible moment.

MOSAIK is the vocabulary for those differences. It is not a runtime, not a product, and not a scheduler — it describes what a node can do, and BIDEEW reads that description when deciding where work goes.

What counts as a capability

A capability is a hardware or runtime fact about a node: hardware virtualisation is available, a GPU is present, a particular runtime is installed and working.

It is deliberately not a product and not a preference. "Runs a database" is not a capability — that is just an application, and treating it as one would have placement filtering on something that is not a real constraint. The test is whether a node lacking it would genuinely be unable to run the workload.

Nodes advertise their capabilities; the platform does not assume them. A node that has never reported a capability is treated as not having it, and work requiring it goes elsewhere.

Capability is not consent

This distinction matters more here than it would on a normal cloud, because the hardware belongs to somebody else.

Hardware virtualisation being available says a machine can run strongly isolated workloads. It says nothing about whether its owner wants to host them. Those are recorded separately, and one is never inferred from the other — reconfiguring a stranger's machine because a device file exists is not a decision the platform gets to make.

The practical consequence for providers: you are asked what you are willing to host, and that answer is respected even when the hardware could do more.

No silent fallbacks

If a workload needs a capability and no eligible node advertises it, the request fails. It is not quietly placed somewhere that lacks the capability.

This is a deliberate trade. A silent downgrade would remove something the customer asked for while everything still appeared to work — the failure would surface much later, as data in the wrong place or a boundary that was never there. A visible refusal is recoverable; a silent one is not.

Today and later

What ships today is the container and networking baseline every node has, plus a strong isolation capability that a provider opts into and that the platform will not substitute away.

The vocabulary is deliberately wider than what is live, because capabilities are how new runtimes arrive without redesigning placement each time. Pages describing individual capabilities will land here as they ship — this page describes the mechanism, not a catalogue of promises.