Measuring Outcomes in AI Sales Contracts

Suppose a vendor sells an AI tool to a contract manufacturer, and the tool drafts inspection reports. The vendor would like part of its payment to depend on results the tool actually produces, not merely on the sale being signed. This is the basic appeal of a value-share arrangement, in which payment is tied to the value that is generated.

The difficulty appears at settlement, when someone has to decide how much the AI actually earned. If the customer's data cannot separate what the AI contributed from everything else happening in the business, both sides can end up arguing about who deserves credit. A simple yes-or-no payment rule gives them no way out of that argument.

This article follows that inspection-report case. The source shows how one design choice, the way the outcome payment was structured, kept the arrangement from collapsing into a dispute. Hold this question in mind as you read: what kind of payment rule lets two parties agree on a fair amount even when they cannot agree on a precise measurement?

Before defining anything, trace what happens to the payment under each rule as the measured outcome changes. Start at zero, move toward the target the contract names, and watch the payment amount at each level. The figure below sets the two structures side by side. Read it from left to right, and ask at each level what the vendor would receive.

Under the graduated structure, the payment tracks the measured result in degrees: more measured outcome means a larger share of the payment. Under the all-or-nothing structure, the payment stays at nothing for every level below the target and then jumps to the full amount once the target is reached. The jump is the defining feature of the binary rule, and it is the point where a disagreement about the measurement becomes expensive for one side.

The source's description of the graduated structure has two parts, and both matter. The first is that the outcomes must be specific and measurable, so there is something concrete to evaluate. The second is that the payment responds to those outcomes in steps or degrees rather than in a single leap. A graduated design does not ask whether value showed up at all. It asks how much of the measured result was achieved and pays accordingly.

It helps to keep two ideas distinct. A value-share contract is one in which the payment is tied to the value generated, and the source gives this as its working definition. The value-share contract describes the relationship: pay is linked to generated value. The graduated outcome payment describes how that link is calculated and settled.

Now trace a messy measurement through the decision. The flowchart shows the sequence of steps when the customer's data cannot isolate the AI's contribution cleanly. Follow the path from the measured outcome to the point where a payment tier is either accepted by both parties or rejected by one side.

The source states that the graduated structure was the engineering that made the value-share contract work. The idea of sharing value was not enough by itself. The payment rule had to be shaped so that it could still be applied when the evidence was imperfect. The before-and-after figure shows what changes between a fragile version and the graduated version the source case used.

In the fragile version, the whole payment depends on one binary reading of uncertain data, so the uncertainty lands directly on the single trigger. In the graduated version, the tiers themselves absorb the uncertainty. Small disagreements about exactly how much was achieved move the payment only within a tier, not across a cliff. That is the sense in which the graduated structure, rather than the value-share idea alone, made the arrangement workable.

Learners often misread what the graduated structure is for. The following mistakes come up repeatedly when people first study this case.