{
  "kind": "pricing",
  "slug": "pricing-and-packaging",
  "title": "Pricing and Packaging Inputs",
  "summary": "The reasoning framework and input checklist a forward deployed lead uses to construct, defend and expand a post-training deal price, reached for when scope is agreed and a number has to go on paper.",
  "stage": "proposal",
  "body": "*Playbook stage: proposal, and reused at procurement.* Reached once the scope in **Reference Architectures** is agreed and a number has to go on paper. The paragraphs it prices are in **Proposal Blocks**.\n\n# What this is\n\nThis is not a price list. Prime Intellect's rate card is not something a template gets to assert, and a forward deployed lead who quotes a number they cannot reconstruct will lose the room the moment procurement asks how it was built. What follows is the reasoning: the cost stack under a post-training engagement, the four shapes that stack can be sold in, the anchoring question that sets the ceiling, and the arithmetic you must be able to do without opening a spreadsheet.\n\nEvery {{placeholder}} in this document is an assumption, including every figure in the worked example, which is invented end to end. Fill them from your own deal desk before this leaves your laptop, and use the ids in `inputs` as the single namespace so the checklist and the formulae are visibly the same object.\n\n## The cost stack\n\nSix things cost money in a post-training engagement: five of them yours, one of them the customer's. They behave differently, and confusing them is how margin disappears.\n\n| Cost | Behaviour | Who consumes it | Recurs? |\n| --- | --- | --- | --- |\n| Committed compute (training) | Bought in blocks at a known hourly rate, paid whether used or not | The customer's training runs | One-off per campaign, but the commitment is standing |\n| Applied research time | Senior, capacity-limited, booked weeks ahead | Discovery, reward design, run triage, failure analysis | One-off, front-loaded, always underestimated |\n| Environment construction | Engineering against the customer's real tools and data | Turning a workflow into something an agent can be trained in | One-off per workflow, with a maintenance tail |\n| Eval construction | Task set, verifier, held-out split, baseline measurement | Proving the thing works and keeps working | One-off to build, recurring to run |\n| Inference | Serving the adapted model in production | The customer's users, continuously | Recurring, and the only line that grows with their success |\n| Customer SME and data-engineering time | Not on your profit and loss, and the commonest cause of slippage | Baseline measurement, data access, trace capture, sign-off | Front-loaded, and unbudgeted on their side more often than on yours |\n\nThree consequences follow immediately.\n\nFirst, **the recurring lines are inference and eval runs; everything else is a one-off with a tail.** A deal priced entirely on the one-offs is a consulting engagement wearing a platform's clothes. It will be renegotiated from zero every year, and the second year will be harder than the first, because the customer now believes environment work is a solved problem.\n\nSecond, **environment and eval construction have a maintenance tail nobody budgets for.** The customer's internal API changes and their tool surface shifts. Price {{maintenance_tail}} explicitly, as a named line, or it is absorbed by applied research time you have already sold at zero.\n\nThird, **the cost line you do not control is the one that sets the schedule.** {{customer_sme_days}} pays for the baseline, the data access and the sign-off, and it is spent by people whose manager did not approve this project. Get those days named and calendared before signature, from the line manager rather than the sponsor. Where they are not committed in writing, inflate the POC duration rather than cutting the fee: a proof that overruns because their data engineer never appeared still costs you the full committed compute block.\n\n## Unsold committed capacity is already paid for\n\nThe single most expensive habit in compute sales is treating reserved capacity as free because the invoice has already been paid.\n\nIf the deal reserves {{committed_gpu_hours}} and the customer's runs consume {{expected_utilisation}} of them, the deal did not cost you that fraction of the block. It cost the whole block, unless another customer's workload is genuinely queued and able to fill the gap. Charge 100% against the deal in your head, every time. When the gap is real and unavoidable, price it as risk you are carrying and get paid for carrying it, or push it back to the customer as a lower commitment with burst pricing above it.\n\nThe arithmetic you should be able to run silently while the customer is talking:\n\n- **Gross compute cost** = {{committed_gpu_hours}} multiplied by {{cost_per_gpu_hour}}, at 100% of committed, never at {{expected_utilisation}}.\n- **Human cost** = ({{applied_research_days}} + {{environment_days}} + {{eval_days}} + {{maintenance_tail}} across the term) multiplied by {{loaded_day_rate}}.\n- **Inference cost** = {{inference_volume}} multiplied by your serving cost per unit, for the months of the term the deployment is actually live. It is small in a POC and it is not small at renewal.\n- **Contribution** = contract value minus all three.\n- **The floor test**: contribution margin below {{target_gross_margin}} needs a written reason, not a feeling. Zero is not a pass. If the reason is that the deal becomes a platform deal later, write down the specific expansion, its size and its date. An unwritten expansion is not a plan.\n\n## The anchoring question\n\nEverything above tells you what the deal costs. It says nothing about what it is worth. That comes from one question, asked early and pursued until you get a number.\n\n**What does this workflow cost you today, per unit?**\n\nNot annually. Per unit: per ticket, per claim, per contract reviewed, per research report, per support conversation. Annual figures are guessed; unit figures are known to the person who runs the team, because their headcount plan depends on them.\n\nConvert it as follows. If the workflow runs {{annual_volume}} at {{unit_cost_today}}, and the eval design says the verifier covers {{addressable_share}} of the task — agreed with their operational owner, not estimated by you — then the annual value pool is {{annual_volume}} multiplied by {{unit_cost_today}} multiplied by {{addressable_share}}. Bounding the pool by verifier coverage rather than by optimism is the whole point: the share of the workflow you can prove you touch is the share you are allowed to count. Your **value ceiling** for year one is {{capture_rate}} of that pool, the fraction the customer will concede is attributable to you rather than to their own change management.\n\nTwo disciplines on the ceiling. It is a *total contract* ceiling for year one, so every shape you stack inside the same twelve months draws on the same pool: a POC fee plus a subscription plus a committed floor must sum under it, not each sit under it. The exception is a POC genuinely funded from a pilot or innovation line rather than the production budget, in which case the ceiling binds only the production tranche. That is what {{budget_source}} is for. Ask which budget before you build the package, not after.\n\nThe ceiling matters more than the floor. The floor tells you when to walk; the ceiling tells you that a number well below it should never be defended apologetically.\n\n## The four packaging shapes\n\nThe four shapes, what each is, when each fits and how each fails, are set out in `packages`. What matters here is how they combine.\n\nMost real deals are a blend: a POC fee converting into a committed compute floor plus a platform subscription, with the outcome mechanic used as a discount trigger rather than as the primary payment. Neither outcome instrument attaches to the POC fee itself as upside. **Proposal Blocks** commits in writing that the POC is not success-contingent, and that commitment governs; outcome mechanics belong to production terms, with a threshold rebate the one instrument that may sit inside a POC, because it is bounded and priced in on the day.\n\nThat last clause is the most useful sentence in this document, so it is worth unpacking. **Outcome pricing is far safer as a rebate you owe on failure than as an upside you must chase.** A rebate is bounded, priced into the headline number today, and settled by a single threshold test. An upside is unbounded in effort, collected a year later, and settled by an attribution argument with someone whose bonus depends on the answer. A rebate needs only an agreed threshold and a metric a third party can recompute; an upside needs a full attribution model that survives their reorganisations, their process changes and their staff turnover. And a rebate lets you raise the headline price now in exchange for carrying a risk you understand. Offer neither on a metric nobody outside the customer can recompute — see {{verifier_type}}.\n\nNone of the four shapes prices production serving directly, which matters because inference is the only line that grows with the customer's success. In practice it rides inside the committed floor. That is tolerable in year one and dangerous at renewal: once steady-state serving dwarfs training, a floor sized for training campaigns gets renegotiated downwards by a customer who has stopped training and started serving. Decide before signature which of two things happens at renewal — inference is metered separately at a per-unit or per-token rate with its own monthly minimum, or the floor is re-sized against {{inference_volume}} measured from production traces. Writing down neither is how the durable revenue line quietly becomes the discount.\n\n## Why a free POC is usually a mistake\n\nA free POC is not a cheaper sale. It is a slower one. Three specific failures:\n\n1. **It buys no attention.** Unpaid work is scheduled against paid work and loses. Your applied research time is consumed while the customer's data engineer is on someone else's project.\n2. **It sets the anchor at zero.** Everything you did in the POC is now the baseline of what is free. Environment construction, the most expensive thing you do, has just been demonstrated as complimentary.\n3. **It hides the buyer.** A customer who cannot find a fee at the very bottom of your range cannot find the production budget either. The fee is a qualification instrument disguised as a commercial term.\n\nWhen you genuinely must run one unpaid, for a lighthouse logo or a market you need a reference in, never do it for nothing. Trade it. Take reference rights, a named case study with metrics, a committed production decision date, executive sponsorship on the kick-off call, {{customer_sme_days}} named and calendared, and a written eval that defines success before the first run.\n\nThat eval clause needs checkable terms rather than good intentions. Name who holds the held-out set — them, not you. State that it is withheld from you until the readout, and that it is re-drawn at renewal. Leakage of the held-out set into training data is not a maintenance nuisance; it is the failure that makes a paid readout unrepeatable and a value share unpayable, and by the time anyone notices, the number you were paid on cannot be reproduced. Free of charge is acceptable; free of obligation is not.\n\n## Discount discipline\n\nA discount given for nothing teaches the customer that your first number was dishonest, and every subsequent number will be tested. The rule: **price moves only when something else moves.** If they want a lower number, something must come back across the table: a longer term, a bigger commitment, a logo, a case study, a reference call, an earlier expansion date, faster payment terms, committed SME days, or access to the workflow data that makes the next deal cheaper to build. The `tradeables` list is the menu.\n\nTwo mechanical safeguards. Discount the *rate*, never the *scope*; cutting scope to hit a number is how a POC ends with an eval too thin to prove anything. And put any commercial concession on a clock. A discount that expires on a stated date is a negotiation; one that does not is the new price.\n\n## Land and expand, specifically\n\nPost-training has an unusually clean expansion geometry, and it is worth naming because it changes what you optimise for in deal one.\n\n**One workflow.** Pick the narrowest workflow with a real verifier, and settle {{verifier_type}} before you quote: it moves {{eval_days}} by an order of magnitude and it decides whether any outcome mechanic is available to you at all. Deal one exists to prove the loop works and to build the customer's belief that their own traces are an asset. Optimise for provability, not size.\n\n**Adjacent workflows.** Reuse across workflows is real but partial, and being precise about which half transfers is what stops you discounting on a hope.\n\nWhat transfers: tool adapters, the sandbox harness, data plumbing, the deploy path and trace capture. Expect {{reuse_fraction}} of {{environment_days}} back on workflow two.\n\nWhat does not transfer: the task set, the verifier, reward shaping, the held-out split and the baseline measurement. A new workflow is a new eval, re-costed at close to full {{eval_days}} every time. The eval is the least portable thing you build; only the scaffolding around it moves, and the industry habit of describing evals as reusable infrastructure is the reason second workflows overrun. The **Strategic Deployment Playbook**'s expansion stage is not an exception to this. What a shared verifier saves there is the adjudication apparatus — trained adjudicators, an agreed rubric, a time-based cut already defended — and that is real, but it is not the eval, which is re-costed in full every time.\n\nSo the pricing instruction is concrete: hold rate on workflows two and three, bank the environment reuse as margin, and never discount on the assumption that the eval is reusable. Contract for the adjacency early — get {{expansion_map}} written down and reserve pricing for those workflows at signature, before you have proved yourself and lost the leverage of uncertainty.\n\n**The platform.** Eventually the customer wants to build environments themselves, on their own cadence, without waiting for you. That is the subscription, and it is the durable revenue. Every earlier stage should be visibly a step towards it, not a bespoke project that ends.\n\n## Worked example, all numbers placeholder\n\nA {{mid-market fintech}} wants to adapt a model for {{contract clause review}}. Every figure below is invented and marked; none of it is a benchmark.\n\n**Anchor.** {{40,000}} contracts per year at {{£38}} fully loaded is {{£1.52m}} of annual workflow cost. The eval design covers {{60}}% of the task, agreed with their head of legal operations, so the value pool is {{£912k}}. At a {{15}}% capture assumption, the year-one total-contract ceiling is {{£137k}}.\n\n**Cost of the POC.** {{4}} weeks of {{16}} GPUs is {{10,752}} GPU-hours at {{£2.40}}, which is {{£25.8k}} of compute charged at 100% of committed. {{15}} applied research days plus {{20}} engineering days is {{35}} days at {{£900}}, which is {{£31.5k}}. Add {{2}} maintenance days inside the term at the same rate, {{£1.8k}}. POC inference is negligible; production inference is not, and is handled at renewal. Total POC cost {{£59.1k}}.\n\n**Package, summed against the ceiling.** POC at {{£75k}} fixed against a written eval, namely {{clause-extraction F1 on a 300-contract held-out set held by their legal operations team, withheld from us until readout, baseline measured in week one, re-drawn at renewal}}. On success, a {{12}}-month platform subscription at {{£35k}} plus a committed compute floor of {{£25k}}, with workflows two and three pre-priced at the same rate for {{18}} months. Year one totals {{£135k}} against a {{£137k}} ceiling. That is uncomfortably tight, so confirm the budget: if the POC is funded from a {{pilot and innovation}} line rather than the production budget, the ceiling binds only the {{£60k}} production tranche and there is room to raise the floor.\n\n**Margin check.** {{£75k}} minus {{£59.1k}} is {{£15.9k}} of contribution, a margin of {{21}}% against a target of {{60}}%. It is thin, and it is meant to look thin, because that is what a correctly costed POC looks like. Two honest readings, and you must pick one in writing. Either the POC is an acquisition cost carried against the named expansion, in which case put the expansion, its size and its date into the deal review; or the POC is too cheap or too long, and the fix is scope-in-time — fewer weeks, fewer GPUs — never scope-in-rigour. What you may not do is charge the compute at the {{55}}% you expect to use, which would report {{£27.5k}} of contribution and a comfortable {{37}}% on a deal that has not changed in any respect.\n\n**Trade.** The POC fee is {{15}}% below list, given in exchange for a named case study, two reference calls per quarter, {{10}} days of their SME time named and calendared, and a production go or no-go decision within {{30}} days of the readout.",
  "fields": {
    "inputs": [
      {
        "id": "cost_per_gpu_hour",
        "name": "Committed GPU-hour cost",
        "unit": "currency per GPU-hour",
        "howToGet": "Deal desk, for the specific accelerator class and term length; never the on-demand list rate.",
        "whyItMatters": "It is the only genuinely fixed number in the stack, and it sets the floor below which the deal destroys margin regardless of the strategic story."
      },
      {
        "id": "committed_gpu_hours",
        "name": "Committed GPU-hours in the engagement",
        "unit": "GPU-hours",
        "howToGet": "GPUs reserved multiplied by the reservation window, taken from the scoping document rather than from the expected training plan.",
        "whyItMatters": "Reserved capacity is paid for whether the customer's runs fill it or not, so the deal must be charged the full block."
      },
      {
        "id": "expected_utilisation",
        "name": "Expected utilisation of the committed block",
        "unit": "percent",
        "howToGet": "Applied research estimate of run count, run length and restart rate for the planned campaign.",
        "whyItMatters": "The gap between committed and used is risk you are carrying; naming it turns an invisible loss into a priced term."
      },
      {
        "id": "applied_research_days",
        "name": "Applied research days",
        "unit": "person-days",
        "howToGet": "Ask the assigned researcher for their own estimate of discovery, reward design, run triage and failure analysis, then apply the historical overrun factor.",
        "whyItMatters": "It is scarce, booked ahead, and the input most reliably given away free in POCs."
      },
      {
        "id": "environment_days",
        "name": "Environment construction days",
        "unit": "person-days",
        "howToGet": "Engineering estimate against the customer's actual tool surface, made after you have seen their API docs and a real trace, not after the demo.",
        "whyItMatters": "It is the largest one-off engineering cost and the thing customers most often assume is included."
      },
      {
        "id": "eval_days",
        "name": "Eval construction days",
        "unit": "person-days",
        "howToGet": "Estimate task set assembly, verifier build, held-out split and baseline measurement separately, and estimate them against {{verifier_type}}; the baseline is usually slowest because it needs their data and their people.",
        "whyItMatters": "Without a costed eval you cannot prove improvement, and an unproven POC converts at a fraction of a proven one."
      },
      {
        "id": "verifier_type",
        "name": "Type of verifier the eval will rest on",
        "unit": "programmatic | model-judged | human-rated",
        "howToGet": "Propose all three against a real trace and see which one the operational owner will actually sign.",
        "whyItMatters": "It sets eval cost within an order of magnitude, and it is the precondition for outcome pricing: never offer a value share or a rebate on a metric no third party can recompute."
      },
      {
        "id": "maintenance_tail",
        "name": "Environment and eval maintenance",
        "unit": "person-days per quarter",
        "howToGet": "Ask their engineering lead, not their sponsor, how fast their tools and data schema change.",
        "whyItMatters": "Unbudgeted maintenance silently consumes applied research time you have already sold at zero."
      },
      {
        "id": "customer_sme_days",
        "name": "Committed customer SME and data-engineering days",
        "unit": "person-days, with names and dates",
        "howToGet": "Get them named and calendared before signature, from the line manager who owns the people rather than from the sponsor who owns the budget.",
        "whyItMatters": "It is the schedule risk you cannot control; where it is not committed in writing, inflate the POC duration rather than cutting the fee."
      },
      {
        "id": "inference_volume",
        "name": "Steady-state inference volume",
        "unit": "tokens or requests per month at full rollout",
        "howToGet": "Units of work per month multiplied by measured tokens per unit from the POC traces.",
        "whyItMatters": "It is the only recurring line that grows with the customer's success, so it is where durable revenue is either captured or forfeited."
      },
      {
        "id": "unit_cost_today",
        "name": "Current fully-loaded cost per unit of the workflow",
        "unit": "currency per ticket, claim, contract, report or conversation",
        "howToGet": "Ask the line manager who owns the team, not the sponsor; their headcount plan already contains this number.",
        "whyItMatters": "It is the anchor from which the value ceiling is derived; without it you are pricing against your own costs alone."
      },
      {
        "id": "annual_volume",
        "name": "Annual volume of the workflow",
        "unit": "units per year",
        "howToGet": "Their operational reporting or ticketing system, ideally as a screenshot rather than a spoken figure.",
        "whyItMatters": "Volume multiplied by unit cost is the value pool; a high unit cost at low volume is a workflow not worth training."
      },
      {
        "id": "addressable_share",
        "name": "Share of unit cost the deployment can plausibly remove",
        "unit": "percent",
        "howToGet": "Derive it from the eval design: what fraction of the task the verifier actually covers, agreed with their operational owner.",
        "whyItMatters": "It stops the value pool being counted as the whole workflow when the model only touches part of it."
      },
      {
        "id": "capture_rate",
        "name": "Assumed share of the value pool you can capture",
        "unit": "percent",
        "howToGet": "Deal desk convention plus what comparable customers have conceded; hold to a modest band until a CFO tells you otherwise, and treat any figure you cannot source as an assumption rather than a norm.",
        "whyItMatters": "It converts a value pool into a defensible ceiling, which is what lets you hold a price without apologising for it."
      },
      {
        "id": "loaded_day_rate",
        "name": "Loaded internal day rate",
        "unit": "currency per person-day",
        "howToGet": "Finance, not your own estimate; it must include overhead or every deal will look more profitable than it is.",
        "whyItMatters": "Human time is the second largest cost and the one most often priced at zero in enthusiasm."
      },
      {
        "id": "target_gross_margin",
        "name": "Target contribution margin for the deal",
        "unit": "percent",
        "howToGet": "Finance or deal desk, as the current threshold for this deal type; POCs and production terms usually carry different thresholds.",
        "whyItMatters": "Without it the floor test degenerates into 'is contribution positive', which passes a deal at zero margin."
      },
      {
        "id": "budget_source",
        "name": "Named budget line and its owner",
        "unit": "name plus budget code or cost centre",
        "howToGet": "Ask directly: which budget does this come from, who signs it, and what else is competing for it this quarter.",
        "whyItMatters": "A price with no identified budget is a forecast, not a deal, and this is the fastest test of whether your champion is the buyer."
      },
      {
        "id": "expansion_map",
        "name": "Named adjacent workflows two and three",
        "unit": "list of workflow names with owners",
        "howToGet": "Ask during discovery, before the first deal is proven and while your leverage is highest.",
        "whyItMatters": "Deal one is rarely attractive on its own arithmetic; the expansion is what makes it work, and it has to be written down to count."
      },
      {
        "id": "reuse_fraction",
        "name": "Share of environment work reusable on the next workflow",
        "unit": "percent of environment_days",
        "howToGet": "Engineering estimate of which adapters, harness, data plumbing and deploy path carry over to the named adjacent workflow; count no eval component in this figure.",
        "whyItMatters": "It is where expansion margin actually comes from, and overstating it, especially by assuming the eval transfers, is how workflow two overruns."
      }
    ],
    "packages": [
      {
        "name": "POC fee",
        "shape": "Fixed fee for a scoped, time-boxed proof measured against an eval agreed in writing before any run starts.",
        "fitsWhen": "The workflow is unproven, the champion needs evidence to raise production budget, and there is a verifier you both believe in.",
        "failsWhen": "Success criteria were left informal, so the readout becomes a debate about whether the result feels good rather than whether the number moved; or the held-out set leaked into training data, so the number that was paid for cannot be reproduced."
      },
      {
        "name": "Platform subscription",
        "shape": "Annual access to the platform SKU, covering {{what the SKU includes and on what seat and support model — confirm with product}}.",
        "fitsWhen": "The customer intends to run many workflows and has, or is hiring, a team that wants the capability in-house.",
        "failsWhen": "Sold to a customer with exactly one workflow and no internal owner; seats go unused and the renewal conversation is a post-mortem."
      },
      {
        "name": "Committed compute with a floor",
        "shape": "Minimum spend over a term, drawn down against usage, with burst capacity priced above the floor.",
        "fitsWhen": "Training volume is real and forecastable, and their procurement function rewards commitment with a better rate.",
        "failsWhen": "The floor was set from the champion's optimistic forecast; unused commitment turns renewal into an argument about credit rather than growth."
      },
      {
        "name": "Outcome or value share",
        "shape": "Payment, or a rebate, tied to a measured movement in an agreed production metric.",
        "fitsWhen": "The metric is already instrumented, owned by a named person, recomputable by a third party given {{verifier_type}}, and attributable to the deployment rather than to their own process changes.",
        "failsWhen": "The customer controls both the measurement and the definition, or the metric moves for unrelated reasons and nobody can adjudicate."
      }
    ],
    "tradeables": [
      {
        "give": "Rate reduction on the POC fee",
        "get": "A named case study with real metrics, approved by their comms team, drafted at the readout while enthusiasm is highest."
      },
      {
        "give": "Rate reduction on the subscription",
        "get": "Logo rights and two reference calls per quarter for the term."
      },
      {
        "give": "Extended payment terms",
        "get": "A multi-year term, or a longer committed compute window at the same floor."
      },
      {
        "give": "Additional applied research days",
        "get": "A written production go or no-go decision date within a fixed window of the readout."
      },
      {
        "give": "Environment construction at reduced cost",
        "get": "Pre-priced commitment to adjacent workflows two and three, signed now rather than renegotiated later."
      },
      {
        "give": "Discounted burst compute above the floor",
        "get": "A higher committed floor, which converts variable revenue into contracted revenue."
      },
      {
        "give": "{{priority scheduling on a scarce accelerator class — confirm with capacity planning that this is offerable}}",
        "get": "Executive sponsorship on the kick-off and a standing monthly review with the economic buyer."
      },
      {
        "give": "A rebate if the agreed eval threshold is missed",
        "get": "A higher headline price and withdrawal of the customer's request for pure outcome-based pricing."
      },
      {
        "give": "{{early access to unreleased platform capability — confirm with product what may be offered and to whom}}",
        "get": "Rights to use their traces and environment patterns, suitably anonymised, to make the next build cheaper."
      },
      {
        "give": "A longer POC window at the same fee",
        "get": "{{customer_sme_days}} committed by name and calendar, signed by the line manager who owns those people."
      }
    ]
  },
  "notes": "This template exists to stop a forward deployed lead quoting a number they cannot reconstruct under pressure. The three failures it is built against are pricing from cost alone, which caps you far below what the workflow is worth; pricing committed compute at expected utilisation, which quietly turns a healthy-looking deal into a loss; and assuming eval work transfers between workflows, which is how expansion margin is discounted away before it is earned. Every figure here is a placeholder, including all of the worked example: replace them from the deal desk before this reaches a customer, and never let a discount leave the table without something coming back across it."
}