An ‘Open’ Standard for Value and Pricing Models Is Vendor-Run

← Back · ACT III · Chapter 15: The Value Lattice System

A new open specification for computable value and pricing models has been published at version 1.0.0. Schemas under Apache 2.0 with an explicit patent grant. Prose under Creative Commons. Public repositories, a published governance policy, an invitation to propose changes. The companion post examined the asymmetry it creates: When AI Agents Buy for You, the Seller’s Agent Defines Your Needs This one is about who governs it.

Everything about the licensing is done properly. The specification’s own page calls the patent grant “the requirement enterprise legal teams look for before approving adoption of an open specification,” and including it signals people who have thought about how standards actually get taken up.

Then read the governance section, which the specification publishes plainly and without evasion. Right now, its originator leads. An independent technical steering committee forms at ten production implementations. Long term, the intent is transfer to the Linux Foundation.

And in the licensing section, one line: permanent attribution to the originator.

Where The Originator Sits

The originator is a value-pricing software vendor. Its commercial product is the tooling that produces and operates the models this specification defines.

Nothing here is hidden. The specification names its originator, publishes its governance stages and states its adoption thresholds, and everything in the previous paragraph came off its own page. What matters is what a buyer agrees to when it conforms.

A specification is a set of decisions about what can be said, not a passive description of the world. It fixes which value drivers exist, what a confidence interval attaches to, what counts as a baseline, how surplus is computed, and what shape an outcome takes. Those decisions are the substance of the thing, and making the file free to read leaves them with whoever wrote them.

The Comparison The Spec Invites

The specification makes its own case by analogy. TCP/IP for data. OpenAPI for APIs. ISO 4217 for currency. The claim is that value and pricing are the last layer of the commerce stack without a standard.

The claim about the gap is correct. In the specification’s words, every B2B deal “rests on a value model that lives in a spreadsheet no other system can read,” and that is a real and expensive problem.

The analogy is where it strains. ISO 4217 is maintained by a standards body with no position in any currency. TCP/IP came out of a process where no participant sold the packets. Those specifications are neutral because their governance is structurally incapable of favoring one party, not because they were published for free.

A specification governed by a participant with a commercial interest in the thing being specified may be excellent, and it may in time become genuinely independent. It is not neutral yet, and the roadmap says so out loud.

Read The Roadmap As A Position Statement

The published roadmap runs in four stages. Version 1.0 delivers value model and pricing model schemas. Version 2.0 adds outcome-based pricing and discounting. Version 3.0 adds credit-based pricing and deal terms. Version 4.0 adds the API layer and an agent-to-agent transaction protocol.

Credit-based pricing is the commercial thesis its originators are publishing books about. It arrives in the specification at version 3.0, at which point it stops being one commercial model among several and becomes part of the layer everything else has to speak.

That is what standards do, and it is precisely why standards are worth contesting early. The layer everyone builds on eventually stops looking like a choice. Buyers who conform at version 1.0 will not be consulted at version 3.0 about whether their pricing model is representable, and by version 4.0 the protocol will be executing transactions on the answer.

Three Questions Before You Conform

Who governs it. Not who wrote it and not who pays for it. Who decides what version 2.0 contains, and what happens if a buyer needs a value driver the specification does not admit.

What can fail it. A standard that no conforming party can fail is only a format. Ask what a non-conforming vendor cannot do, and whether any buyer-side claim is capable of being rejected by the schema.

What happens when the two sides disagree. If the buyer’s baseline and the vendor’s baseline diverge, which one does the schema represent, and which one does the agent compute against. If the answer is that only one baseline has a field, that is the answer to every other question as well.

The Buyer Should Be A Founding Partner Or A Standard-Setter

The specification is openly recruiting founding partners, who get seats on the technical steering committee when it forms. Buyers should take that seriously, because the alternative is conforming later to something they had no hand in.

The stronger move is to hold a standard of your own, declared before any vendor model is admitted, so that any schema, open or proprietary, has to prove itself against it. A seat on another party’s committee helps, and it does not replace that.

A buyer with its own standard can adopt an open specification on the merits and walk away from it when the merits change. A buyer without one ends up taking on the originator’s position along with the schema.

A free license settles who may use the specification and leaves open who decides what it says.

Sources: thevalueproject.org, open specification for computable value models and pricing models, v1.0.0, read in full 11 August 2026. All governance, licensing, and roadmap statements quoted or paraphrased above are published on that specification’s own site: schemas under Apache 2.0 with patent grant, prose under CC BY 4.0, permanent attribution to the originator, originator-led governance until an independent technical steering committee forms at ten production implementations, with long-term intent to transfer to the Linux Foundation, and a four-stage roadmap ending in an agent-to-agent transaction protocol.

Keep reading: ACT III · Chapter 15: The Value Lattice System