The price should follow the proof
Why historical validation should set the scope before a workflow earns a production quote.
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-enabled" 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.
One workflow, staged as evidence
Nodes prices one named workflow from its trigger through approved action and evidence. The commercial unit is the work the buyer can define and inspect, not the number of people who log in or the volume of model calls behind it.
A Decision Replay is an optional historical validation path. It is a read-only evaluation of one repeated decision against historical outcomes. Before it begins, both teams document the decision, outcome, available data, measurement window, success threshold, and stop conditions. Live decisions remain outside that scope. A product walkthrough does not require a prepared dataset.
For a Replay-led engagement, the historical evidence informs whether and how to scope production work. Other responsibilities require an appropriate evaluation of their own. The production quote defines the business process, systems, operating envelope, deployment, implementation, and support. The current pricing page is the commercial source of truth; the agreement specifies costs and obligations.
The license covers an agreed business responsibility. Additional agents, steps, or branches inside that scope do not automatically create another charge. A separate business process or material expansion is agreed before activation. Internal usage is distinct from infrastructure and implementation costs, which need explicit treatment in the quote.
The sequence gives the buyer a checkable result before a production commitment is proposed.
An isolated public price would conceal that boundary. Two workflows can share a label while crossing different systems, approval rules, operating volumes, and security controls. A scoped quote makes those differences visible before either side treats the number as comparable.
What the production quote fixes in writing
A named workflow is specific enough to draw. It has a trigger, approved sources, a defined decision, a named reviewer, a bounded action, and an outcome record. The quote identifies the systems the workflow may read and write, the business units and geographies in scope, the expected operating volume, the controls required for deployment, and the support needed to keep it running. Together, those terms define the license boundary the buyer is purchasing.
That boundary also explains when the price may change. Adding people to an existing approval path does not create another seat charge. Running more model calls does not create a usage bill. A new quote is warranted when the work itself changes: another decision type, a materially broader workflow, a new legal entity or geography, a major system integration, or a different operating requirement. Procurement can compare the change in scope with the change in price without translating seats or tokens into business value.
A negative Decision Replay still produces a useful answer. It may show that the available history cannot support the proposed outcome, that the result does not clear the agreed threshold, or that a data gap must be fixed before a production workflow is credible. The teams can recalibrate or stop. That is materially different from treating every pilot as a sales stage that must end in a platform contract.
What validated actually means
The intended decision trace connects an objective, evidence, authority, and recorded effects so that a later reviewer can reconstruct the case. It should also link subsequent outcomes without equating successful execution with business value. Nodes' broader automated trace and outcome-learning loop remains product direction; a customer result does not by itself demonstrate every runtime component.
At the anchor pilot, a Fortune 500 insurance carrier, the customer's finance team documented $1.58M in Q1 net savings, with CFO validation and the carrier's own definition of what counted as savings. That is customer attribution, not proof that Nodes caused every operational change. The business case uses the customer's approved baseline and attribution rules.
The same discipline, one level up
The proposal economics discussion applies a similar discipline to a workflow. Where evidence supports it, compare the expected benefit and cost of acting with the consequences of waiting. Where it does not, show the uncertainty or ask for more information. The commercial evaluation should make the same distinction between a modeled opportunity and an observed result.
The status quo can have a cost before any vendor enters the room. That cost still needs a supportable baseline. A useful recommendation may be to investigate, wait, or leave a process alone; it does not need a fabricated dollar figure to deserve consideration. Procurement should ask the seller to explain the uncertainty behind its business case as well as the proposed price.
Three questions to ask any vendor selling evidence-based pricing
A buyer evaluating an evidence-based commercial model, from any vendor, has three questions worth asking before signing anything. None of them require the vendor to open the code. The answers are what separate a pricing model from a pitch.
Does the validation stage produce evidence that determines the production scope, or is the first real commitment still based on the vendor's forecast? If historical evaluation has no defined decision, outcome, measurement window, threshold, and stop condition, it cannot reduce the buyer's uncertainty.
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 if the historical evidence does not clear the agreed bar? A Decision Replay should state the decision, evidence threshold, measurement window, and stop conditions before work begins. The buyer should know what a negative result means before committing to a production scope.
The architecture is the product, priced
Before signing, walk through an ordinary improvement inside the agreed process. If the system adds a reviewer, changes a supported step, or reuses a specialist for the same responsibility, ask whether the contract already covers that work. Then contrast it with a genuinely separate business process. Record which change needs a scope discussion and which continues under the existing agreement. Include implementation, infrastructure, support, and retained customer effort in the cost view. A no-token-meter statement should not hide those other costs or imply unlimited unrelated work.
A pricing model that asks for a production commitment 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, moved to the invoice. A vendor whose commercial process mirrors its product's approval discipline, evidence first and production scope second, gives the buyer something more useful than confidence to evaluate.
Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.