For project teams
For project teams
Ask once. The request states what the work needs; Novation characterizes it and slices it into pieces the desk can price and buy; the answer says where it will run, when, at what cost, and what is left in your budget. Your schedulers stay where they are, and your work runs where it always did.
WHAT A REQUEST CARRIES
The deadline. The tolerance for interruption. The priority. The minimum run and the topology the work needs. Where the data sits. The project budget it draws on. Who can say yes — raised in your intake tool, Zip or Coupa, where you have one, with the purchase order before any order is placed. Written down once, in an hour with your engineers, held against every job after that, weighted by spend, and asked again when the job logs show a workload family has changed.
WHAT COMES BACK
Where the work will run and when. The delivered cost, not the rate card. The amount reserved against the budget and what is left after it. The acceptance test on the allocation before the work starts. And a stay-put, with the reason, when staying put is right.
WHAT STOPS AND WAITS
A request above the project budget or above the approval threshold. A supplier that is not through your security review, at any price. Work the engineers have not confirmed can move. Each stops and waits for a named person, with the alternatives and the numbers on the page.
Characterize, then slice
A training campaign is not one purchase. It is staging, then training, then evaluation, and each needs a different machine for a different window with a different tolerance for interruption. Novation reads your job history — Slurm accounting, Kubernetes events, Ray submissions, Airflow task instances — classifies the work by family, infers what could move, and puts the inference in front of your engineers to confirm. Anything unconfirmed is treated as firm. Then it cuts each family along the four seams that price apart — phase, hardware, deadline, interruptibility — and writes the requirement for every piece before a single price is looked at.
A fleet, characterized
ConceptualScroll the figure sideways →
Read from job history, not a questionnaire. Each class is sized by spend; the green pool is what your engineers confirmed can move. Anything inferred but unconfirmed is drawn dashed and treated as firm.
The pool is stated before any saving is. On the calculator's default fleet it is 30% of spend, and 15% of that is held back to retire a commitment first.
Why this is the mark. The Mekko is the brand mark because it is also the first chart the audit draws. Same object, same reading: what we look at, before what we do.
The budget is the bridge
01 · REQUEST
What the work needs, against a project budget.
02 · AUTHORIZE
Who approved, against which budget, inside what limit — in your intake tool where you have one, with the PO before the order.
03 · RESERVE
The amount held the moment the work is approved.
04 · RUN
The desk places it, or records what it would have placed; your scheduler runs it.
05 · DEBIT
When it ran, at what it cost delivered.
06 · RECONCILE
To the contract, the rate card, the purchase order, and the invoice.
Nothing reserves the money at approval today, and nothing debits it when the work runs, so the first notice is the invoice. Here the first notice is the request.
The demo for this seat
File a request for an invented campaign and watch it characterized and sliced into the pieces the desk will price; see the requirement that goes to the desk, the amount reserved against the project budget, the approval it waits for, and the answer that comes back — including one that says stay put. Behind an email code; ask and we will let you in.