Inspiration
An AI-generated purchase proposal can look convincing while still naming the wrong price, relying on stale evidence, or preceding the buyer's approval. We wanted to make those different conditions visible and independently testable.
Our earlier H56 work explored deterministic governance computation. This project applies that foundation to a concrete payment workflow: a model proposes, business policy checks the terms, a separate core evaluates host eligibility, and PayPal remains the source of buyer approval and transaction state.
What it does
H56 PayPal accepts a structured purchase proposal from a controlled catalogue or a model. An independent payment-policy layer checks the per-order limit, the offer, the logical payee, and the catalogue price and currency. If those checks pass, H56 evaluates a fixed synthetic host-evidence contract through four native cores: K0 for facts and history, K1 for derived state, C1 for capability contracts and C2 for candidate feasibility.
The saved result is bound to its order, request, evidence and native assessment. A local read-only UI presents the records, and a separate verifier compares the displayed result with the original kernel record.
The PayPal Sandbox route creates an order only after the local execution gate passes. The buyer approves it in their own browser. Before Capture, the executor rechecks the current assessment and the order held by PayPal, including identity, amount, currency and merchant. A pending capture is reported as unsettled rather than successful.
On November 5, 2026, one real DeepSeek proposal continued through payment policy, H56 host assessment, buyer browser approval and a USD 1.00 PayPal Sandbox Capture on the same order. The original proposal and order binding were retained through a fresh assessment before Capture. The server reported COMPLETED and settled=true. 27 linkage checks verify the same-order chain: same-order evidence summary.
How we built it
We created a separate Python project and retained the original 139-member computation closure without algorithm edits, together with its source declaration. The payment application, catalogue, order binding, recovery tools, evidence UI and Sandbox executor were built around that closure.
The AI proposal interface uses an HTTPS OpenAI-compatible provider. Model output is decoded and checked before entering the same policy and native-core path as a catalogue proposal. Service provenance records the returned model, response identity, usage and byte hashes. Mock mode is explicit and exercises the interface without a service call.
All runtime routes use the Python standard library and included vendor sources; no third-party runtime packages are required. A guarded test entry detects Python network attempts, while fresh-run directories, persisted operation intent and stable PayPal request identifiers support inspection and controlled retries.
Challenges we ran into
The main challenge was keeping different facts separate. A business-policy stop must not be presented as a native-core refusal. A host result must not become buyer approval. An uncertain API outcome must not be reported as a completed payment.
Evidence also had to survive review. We added comparisons across saved bytes, request digests and native records, then tested deliberate changes to make sure those comparisons could reject them. Review exposed credential-name case differences on Windows, encoded credential echoes, stale evidence, and deep response structures; focused tests now cover the repaired paths.
Accomplishments that we're proud of
- On November 5, 2026, one real DeepSeek proposal continued through payment policy, H56 host assessment, buyer browser approval and a USD 1.00 PayPal Sandbox Capture. The original proposal and order binding were retained through a fresh assessment before Capture. The server reported COMPLETED and settled=true. Same-order evidence summary.
- A recorded PayPal Sandbox operation on November 3, 2026 completed a USD 1.00 Capture after browser approval and server verification, with three saved host assessments.
- A separate real DeepSeek call on November 4 generated a structured proposal that passed policy, H56 evaluation and independent binding verification. The receipt records deepseek-flash, 511 input tokens and 84 output tokens; the native result is FEASIBLE with 22 returned calls.
- Fresh Python 3.9.13 and 3.13.12 environments each passed selfcheck 6/6 and 263 guarded offline tests with no third-party runtime packages installed and zero detected network attempts. The unused Requests dependency was removed. The core remains byte-identical to its declared source; application Python remains at the ecbad1c code baseline.
The November 5 result is a same-order model-to-Sandbox run, presented in the demonstration video. Host inputs retain the SYNTHETIC_ONLY demonstration grade; Sandbox funds are simulated. The earlier November 3 and 4 records remain available as labelled historical examples.
What we learned
Auditable execution depends on preserving the reason and input behind a decision, not only its final label. It also depends on stopping at the right boundary: before a model call for an unusable local target, before order creation for an inadmissible proposal, and before Capture when the buyer or server-held order does not satisfy the contract.
What's next
We plan to develop versioned host-evidence collectors, richer payment contracts and a guided operator workflow, preserving the separation between proposal, eligibility, authorization and execution.
Log in or sign up for Devpost to join the conversation.