Skip to main content
In development. No pass is complete. Nothing on this site has earned Stable. See maturity levels.
Plenty of software calls itself production-ready because the tests are green. Green tests prove the code does what its author expected. They prove nothing about what a payment provider does at 2am when a webhook arrives twice. So 86d does not let a capability call itself Stable on tests. It has to run the real merchant path, in production, against live providers, and produce a record of what happened. This page is the bar. It is written down publicly so you can hold 86d to it.

​
Three passes

The same merchant path, proven three times, each one gating something different. Pass two is the live Console rehearsal. The final reset follows it, and pass three recreates the Store through the agent flow. Genuine activity and marketed launch wait for both passes and 86d Payments readiness.

​
What a pass has to produce

Every one of these, actually happening, not simulated and not inferred from a queue accepting a job:
  • a Store provisioned, deployed, and serving a page
  • a custom domain activated
  • one live payment
  • one tax decision made by the server against a registration the merchant attested to
  • one real shipping quote against a normalized address
  • a Checkout that completes and creates an Order
  • one Inventory deduction, exactly once
  • one physical Fulfillment, with one label and one tracking record linked to it
  • Customer history, and a guest Order attaching to an account created afterward
  • Loyalty earning, or a deliberate disabled state that is visible to the Shopper
  • one transactional email reaching a Shopper
  • one alert reaching the merchant
Across passes two and three, two more:
  • one confirmed refund with correct Payment, tax, Inventory, Loyalty, Order, and fee adjustments
  • one ambiguous or retried operation that produces no duplicate Order, Payment, label, notification, or ledger entry
Card, Apple Pay, Google Pay, and PayPal each need their own live test before any of them is advertised.

​
What gets recorded

Each entry in the evidence register identifies: The register is append-only. Correction and invalidation append linked entries and advance a head projection; they never edit an observation. Dates in the current-state table come only from the effective passed Local, Console, or Agent entries. A pass closes only from a passed pass seal. Unit tests, fixtures, and dry runs cannot write those cells. A screenshot does not advance a gate. Neither does a verbal report, a sandbox result, or a job being accepted into a queue.

​
Genuine activity, specifically

At least one Customer and one completed Order have to come from a real Shopper who is not someone at 86d running a test, using a live payment and ordinary fulfillment. Sandbox records and internal smoke purchases are useful evidence for the specific thing they check. They do not satisfy this one, because the entire point is to find out what happens when someone who does not know how the system works uses it.

​
The go or no-go list

86d does not make a marketed launch claim until all of these are true:
  • passes two and three complete in reset order, with 86d Payments card, Apple Pay, Google Pay, fee, refund, verified-event, and settlement/reconciliation evidence
  • genuine customer and Order evidence exists
  • every launch-critical capability has earned Stable
  • repository health gates pass for the deployed source
  • export, suspension, restoration, and destruction all work
  • published pricing, terms, privacy, refund, and service descriptions match the product
  • no known path accepts an unsigned provider event, a money value supplied by a Shopper, a missing tax decision, or a missing shipping quote
Unrelated Beta and Experimental Modules do not block any of this. Maturity is per capability.