The price should follow the proof
Why a diagnostic pilot, a platform fee, and an outcome-based price are stages of evidence rather than menu options.
The real question in an enterprise AI pricing conversation is never what does it cost. It is why should we pay before we have seen it work. Every stalled deal I have watched stalls on that mismatch: the vendor is confident, the buyer has no evidence, and the contract asks the buyer to close that gap with trust. Cost is the gate procurement points to, but the actual blocker sitting behind the gate is evidentiary. Nobody wants to be the signature under a number nobody can yet verify, and in a regulated enterprise that signature has a name attached to it long after the deal closes.
The trust exercise wearing a spreadsheet
Outcome-based pricing has become the pitch every enterprise AI vendor is making this year. On paper it sounds like the fix for exactly the problem above: stop asking buyers to pay for promises, pay for results instead. Buyers have started treating the phrase with the same suspicion "AI-powered" earned a couple of years ago, and the suspicion is earned twice over here, because the vendor usually writes both halves of the deal. The vendor defines the outcome. The vendor measures whether it happened. A price tied to a number only the seller can produce is not evidence. It is a new trust exercise, dressed in a spreadsheet instead of a slide deck.
That does not make outcome-based pricing wrong. It means the pricing model only works if something other than the vendor's word stands behind the number, and if the buyer was never asked to bet the whole relationship on that number in the first place. Finance teams have started asking the accounting question out loud: who is the accountant of record when a fee is contingent on an outcome. A vendor with no answer to that question has a pricing model that only survives on faith in the seller.
Three tiers, staged as evidence
Nodes prices in three tiers, and the tiers are not a menu a buyer picks from based on budget. They are stages, and each one only exists because the stage before it produced something to price against.
The Diagnostic Pilot starts from $25K and it is money-back. That price is set low on purpose. Its entire job is to produce evidence a bigger commitment would need, and if it fails to produce that evidence, the buyer does not pay for the attempt. Saying yes to a diagnostic pilot should cost a buyer nothing but time, because nothing is being asked on trust at that stage. There is no claim yet to trust. A buyer who has run one walks away holding something concrete regardless of what happens next: a look at what the system finds inside their own systems of record, on their own data, produced by their own team's cooperation rather than a vendor's slide deck.
The Platform fee, from $200K annual, is only asked for once that evidence exists. By the time a platform conversation starts, the diagnostic pilot has already produced a working answer instead of a promise to fund. The fee funds a deployment of something the buyer has already watched work on their own numbers, not a hypothesis. There is no per-seat charge stacked on top of it, because a per-seat fee prices headcount rather than the outcome the platform produces, and headcount is not what a buyer at this stage is trying to buy.
The Outcome-Based tier prices from 2% of validated impact, a published floor, the same figure the pricing page carries. It does not haggle its way to a different number depending on how the conversation goes, because a haggled number is a negotiation lever, and this tier is not meant to be negotiated, it is meant to be earned. That word, validated, is the whole tier. It only applies once impact has been measured and signed off, a condition the next section earns. A vendor who wants 2% of an outcome only that vendor gets to define is asking for the trust exercise dressed as a percentage. A vendor whose 2% is pinned to a number the customer's own finance team validated is pricing evidence, and the two are not the same transaction even when the percentage on the page looks identical.
Each stage is priced low enough, or gated tightly enough, that the buyer is never the one holding the risk of a claim they cannot yet check.
What validated actually means
Every action the system takes runs through a Decision Trace: a queryable record of what happened, on what data, with what reasoning, and what a human approved. That same mechanism that makes any single recommendation auditable is what produces the number the outcome-based tier prices against: the same trail, read for a different question, rather than a separate reporting layer bolted on for pricing purposes. Ask what happened on a given action and the trace answers it. Ask what the sum of those actions was worth over a quarter and the trace answers that too, because the second question is only the first question aggregated.
At the anchor pilot, a Fortune 500 insurance carrier, Q1 net savings came to $1.58M. That figure was not handed to the customer as a fait accompli. It was signed off by the carrier's own CFO, using the carrier's own numbers, against the carrier's own definition of what counted as savings. That is the whole difference between an outcome claim and an outcome price. Anyone can claim an outcome. Only a customer's own finance function can validate one, and until that validation happens, the outcome-based fee simply does not apply.
The same discipline, one level up
This site has already made the evidence-over-trust argument at the level of a single workflow. When a system proposes an action, the proposal arrives pre-priced: the cost of acting and the cost of waiting both attached, so the human evaluating it is looking at evidence instead of being asked to trust a recommendation. That discipline does not stop at the workflow layer. The pricing model is the same discipline applied to the vendor relationship itself. A buyer should never have to trust Nodes any more than a reviewer inside Nodes' own product should have to trust an agent. At every stage, from the first pilot dollar to the outcome fee, there is something the buyer can inspect rather than something they are asked to believe.
The status quo has its own price, paid in inaction before any vendor is even in the room. What this piece is about is what happens once a vendor is in the room, and whether the price they are asking for has anything standing behind it besides their own confidence. A buyer who has internalized the first argument, that a workflow recommendation without a cost attached is asking for a judgment call rather than a decision, should hold the vendor selling them the workflow to the identical standard.
Three questions to ask any vendor selling outcome-based pricing
A buyer evaluating an outcome-based pitch, from any vendor, has three questions worth asking before signing anything. None of them require the vendor to open the code. All three can be answered in a single conversation, and the answers are what separate a pricing model from a pitch.
Does the cheaper, earlier stage produce evidence the later stage prices against, or is the outcome fee the first real commitment being asked for. If a vendor goes straight to an outcome-based number with no lower-cost stage that produced proof first, there is nothing behind the price but the pitch. A pilot that exists only to build a relationship, rather than to produce a number the next stage can point to, is marketing wearing a contract.
Who measures the outcome the price is tied to: the vendor, or the customer's own system of record. If the only entity capable of confirming the outcome happened is the vendor selling it, the buyer is being asked to grade the vendor's own exam. Ask the vendor directly which system produces the number their fee is calculated against, and ask whether that system belongs to the buyer or the seller.
What happens to the price if the outcome does not materialize. A diagnostic pilot that is not money-back is not really a diagnostic, because a real diagnostic accepts the possibility of a negative result. It is a discount on the trust exercise, still asking the buyer to absorb the risk the vendor should be carrying at that stage.
The architecture is the product, priced
A pricing model that asks for money before evidence exists is not a discount problem procurement can negotiate its way out of. It is the same "trust me" architecture the rest of an enterprise AI pitch runs on, just moved to the invoice, and no amount of negotiating the percentage down fixes an architecture built on a promise instead of a trace. A vendor whose price structure mirrors its product's approval discipline, evidence first, validation before the bill, is the vendor whose product probably works the way it says it does. The invoice is a decision too. It deserves the same trace as any other one.
Saad Bin Shafiq is the founder of Nodes. Anchor pilot: Fortune 500 insurance carrier, four years of production data, 10,765 agents. Methodology: Decision Traces.