A valid API contract can still deliver the wrong paid result.

01 · Structural validation

What API contract and schema testing are good at.

Contract and schema testing help verify interface shape and compatibility: whether expected fields exist, types and structures match the contract, and producer/consumer expectations remain aligned according to the test design.

MOV does not need to replace that stack. Structural checks can remain exactly where they are and can contribute evidence or predicates to a broader acceptance decision.

02 · What structure does not prove

A schema pass does not automatically prove buyer truth.

• Correct entity: a structurally valid response can describe the wrong company, account, asset, or subject.
• Required freshness: a valid payload can contain data that is too old for the buyer's declared use.
• Authoritative source agreement: the payload can be well-formed while contradicting independently retained evidence.
• Buyer-specific value predicates: a field can exist with the correct type and still contain an unacceptable value.
• Sufficient evidence: a payload can be structurally complete while the evidence required for acceptance is missing or non-final.

03 · Same response, different question

Schema: PASS. Buyer acceptance: REJECT.

MOV's reference proof keeps the structural layer green on purpose. The response passes schema validation, but retained authoritative source evidence contradicts an obligation-relevant entity value. The buyer contract therefore rejects the paid result.

PAYMENT       SETTLED   ✓
DELIVERY      DELIVERED ✓
HTTP          200       ✓
SCHEMA        PASS      ✓
BUYER CONTRACT          REJECT ✕
REASON                  MOV.ENTITY.MISMATCH

04 · Assertions vs acceptance boundary

Assertions check values. MOV accepts a paid attempt.

Ordinary application assertions are useful and MOV can run deterministic predicates. The additional product boundary is the binding around those checks: the buyer-owned contract, exact paid attempt, request, delivery, retained evidence, verifier version, and replayable decision remain connected.

05 · Uncertainty

Missing evidence should not become pass/fail certainty.

Structural validation usually answers questions about the payload it can inspect. Runtime Acceptance also has to represent whether the required evidence is sufficient to make the buyer's decision at all.

MOV therefore keeps UNKNOWN as a first-class runtime state. Missing, contradictory, unavailable, corrupt, or non-final required evidence does not silently become ACCEPT and does not have to be misrepresented as a definitive REJECT.

06 · Complement, not replacement

Keep your contract tests. Add Runtime Acceptance where the paid result needs buyer-owned semantics.

The clean architecture is layered. Contract/schema testing can continue to validate structure. Payment evidence can establish economic facts. Delivery evidence can establish what arrived. MOV consumes those facts alongside the buyer contract and any required independent source evidence to decide whether the exact result is acceptable.

payment evidence
+ request identity
+ delivery artifact
+ schema / contract checks
+ independent source evidence when required
+ buyer acceptance contract
+ version-pinned deterministic verifier
= ACCEPT | REJECT | UNKNOWN

07 · Recorded proof

Run the structural-pass / buyer-reject case locally.

The current public release installs from a verified versioned artifact rather than a package registry. The recorded acceptance path performs no network request, purchase, wallet/signer invocation, or runtime-secret read.