Skip to content
Resilience GateResilience Gate

RELEASE ENGINEERING / OWNED TESTNET

What earns a release
the right to move forward?

A healthy deployment is the beginning. Follow one candidate through useful traffic, controlled failures, recovery, and the evidence behind its next step.

Understand the system Follow one release Inspect the evidence

A documented lab, with bounded claims. No live status feed.

THE RELEASE QUESTION

  1. 01
    Know the candidateSource, digest, rendered revision.
  2. 02
    Observe useful workPaid traffic before injection.
  3. 03
    Challenge the boundaryPostgreSQL. Redis. Signer.
  4. 04
    Account for the resultScore, recovery, cleanup, eligibility.
Evidence earns eligibility.
Promotion remains a separate decision.

A release is a chain of decisions

Section titled “A release is a chain of decisions”

The application creates short URLs, optionally through an x402 payment. The release platform asks a different question: can this exact candidate do useful work, survive the tested dependency failures, recover, and leave the lab clean?

Source, publication, delivery, verification, and evidence responsibilities
Each handoff answers a different question. An image digest names the candidate; a bounded experiment establishes what happened to it. Source-derived explanation, not a live observation.
Enlarge diagramDiagram source

Choose the depth you need

Section titled “Choose the depth you need”
01 / REVIEW THE SYSTEMConnect the responsibilities.

Learn what the application does, who owns deployment, and what verification establishes.

02 / FOLLOW THE HANDOFFSTrace one candidate.

Follow publication, discovery, rendering, reconciliation, and downstream eligibility.

03 / WORK WITH THE PROJECTStart without credentials.

Validate source and local contracts, then find the procedures for an owned lab.

Read a result in its actual scope

Section titled “Read a result in its actual scope”

The retained records include both a successful release and a deliberately blocked candidate. These are dated observations from an owned lab, rather than current service status.

observedpass

October 3 release verification

Observation: 2026-10-03 · staging 14:37:29–14:46:28 UTC

The verification report summarizes paid preflight, three dependency faults, recovery, and cleanup. The fresh raw bundles are privately retained.

Read the supporting record
historicalfail

A degraded candidate stayed ineligible

Observation: 2026-10-02 · earlier campaign

The historical negative candidate could not prove paid traffic within 75 seconds, so the gate failed before injection. That failure is useful evidence of the decision boundary, with its own identity.

Read the supporting record

Browse the complete reviewed screenshot gallery: 29 canonical captures and five detail companions, displayed with their historical captions, source identities, and original image links.

What the next step requires

Section titled “What the next step requires”

Readiness establishes a starting condition. Actual injection establishes that a fault occurred. Measurements establish how the application behaved. Cleanup establishes a separate operational outcome. Staging verification grants normal downstream eligibility; an operator still requests prod-like promotion.

Learn why a green result can still be insufficient, or follow the Redis fallback and payment consistency boundary in detail.

A precise scope

Section titled “A precise scope”

Resilience Gate demonstrates release engineering on one owned Radius testnet lab. Environments share a cluster. prod means production-like testnet; it does not establish public-production availability, mainnet settlement, custody, disaster recovery, or general chaos coverage. The documentation makes implemented contracts, source tests, historical observations, and uncollected evidence visible separately.

Inspect the limitations, integrated system design, and website implementation report for the exact boundaries and verification state.