01 · Payment truth
What x402 owns — and what it does not.
x402 belongs to the payment side of the machine transaction. It can establish that a machine-service payment path was followed and provide economic evidence that MOV can retain as part of the exact attempt.
That evidence matters, but it is not the buyer's acceptance authority. A successful payment does not establish that the returned entity is the requested entity, that required evidence is fresh, or that another buyer-owned predicate passed.
Core distinction: payment truth ≠ delivery truth ≠ buyer acceptance truth.
02 · The post-payment gap
Everything can look green and the purchase can still be wrong.
MOV's reference proof deliberately keeps the ordinary technical signals green. The payment settles, delivery arrives, HTTP succeeds, and the response structure passes. The buyer contract still rejects the result because obligation-relevant evidence contradicts it.
In the recorded case, MOV returns MOV.ENTITY.MISMATCH. The failure is not "the payment failed." The failure is "the paid result did not satisfy the buyer's precommitted acceptance requirement."
03 · Runtime decision
The agent needs a branchable acceptance state.
Continue
Required evidence is sufficient and every mandatory acceptance predicate passes.
Stop or switch
Evidence is sufficient and at least one mandatory buyer predicate definitively fails.
Reconcile evidence
Required evidence is missing, contradictory, unavailable, corrupt, or non-final.
Decision mapping
One decision engine
The verification engine maps deterministically to buyer-facing ACCEPT | REJECT | UNKNOWN.
04 · When to add acceptance
Add Runtime Acceptance when the paid result has objective requirements.
MOV is strongest when a machine buyer can state what must be true before the transaction and verify those requirements from retained evidence afterward.
- Entity identity: the delivered result must describe the entity the buyer actually requested.
- Freshness: required data must satisfy the buyer's declared freshness boundary.
- Required fields and values: mandatory output facts must satisfy explicit predicates, not merely exist structurally.
- Source policy: where the contract requires independent evidence, the result must agree with the required source evidence.
These are examples of objective acceptance semantics. MOV is not positioned as a generic subjective quality judge for arbitrary LLM output.
05 · Product boundary
MOV does not replace x402.
No custody or payment routing
MOV consumes payment evidence. It does not take custody of buyer funds or become the payment rail.
No x402 protocol clone
MOV is x402-first because paid machine-service results are the initial use case, not because MOV owns the x402 protocol.
No generic LLM judge
The current scope prioritizes objective buyer predicates and deterministic verification.
Local free core
The current public release runs the recorded acceptance path locally without a hosted platform, wallet, or signer requirement.