A failed request does not explain why it failed
A remote catalog read can fail because WordPress is down, a CDN is challenging the caller, a security plugin changed rules, DNS is unstable or the route is temporarily overloaded. None of those events means that the merchant revoked consent. Conversely, an old successful read cannot prove that consent still exists.
Treating reachability as authorization creates two dangerous errors: dropping an authorized merchant because a firewall intervened, or continuing distribution because the last catalog read happened to work before a later revocation.
The architecture now carries three separate proofs
What changed across four Bridge releases
| Release | Change | Failure it addresses |
|---|---|---|
| 1.0.138 | Installation identity, domain proof, signed heartbeat and signed leaving lifecycle. | Global can distinguish an installation from an unauthenticated domain claim. |
| 1.0.139 | Static signed catalog snapshot with bounded fields, atomic publication and freshness metadata. | Discovery can survive a temporarily blocked REST route without scraping HTML or inventing facts. |
| 1.0.140 | Durable consent-delivery retries and recovery of pending receipts. | A short network outage no longer leaves a receipt pending forever after two retries. |
| 1.0.141 | Provider-consent receipts sent through the verified, signed installation channel. | Global no longer needs a successful public discovery read to cryptographically verify the receipt. |
How catalog discovery behaves during an outage
- Prefer current evidence. When the merchant Bridge is reachable, KaliCart can perform the scoped live read allowed by the workflow.
- Use the signed snapshot only inside its contract. The snapshot must belong to the verified installation, pass its signature and hash checks, remain within freshness rules and come from a store eligible for snapshot use.
- Keep provenance visible. Indexed results retain seller identity and snapshot time. The system does not describe them as a current checkout quote.
- Fail explicitly at verification. If the selected product cannot be checked live, the response reports that status instead of guessing current price, stock or shipping.
- Stop when trust expires. A missing, stale, invalid or no-longer-authorized source is not served merely because an older copy exists.
The snapshot is not a firewall bypass
KaliCart does not solve anti-bot challenges, impersonate browsers or route around a merchant’s controls. The static snapshot is produced by the Bridge installation itself and read as a signed publication. It contains a constrained catalog projection, not WordPress credentials, customer data or an administrative API.
This matters for independent stores because shared hosting and security layers vary widely. The resilient path moves availability into a file the merchant deliberately publishes; it does not weaken the boundary around the live store.
Consent no longer depends on discovery reachability
Earlier provider receipts were delivered over HTTPS but were not bound to the installation signature. Global therefore re-read the merchant’s public discovery document before marking a grant or revocation as verified. A CDN challenge could keep a legitimate receipt in an unverifiable state.
Bridge 1.0.141 signs the provider-consent request with the same Ed25519 installation key already verified by the identity lifecycle. Global checks the request signature, installation ID, merchant host, anti-replay request ID and receipt binding. A valid signed receipt can therefore be verified without fetching the public discovery route again.
The compatibility boundary is deliberate: older Bridges continue through the discovery-based route; Bridge 1.0.141 falls back only when the signed route is unavailable because Global is older or the local identity cannot be used. A rejected signature is never bypassed by retrying the unsigned route.
Revocation and outage are no longer the same state
A real revocation stops the provider channel. An unreachable store triggers continued verification and, where necessary, a visible suspension state. Those states are reversible and auditable; neither one rewrites the merchant’s prior authorization history.
Signed receipts verify authorization once delivered. Delivery retries remain bounded and use backoff, so a network failure does not become a request storm. A receipt that was already in a long retry interval before an upgrade may still wait for its scheduled retry; a dedicated delivery-policy epoch is tracked as follow-up work.
What was verified before release
- 14 of 14 signed-consent cases passed against the Global database path.
- 47 of 47 installation-identity cases passed.
- 92 of 92 continuous-verification and suspension cases passed.
- The Bridge identity end-to-end suite and all applicable plugin suites passed.
- WordPress Plugin Check reported zero errors for the release package.
- The WordPress.org 1.0.141 package matched the verified KaliCart release file for file.
The boundary that remains
Resilience is not freshness. A signed snapshot proves origin and integrity; its timestamp says how old it is. It cannot prove that a product remained in stock five minutes later. That is why KaliCart separates candidate discovery from live verification and keeps the merchant checkout authoritative.
The design goal is narrower and more useful: a temporary API failure should not erase an independent store from discovery, and it should never be mistaken for either consent or revocation.