# Machine Outcome Verification Machine Outcome Verification (MOV) is a developer product for **runtime acceptance of paid agent-service results**. North star: > **MOV is the acceptance layer between machine payment and machine action.** Primary question: > **Your agent paid. Should it trust the result?** Current release: **MOV 0.1.0 — public local Runtime Acceptance release.** The exact runtime decision is buyer-facing: ```text ACCEPT | REJECT | UNKNOWN ``` The existing kernel truth remains: ```text PRECOMMITTED BUYER OBLIGATION + PAYMENT / TRANSACTION EVIDENCE + DELIVERY ARTIFACT + INDEPENDENT SOURCE EVIDENCE WHEN REQUIRED + VERSION-PINNED DETERMINISTIC VERIFIERS = VERIFIED | FAILED | UNKNOWN ``` Interface mapping is `VERIFIED -> ACCEPT`, `FAILED -> REJECT`, `UNKNOWN -> UNKNOWN`. Payment, delivery and acceptance remain separate dimensions. This repository is implementation state. Canonical product/governance authority remains in MOV Sources 01–05. See `docs/control/RUNTIME_ACCEPTANCE_WEDGE_LOCK_v1.md` for the current derived wedge reconciliation. ## Product job An agent or software runtime pays an external API, MCP tool or machine service and receives a result. Before that result is used downstream, MOV evaluates the exact purchased result against the buyer's predeclared acceptance requirements. The buyer owns the acceptance semantics. A contract may specify subject/entity, required fields, schema, source policy, freshness, value constraints, economic policy, verifier set and required evidence. Merchant assertions, HTTP 2xx, payment settlement, receipt validity, delivery presence or schema success do not by themselves establish acceptance. Conceptually: ```ts const decision = await mov.accept({ contract, transaction, request, delivery, evidence, }) ``` Runtime branching: ```text ACCEPT -> continue REJECT -> stop / switch provider UNKNOWN -> obtain evidence / reconcile / retry later / escalate ``` ## Canonical proof The existing REL-44 proof demonstrates the product boundary: ```text PAYMENT SETTLED ✓ DELIVERY DELIVERED ✓ HTTP 200 ✓ SCHEMA PASS ✓ BUYER CONTRACT REJECT ✕ REASON MOV.ENTITY.MISMATCH ``` Everything technical succeeded. The purchase was still wrong. MOV caught it before downstream use. ## Public MOV 0.1.0 The canonical public release is local-first and registry-unpublished. Install the exact versioned artifact directly: ```bash npm install https://machineoutcome.com/downloads/mov-runtime-acceptance-0.1.0.tgz ``` Download a recorded ACCEPT fixture as `accept.json`, then run: ```bash npx mov accept --fixture ./accept.json ``` Release metadata and checksum are published alongside the artifact: ```text https://machineoutcome.com/downloads/release.json https://machineoutcome.com/downloads/mov-runtime-acceptance-0.1.0.tgz.sha256 ``` The shipped recorded acceptance path is capability-inert for live payment: it does not move money, invoke a wallet/signer, or read runtime secrets. ## Current release scope The engineering proof and buyer-ready productization are complete. MOV 0.1.0 currently provides: - the preserved deterministic kernel and x402/runtime proof; - an explicit buyer-owned acceptance-contract interface over sound obligation semantics; - the local `mov accept` CLI and TypeScript `mov.accept(...)` facade; - branchable `ACCEPT | REJECT | UNKNOWN` machine output with stable reason codes; - versioned contracts, schemas, evidence envelopes and verifier manifests; - machine-readable discovery through `llms.txt` and `docs/discovery/mov.runtime-acceptance.v1.json`; - a public self-service website, versioned artifact, checksum and recorded examples; - independent-source binding when the buyer contract requires it; - local-first/no-custody boundaries with live payment disabled in the public release. The primary human buyer is a developer/engineering team building autonomous agents that purchase external APIs, MCP tools or machine services. The primary runtime user is software. ## Free core, paid help MOV 0.1.0's current local product is free to download and use. There is no license gate, premium unlock, account requirement or subscription in the released local core. If a team is using MOV on a real paid API / MCP / agent flow and wants help defining the acceptance rules or building a reusable private verifier/acceptance pack, contact `sarmad@machineoutcome.com`. That paid path is intentionally scoped one real flow at a time during WTP-1 validation. There is no fixed public subscription price or hosted paid tier yet. See `docs/commercial/WTP1_PAID_PIPELINE_v1.md` for the Stage-0 commercial pipeline and boundaries. ## Explicitly not authorized yet No generic agent-evaluation platform, generic observability suite, broad API testing product, payment/receipt verifier only, escrow/custody, generic LLM judge, broad dashboard, multi-tenant platform, reputation graph, provider-routing platform or cross-rail abstraction. CI remains a packaging/workflow surface, not the category. ## Development ```bash corepack enable corepack prepare pnpm@11.17.0 --activate pnpm install --frozen-lockfile pnpm check ``` ## Local Runtime Acceptance CLI After `pnpm build`, run the buyer-facing Runtime Acceptance surface against a canonical recorded fixture: ```bash pnpm mov accept --fixture fixtures/verified/clean-company.json ``` `mov accept` emits one canonical `mov.runtime-decision.v1` JSON object with `ACCEPT | REJECT | UNKNOWN`, while preserving payment and delivery as separate dimensions. Stable process exit values remain `0`, `1`, and `2` for the mapped ACCEPT, REJECT, and UNKNOWN decisions. The lower-level kernel-facing verification command remains available and backwards compatible: ```bash pnpm mov verify --fixture fixtures/verified/clean-company.json ``` Run the complete committed failure catalogue: ```bash pnpm mov fixture run fixtures/ ``` `mov verify` continues to emit canonical `VerificationResultV1` with `VERIFIED | FAILED | UNKNOWN`. `mov accept` is a thin deterministic product wrapper over that same recorded verification path; it does not create a second decision engine. Recorded `accept` and `verify` perform no network calls and require no hosted service, database, wallet, signer, runtime secret, or economic action. See `docs/contracts/CLI_CONTRACT_v1.md`. ## TypeScript Runtime Acceptance The public MOV 0.1.0 artifact exposes the same local Runtime Acceptance path as TypeScript: ```ts import { mov } from "@mov/cli"; const decision = await mov.accept({ contract, evidence, delivery: { raw: deliveryRaw, value: deliveryJson, }, sourceSnapshots, decidedAt, }); if (decision.decision === "ACCEPT") { // safe to continue under the buyer contract } ``` In this local v1 facade, `EvidenceEnvelopeV1` carries the exact payment/transaction evidence and request fingerprint, so those facts are not duplicated as independent top-level inputs. Invalid invocation data rejects with `MovAcceptanceInputError`; valid but insufficient evidence returns `UNKNOWN`. The facade performs no evidence acquisition, network request, signing, purchase or economic action. Clean public-tarball installation, CLI ACCEPT/REJECT/UNKNOWN verdict paths and strict TypeScript consumer typecheck are verified release properties. The package is versioned as `0.1.0` and intentionally registry-unpublished; the canonical distribution path is the versioned public tarball above. The semantic TypeScript contract is defined in `docs/contracts/TYPESCRIPT_ACCEPT_CONTRACT_v1.md`. ## Machine-readable discovery MOV keeps a concise `llms.txt` index plus a versioned machine-readable discovery manifest at `docs/discovery/mov.runtime-acceptance.v1.json`. The manifest exposes only verified current surfaces and truth boundaries: the three-state decision mapping, local CLI and public local TypeScript interface, exact schema/contract paths, safety properties, release identity, and explicit non-capabilities. It deliberately marks hosted runtime and continuous acceptance as unauthorized rather than inventing an API that does not exist. There is no OpenAPI document yet because MOV does not currently expose an authorized hosted HTTP API. When such an interface is actually authorized, its machine contract should be generated from the real implementation rather than predeclared speculatively. The public-site build also verifies that every relative `llms.txt` discovery target is present in the bounded deployment artifact before release. ## Product quality bar MOV 0.1.0 is held to a finished narrow-product quality bar: - polished visual and interaction design; - premium website and clear proof narrative; - predictable installation and first-run experience; - clear errors and recovery paths; - deterministic behavior and regression safety; - responsive/current-browser/accessibility quality; - strong documentation and examples; - no placeholder, dead, broken or beta-looking surfaces; - reproducible release evidence. The benchmark is finish quality, not enterprise feature breadth. ## Commercial evidence discipline AI and automated QA can establish implementation/presentation quality. They cannot establish demand, budget ownership, willingness-to-pay or retention. Commercial truth comes from actual independent purchase, activation, repeated runtime use, support behavior and money. The hard company test remains DIY substitution: if a developer can recreate materially equivalent trust, provenance, source/freshness handling, uncertainty, versioning and economic binding with trivial assertions, MOV is not a standalone company. ## Security Never commit credentials or service-role secrets. GitHub Actions secrets are runtime inputs only. See `docs/security/SUPABASE_BOUNDARY.md`.