The router is pure on purpose.

Match, cost, completion

Profiling and routing exist to honor three product pillars:

• Match: hardware that fits the work (memory, interconnect, runtime, locality), not the largest accelerator in the catalog.
• Cost: optimize expected cost to completion, not the cheapest hourly offer.
• Completion: attach a fallback graph so reclaim does not end the workload.

A B200 that the work does not need is a routing failure, even if it is available and bid-able.

Two stage handoffs

Profile. Workload revision + inputs become a versioned execution_envelope (Temporal activity / gRPC). Durable ack: envelope row + outbox.

Route. Envelope + policy + market/health snapshots + remaining budget/deadline become primary route + fallback graph + bid_ceiling + score breakdown. Durable ack: route decision and explanation in the same Postgres transaction.

Signals → envelope

Customers describe work and outcome. The profiler compiles that into something the router can score:

• Memory / model size → peak accelerator memory, footprint, topology
• Runtime / throughput → expected duration, parallelism, deadline slack
• Data / resilience → locality, restartability, checkpoint cost, interruption tolerance
• Outcome → remaining max_cost_usd, policy, continuity mode

Confidence is recorded on the envelope and used as a routing input, not hidden. v1 may derive the envelope from static image/metadata and declared requirements; short probe runs are an open decision we have not locked.

Continuity modes

Not every AI workload is a long checkpointable training job. The envelope carries honesty about recovery:

• checkpointed: training / fine-tune; restore gen N+1 from latest verified manifest
• restartable: idempotent batch / many inference jobs; re-queue unfinished units via cursor
• ephemeral: short best-effort; fail fast or retry from origin per policy

The router must not invent checkpoint restore for work that cannot resume.

The objective function

Maximize probability of finishing on time within budget, subject to policy. Score components persisted with every decision:

fit              - envelope vs offer (memory, accel, interconnect, locality)
time_to_result   - expected runtime + provision latency vs deadline slack
cost_to_complete - expected run cost + expected recovery under interruption model
recovery_value   - quality of fallback graph (alternates, restore RTO)
health           - supplier health; stale offers penalized or ineligible
policy           - hard constraints; violations are rejects, not soft scores

bid_ceiling is derived from remaining budget after non-compute costs, a minimum recovery reserve, and margin for viable fallback. Cheap capacity only wins when it can deliver the required outcome. Excess accelerator tier relative to the envelope is an explicit score penalty.

Fallback is a graph

The decision stores a graph, not a single backup provider. Branches are typed by failure class: reclaim, provisioning failure, restore incompatibility, deadline/budget risk. Each branch carries feasibility conditions, expected recovery time, expected cost, and confidence. When the graph is exhausted, recovery re-enters routing against fresh market snapshots with the remaining envelope: progress consumed, budget spent, deadline slack left, last verified manifest. It does not silently invent capacity.

Market price changes alone do not preempt a healthy run. Explanations must be replayable from stored snapshot IDs. Deterministic scoring given the same snapshot IDs is required for audit and customer trust.

Why purity matters

If the router also reserved, every scoring bug would become a financial bug. If the router called providers, latency and rate limits would poison every decision. Purity keeps side effects in the bidding service, keeps decisions append-only and explainable, and lets reclaim call the same function with a thinner envelope.

Inputs are immutable IDs and snapshots. Outputs are a plan. That is the entire interface.

What ships next

Deterministic route explanations and overprovision penalties are the near-term gate. Probe-based profiling, richer interruption models in cost_to_complete, and warehouse-backed learning from recovery postmortems come after we have enough scored decisions to trust. Hedging (parallel reservations) stays off by default until we define max concurrent commits and cancel windows.

Previous: 002 · Market. Next: 004 · Bidding.