01 · The machine buyer problem
Payment automation does not remove the need for buyer judgment.
When software purchases an API call, MCP tool result, or other machine service, two different questions exist. The first is economic: did the payment happen? The second is semantic: did the delivered result satisfy the buyer's requirements?
Those questions must remain separate. A successful payment, a valid receipt, an HTTP 200 response, or a structurally valid payload can all be useful evidence without being acceptance authority.
Runtime Acceptance for Paid Agent Services: declare what must be true, bind the exact paid attempt and result, evaluate against retained evidence, then branch on ACCEPT, REJECT, or UNKNOWN.
02 · Minimal transaction model
Keep the paid attempt and the acceptance evidence bound together.
Economic event
Payment / transaction evidence
The economic facts for the exact attempt remain visible but do not override acceptance.
Request identity
Exact request fingerprint
The result must be evaluated against the request that actually produced the paid delivery.
Delivery
Exact delivered artifact
Acceptance applies to the result that arrived, not an abstract provider promise.
Evidence
Retained source evidence
When the contract requires independent truth, provenance and source evidence stay bound to the attempt.
Buyer semantics
Acceptance contract
The buyer declares the mandatory predicates before or at transaction initiation.
Determinism
Verifier version + decision
Version-pinned deterministic verification produces a replayable runtime decision.
03 · Ordinary green lights
Why payment, HTTP, delivery, and schema success are insufficient.
Each signal answers a useful but narrower question. Payment can establish an economic fact. Delivery can establish that an artifact arrived. HTTP can establish transport success. Schema validation can establish structural compatibility.
None of them automatically prove that an obligation-relevant entity, freshness rule, source policy, or buyer-specific value predicate passed.
04 · Runtime branching
The acceptance result must be directly usable by software.
const decision = await mov.accept({
contract,
evidence,
delivery,
sourceSnapshots,
decidedAt,
});
switch (decision.decision) {
case "ACCEPT":
continueWorkflow();
break;
case "REJECT":
stopOrSwitchProvider();
break;
case "UNKNOWN":
reconcileEvidence();
break;
}
UNKNOWN is not a softer REJECT and not an optimistic ACCEPT. It means required evidence is missing, contradictory, unavailable, corrupt, or non-final, so the runtime should obtain evidence, reconcile, retry later, or escalate according to the buyer's policy.
05 · Objective use cases
Use Runtime Acceptance where the buyer can define falsifiable requirements.
- Correct entity: the result must refer to the exact company, account, asset, or subject the buyer requested.
- Fresh enough: the delivered data must satisfy the declared freshness boundary.
- Required values: objective value constraints must pass, not merely exist in the payload.
- Required source policy: where independent evidence is mandatory, the delivery must agree with the retained source evidence.
MOV does not currently claim universal safety, subjective quality, or generic LLM-output correctness. The current scope is paid machine-service results with objective buyer-owned acceptance semantics.
06 · Local-first boundary
The released core does not need a wallet, signer, or hosted control plane to evaluate recorded evidence.
The current public release exposes local CLI and TypeScript Runtime Acceptance over recorded evidence. The public local path performs no purchase, signer invocation, runtime-secret read, or custody action.
07 · One real flow
Apply the boundary to one paid machine-service flow.
The local product is free. Paid implementation work is scoped to one flow at a time: define the buyer-owned acceptance contract, build the deterministic verifier path, and produce a recorded proof. A hosted subscription is not offered today.