A bid ceiling is a completion budget.

Why bidding exists

Some supply is fixed-price and immediately reservable. Some is negotiated, auctioned, or must be held briefly before provisioning. We support a bid/reservation layer only where it improves the probability of completing a workload.

It is not exposed as a speculative trading product. Seeing capacity is not the same as holding it.

Stage contract

• Owns: bidding / reservation service
• Before: route plan proposes bid_ceiling (router does not reserve)
• After: lease.status=reserved with validated supplier lease ID and accepted terms
• Transport: gRPC (workflow → bidding) + provider HTTPS (adapter)
• Durable ack: reservation_attempt row with provider idempotency key before the supplier call; lease commits supplier ID only after success

Lifecycle

offer observed → quote requested → quoted → bid submitted
  → accepted → reserved → provisioning → active → released
                      ↘ rejected | expired | cancelled

Every transition is idempotent. A supplier-side reservation is not considered active until Nodus persists the supplier lease ID and validates the lease terms.

The ceiling formula

The router proposes a ceiling, not an unrestricted spend amount. The ceiling exists so reservation cannot exhaust the budget needed to finish, including likely recovery:

bid ceiling = remaining workload budget
            - expected non-compute costs
            - minimum recovery reserve
            - margin for viable fallback routes

Nodus may counter-bid inside that ceiling. It must not bid against its own concurrent requests for the same workload without explicit capacity diversification logic. Accepting a low hourly rate that cannot meet the deadline, or that leaves no recovery reserve, is a policy failure even if the bid clears.

What a lease records

• lease ID, supplier lease ID, workload / stage / generation
• quoted and accepted price, billing increment, currency
• start/end window, cancellation / reclaim terms
• provisioning handle, credential reference, state
• route-plan and policy versions

Accepted quote and lease terms become immutable financial evidence. Supplier invoice reconciliation must reference them. Market price alone is insufficient for settlement.

Concurrency controls

• One primary reservation attempt per route decision unless policy explicitly permits hedging.
• Reservation commands use a durable idempotency key.
• A failed or expired lease cannot be reused by a later generation.
• Supplier events are verified before changing lease state.
• Supplier timeouts: query final provider state before retrying or releasing a perceived lease.

Parallel reservations stay off by default. Any hedging policy must define maximum concurrent commitments, cancellation windows, worst-case committed spend, and an operator-visible reconciliation plan.

Financial-risk posture

Bidding is a financial-risk service. It requires a double-entry-style commitment ledger, approval limits, per-tenant and per-supplier exposure limits, and a durable reservation state machine. Route planning may propose a bid; only the reservation service may submit it.

Every accepted quote, bid, lease, release, supplier invoice line, and customer charge is immutable evidence with a correlation ID. Financial reconciliation is a gated close process, not a best-effort background report.

Cost means cost to completion. Launch price that strands recovery is not a win.

What ships next

Full automatic bidding and settlement ledger close land with signed reclaim recovery (design phase 5). Until then, many pilot paths are fixed-price reserve. Heterogeneous metering across suppliers (different billing increments and currencies) is still an open schema problem. We will not invent customer charges from market snapshots alone.

Previous: 003 · Routing. Next: 005 · Execution.