Choose a reading path

The documentation follows one engineering question: what observations justify moving this exact candidate forward? You can approach it as a reviewer, a learner, or an operator. Each route connects explanations to implementation and evidence so that understanding the terminology does not substitute for checking the behavior.

Review the design and the claim

Begin with the overview, then take the system tour. Together they identify what the application does, how a candidate reaches an environment, and where a release decision belongs.

Read healthy versus resilient next. It distinguishes a healthy starting state from observations during a fault, and explains why recovery and cleanup are part of the conclusion. Use the verification report to locate the documented release snapshot, then read the public evidence index and known limitations before interpreting its scope.

For a deeper review, pair the application design with the promotion contract. Ask whether each statement describes implemented behavior, a tested boundary, or a retained live observation. A source link tells you where a mechanism lives; a scorecard tells you what one run measured. Neither alone answers every release question.

At the end of this route you should be able to explain why a digest identifies a candidate, why signature trust is a separate concern, why Argo CD health is insufficient for a staging verdict, and why a successful verification grants normal downstream eligibility without automatically promoting production-like testnet.

Learn through a request and three failures

Start with dependencies and health and recovery. They establish the central distinction between a dependency the application needs for correctness and one it can bypass at some stages of its life.

Follow one paid request, including reuse of an existing destination, settlement, persistence, redirect, and replay. Consult the API reference when you need exact status codes and response shapes.

Then compare the three failure workflows in order:

1. PostgreSQL failure shows essential storage failure, clean 503 responses, process stability, and readiness recovery.
2. Redis failure shows fallback, a latency trade-off, and the observations needed to distinguish an actual outage from ordinary cache misses.
3. Signer failure shows isolation between the application and a paid client’s ability to generate authorizations. A quiet application error counter can coexist with unsuccessful client iterations.

The application design then puts those paths back together into components, data constraints, lifecycle, and consistency limits. Read scorer source with its tests if you want to inspect exact aggregations, validity rules, and fallback-zero queries.

At the end of this route you should be able to identify the failed owner before suggesting a fix, and say which evidence would distinguish degraded service, stopped traffic, broken telemetry, and successful recovery.

Operate from the least external dependency

Begin with the credential-free walkthrough and local development runbook. Source validation and the default Compose stack need no wallet, facilitator, or cloud credentials. They provide useful confidence in local behavior while leaving live delivery and testnet settlement unproven.

Read the configuration reference before preparing a lab procedure. The lab lifecycle runbook explains read-only inspection and the guarded owned-lab boundary. The load runbook explains bounded traffic, prerequisites, and summaries. The chaos-gate runbook explains the supported Kargo verification path, failure handling, and cleanup.

Payments are an explicit opt-in operation. The testnet payment runbook includes requirements that the unpaid Compose exercise cannot establish. This documentation implementation itself does not run paid traffic, mutate Kubernetes, promote Freight, or create cloud resources.

Before interpreting an operational result, read the evidence rules: retain exact candidate identity, label the scenario honestly, review public artifacts, and separate a screenshot’s capture time from the displayed measurement window. Keep the glossary open for terms such as Freight, reconciliation, Permit2, and scorecard.