Architecture: fleet and factory scheduling

One scheduler over four factories that all run the same order-taker contract. How an order is placed, claimed, tracked, and retired across the fleet.

two-level scheduling order-taker contract lane claims heartbeat supervision

Click the map to enlarge.

order a product spec
Spock fleet scheduler, capability-matched
Mothership
trainrendercaptioncompute
BigHonker
rendercaptioncompute
Softserve
captioncomputeyields to Plex
the Fellowshiphead: Tolkien
distributed CPUevaluation11 nodes

A capability gap is refused at the desk, by name. A busy factory waits in its queue. Orders serialize per card, run in parallel across factories.

The order-taker contract

Every factory runs the same contract. The implementation behind each point varies by host; the contract never does.

Accept an order from its queue.
Claim the lane so the fleet knows that card is busy.
Publish card-state and a heartbeat on a fixed cadence.
Resume idempotently after any interruption.
Honor pause and priority.
Retire and release the claim by every exit path.
Count failures as failures, never silent success.
Hold an order it cannot satisfy, naming the missing capability.
Control surface, per order: pause priority requeue cancel stop. Each is applied as a control slip the running order honors, never by editing a queue by hand. A stopped order keeps its partial output and retires clean.

One scheduler over four factories, all running the same contract. When I submit an order, the fleet scheduler places it on a factory whose declared capabilities fit and whose spare capacity can take it. Inside that factory the order becomes a tracked object: it claims the card, beats a heartbeat, survives a restart, answers to pause and priority, and retires cleanly whether it finishes or fails. The models these factories run are on the AI and compute map and the machines are the lab overview. The orchestrator that fronts the whole fleet is Home AI, and the ARM factory is the Fellowship.