Know what the result means.

A complete test in three steps.

1. Compile and confirm the intent.

   Use the example instruction in the test lab. Review the extracted constraints, then confirm them. The run uses this locked contract.

2. Choose a controlled fault.

   A variant fault changes medium to small. A shipping fault pushes the delivered total beyond the limit. The no-fault case keeps the state unchanged.

3. Inspect the decision.

   Open a lineage value or timeline event to see the source observation. Check the payment panel to distinguish simulated behavior from provider evidence.

Make the failure cases executable.

The readiness bench executes twelve synthetic scenarios against the shared contract and payment-binding engine. It covers exact budget boundaries, wrong variants and quantities, missing or stale evidence, subscriptions, inventory and mismatched payment bindings. Run the suite to see actual decisions; the initial screen reports zero executed cases.

The what-if controls change only bounded checkout facts under the unchanged contract. Reports include exact inputs and hashes for reproduction. No agent, PayPal request, capture or void is invoked by this bench.

The Postman collection checks this bounded HTTP surface and forbidden public financial commands. Provider qualification remains a separate task. The judge workbench lists accessible saved records with separate authorization, capture and merchant-order facts.

An instruction becomes a contract.

The intent contract is a structured version of what the shopper is allowed to do. It separates exact constraints from unresolved information. A candidate contract needs human confirmation before execution.

The model does not approve its own purchase. The evaluator checks the recorded state using deterministic rules. A missing required hard constraint cannot be treated as satisfied.

In local simulation, the compiler supports a fixed example. It does not claim general language understanding.

Start with the first divergence.

Intent Lineage aligns the same attributes across checkpoints. A highlighted cell shows where the observed value first moves outside the displayed constraint. Later cells keep that divergence visible.

Allow

The available required checks passed for that exact attempt. Read the payment state separately.

Deny

At least one hard constraint failed. The reason and recorded observation explain the block.

Review

Required evidence is missing or unresolved. The attempt must not proceed to capture.

Raw evidence includes the run environment. A local payload is a local observation; it is not a PayPal response or proof of a real payment.

Authorization and capture are different facts.

A PayPal authorization is not the completed charge. The Sandbox integration can verify a transaction before deciding whether to capture it. Denied authorizations require their own cancellation and status reconciliation.

Sandbox funds are not real money. A successful Sandbox run does not certify a production integration.

Recover without changing the promise.

The wrong-variant case supports one bounded recovery: restore the exact confirmed variant and verify a fresh attempt. The original size, quantity, and spending limit remain fixed.

Recovery creates another run. Compare both to inspect the changed state and decision. A recovery from an injected fault does not prove that an underlying merchant defect has been fixed.

Specific proof. Explicit limits.

• This is a controlled merchant prototype, not a production payment service.
• Seeded faults demonstrate particular behaviors; they do not measure how often those failures occur in real commerce.
• A confirmed contract can still misrepresent the original instruction. Review matters.
• A hash can identify unchanged evidence; it does not establish that the source observation was truthful.
• Local simulation does not prove live AI execution, real browser execution, or PayPal connectivity.
• Recorded runs demonstrate their own environment and configuration, not universal agent reliability.