Runtime Acceptance for Paid Agent Services
MOV checks the exact paid result against the buyer's requirements before software uses it. Payments answer “Did I pay?” Receipts answer “What did I receive?” MOV answers “Can I use it?”
Paid service attempt
MOV.ENTITY.MISMATCH
The payment cleared and the response arrived. Authoritative source evidence contradicted an obligation-relevant value, so MOV refused acceptance before downstream use.
The missing boundary
Machine commerce already has layers for payment, delivery evidence, API structure, and execution visibility. MOV owns a different decision: whether this exact paid result satisfied the buyer's precommitted requirements.
01
Did I pay?
Payment rails establish economic facts. They do not define whether the delivered result is usable.
02
What did I receive?
Receipts and delivery evidence can bind an interaction or artifact. They do not own the buyer's acceptance semantics.
03
Can I use it?
MOV evaluates the paid result against the buyer-owned contract and returns a decision software can branch on.
Three-state runtime truth
MOV does not turn missing evidence into optimism. UNKNOWN is a
first-class runtime state, separate from acceptance and definitive rejection.
Required evidence is sufficient and every mandatory acceptance predicate passes.
if (decision === "ACCEPT") continue()
Evidence is sufficient and at least one mandatory buyer predicate definitively fails.
if (decision === "REJECT") stop()
Required evidence is missing, contradictory, unavailable, corrupt, or non-final.
if (decision === "UNKNOWN") reconcile()
Buyer-owned acceptance
Acceptance semantics belong to the buyer, not the merchant. MOV keeps the contract, economic event, request, delivery, evidence, and verifier versions bound to the same attempt.
Define the entity, required fields, source policy, freshness, value constraints, and verifier set before or at transaction initiation.
Keep payment or transaction evidence, request fingerprint, delivered artifact, and provenance tied to one durable attempt identity.
Run version-pinned deterministic predicates. When the contract requires external truth, compare against independently acquired source evidence.
Use the verdict directly in software. Payment settlement and transport success remain visible but never override acceptance truth.
Reference proof
The reference case is deliberately boring: structured company data with an objective authoritative source. That makes the acceptance failure falsifiable.
Nothing about the payment or delivery failed. The buyer required a specific
entity truth. The delivered value disagreed with retained authoritative
evidence. MOV returned REJECT with
MOV.ENTITY.MISMATCH.
$ npx mov accept --fixture ./reject.json
{
"decision": "REJECT",
"payment": { "state": "SETTLED" },
"delivery": { "state": "DELIVERED" },
"acceptance": { "state": "REJECT" },
"reason_codes": ["MOV.ENTITY.MISMATCH"]
}Local-first integration
The TypeScript surface reuses the same deterministic evaluator as the CLI. Recorded acceptance performs no network request, signer action, purchase, or secret read.
import { mov } from "@mov/cli";
const decision = await mov.accept({
contract,
evidence,
delivery: { raw: deliveryRaw, value: deliveryJson },
sourceSnapshots,
decidedAt,
});
if (decision.decision === "ACCEPT") {
continueWorkflow();
}1. Install the verified public artifact
npm install https://machineoutcome.com/downloads/mov-runtime-acceptance-0.1.0.tgz
2. Download ACCEPT as accept.json, then run it
npx mov accept --fixture ./accept.json
Install directly from the verified public tarball URL. Recorded examples are separate downloadable JSON inputs, so the package remains small and the acceptance path stays local, registry-unpublished, and capability-inert for live payment.
Different jobs, complementary layers
It adds a buyer-owned acceptance boundary after the paid interaction and before downstream action.
| Layer | Primary job | MOV relationship |
|---|---|---|
| Payment rail | Authorize and settle economic transfer. | Payment evidence is an input, not acceptance authority. |
| Receipt / delivery evidence | Record interaction, delivery, or artifact facts. | Useful provenance can feed the acceptance decision. |
| Contract / schema testing | Check interface and structural compatibility. | Structure can pass while buyer semantics still fail. |
| Observability | Explain what executed and how the system behaved. | A MOV decision can complement traces and operational context. |
| MOV | Evaluate this exact paid result against the buyer's acceptance contract. | Return ACCEPT, REJECT, or UNKNOWN before downstream use. |
Trust less. Inspect more.
Early Runtime Acceptance stays local, explicit, and reproducible. The product does not need your wallet, custody, or a broad hosted control plane to evaluate recorded evidence.
Boundaries
No. Payment and settlement evidence are inputs. MOV evaluates whether the purchased result satisfied the buyer-owned acceptance contract.
No. Those facts can be green while an obligation-relevant entity, freshness, source, or value predicate fails.
MOV returns UNKNOWN when a valid evaluation lacks sufficient final evidence. It does not silently promote ambiguity to acceptance.
No. The recorded CLI and TypeScript acceptance paths perform no purchase, signer action, or runtime-secret read.
No. The current wedge prioritizes objective paid machine-service results and deterministic verification. Subjective generic evaluation is out of scope.
Before the next machine action
Start with one recorded transaction. Keep payment truth and acceptance truth separate.