BIDEEW — placement
How Kumulus decides which provider runs your workload, and why it refuses rather than guesses.
BIDEEW — Blockchain Intelligent Dispatcher for Equitable and Efficient Workloads. The name is Wolof for "star".
BIDEEW answers one question: given a workload and a network of independent providers, which machine should run this? The "equitable" half of the name is not decoration — the same component is responsible for accounting for what each provider contributed, so that placement and payment describe the same reality.
The gates
A workload passes through a series of gates, in order. Failing any one of them removes a provider from consideration.
1. Health. Only providers that have checked in recently are considered. A node that has gone quiet is not a candidate, however good its hardware.
2. Declared capacity. Does the provider have room, according to what it has committed to the network? This is the commercial view: how much of this machine is on offer.
3. Physical fit. Does the workload actually fit on a single node, according to what that machine reports about itself right now?
This gate is separate from the previous one for a reason worth stating: totals lie. Four machines with one core free each add up to four cores and cannot run a two-core workload. Capacity has to be checked where the workload will actually land, not summed across the network.
4. Score. Among providers that survived the gates, the best-placed one wins — a combination of how healthy it is, how much room it has, and how much it is already doing.
Refusing is a feature
If no provider passes the gates, the request fails and says so.
That is a deliberate choice, and the same one MOSAIK makes about capabilities. The alternative — placing the workload somewhere that does not really fit, or quietly dropping a requirement to make something work — produces a system that appears healthy while doing the wrong thing. A refusal you can see and retry is a better outcome than a success that was not one.
It also keeps two different problems distinguishable: nobody offers what you asked for and everybody who offers it is full are different situations with different answers, and collapsing them into one generic failure would help nobody.
Failing open, on purpose
One deliberate exception: when a machine has not reported fresh details about itself, the physical-fit gate lets it through rather than excluding it.
The reasoning is that a reporting gap is not evidence of a full machine. Treating silence as "no room" would quietly remove healthy providers from the network every time a report was late — a small glitch becoming a capacity outage. The gates that protect correctness fail closed; this one, which is an optimisation, fails open.