The October 3 recorded release

Question: Did the exact v1.0.0 application candidate complete fresh staging verification, then a separately requested production-like testnet promotion with successful post-deploy health checks?

The recorded verification report answers yes for the private owned Radius testnet lab on 3 October 2026. Staging exercised bounded paid traffic and sequential PostgreSQL, Redis, and signer pod failures. Prod-like promotion then checked readiness and liveness. This page preserves that candidate and its UTC windows; the historical October 2 campaigns remain separate.

The public record consists of the reviewed report, evidence index, and hash-bound screenshots. The two fresh sanitized bundles contain 36 files and two schema-valid metadata records retained in a private external archive. Their raw scorecards, Kubernetes extracts, and cleanup receipts are not published in this checkout. This narrative reports the reviewed result; it does not offer public recomputation of that private collection.

One candidate, several identities

Identity	Recorded value
Application tag/source	v1.0.0 / 3b70835335462f1b6f9b1dd17ab20d1108724f89
Platform source snapshot	7ea5e911aba159966b2a54657c501a8e643ee18f
Chart/source commit carried in Freight	0a98c08ccab5fa7b05efcecf877c714e5c89f025
Freight	d3b4380d40e87e244162da80aae9eb90503be15d (hoping-warthog)
Application OCI digest	sha256:ab88d89c20ccf1a79b9f47f90aa417ac0f54d7852c39b444b7fb788975fdd6a1
Staging rendered revision	64d2ddedb1493e0c59aef9ecad0ad0a2ff4196cf
Prod rendered revision	7d334d5a05e747cabff59d28de75e73534afe578

These values identify different responsibilities. The platform snapshot includes changes after the application tag. Freight combines a chart source and image; Kargo’s render creates a distinct commit for each environment. Inferring one identity from another would obscure what actually moved forward.

Staging earned normal downstream eligibility

The fresh staging bundle is identified as v1-screenshot-20261003T143702Z. Its Promotion staging.01m4134wftvmjnsgvvgzpbenbq.d3b4380 was recorded Succeeded. AnalysisRun staging.01m4135pfqh94e76vzzn7fpbs4.d58be07 was Successful over 2026-10-03T14:37:29Z–14:46:28Z.

Observation	Reviewed result
Gate Job	e01beb57-aa6c-4f51-84e9-e91fd3382676.chaos-verdict.1 succeeded
Before injection	Meaningful paid traffic was established
PostgreSQL fault	Applied at 14:39:11Z; fault/recovery scorecard passed
Redis fault	Applied at 14:42:11Z; fault/recovery scorecard passed
Signer fault	Applied at 14:44:11Z; fault/recovery scorecard passed
Gate	GATE VERDICT: PASS
Reconciliation	resilience-gate-staging Synced / Healthy at 64d2dde

The result joins meaningful work with the intended faults and measured recovery. It does not rely solely on the app remaining green. PostgreSQL protects persistence, Redis accelerates lookup, and the signer enables the client’s paid requests; their failures have different consequences. Inside the gate and the three failure workflows explain why the observations differ.

Cleanup was part of the accepted run. Workflow chaos-gate-hcc49 and load Job loadgen-311c93f7-bfac-4ccb-a546-92cccb187b45 were automatically removed. The source CronJob stayed suspended, and no gate Lease, WorkflowNode, or PodChaos remained. These are reviewed report statements; the private receipts carry their detailed execution proof.

The conclusion was eligibility of this Freight through normal upstream verification. It was not automatic prod promotion. The next handoff required an explicit operator request.

Prod-like smoke answered a narrower question

The prod bundle is v1-prod-screenshot-20261003T153428Z. Promotion prod.01m416e19hks7jnsbca6m49ae9.d3b4380 succeeded over 15:34:28Z–15:34:37Z. AnalysisRun prod.01m416ezeke4d89a42wkqefzv9.d58be07 was Successful over 2026-10-03T15:34:59Z–15:35:29Z.

Readiness and liveness were both Successful. Argo CD reported resilience-gate-prod Synced / Healthy at 7d334d5; application replicas were 3/3, PostgreSQL 1/1, and Redis 1/1. This smoke requested no paid load and no chaos. Its resilience context came from staging verification of the same Freight, not from repeating fault injection in prod.

The fixed existing two-node cluster was neither created nor resized for this campaign. All three Stages ended Steady and Healthy on the same Freight. The final report records no active Promotions, AnalysisRuns, gate/load Jobs, run-scoped fault objects, or Lease, while completed history remained where available. Prod had no load-generator CronJob.

What a public reviewer can inspect

The manifest names fresh-alignment views 09, 10, 11, 14, 14b, and 29. They illustrate GitOps state, staging verification, shared Freight, and the prod resource tree with immutable identity and capture time. The gallery exposes those reviewed records and their captions.

Screenshot 29 was captured at 17:22:51Z, later than the prod verification window. The capture corroborates visible later reconciliation state, not the exact measurement timestamps. Screenshot 26 records an earlier cleanup snapshot at 14:14:31Z, before this fresh staging run began; it must not be presented as that run’s cleanup receipt. Historical Grafana payment/failure/recovery images retain their earlier candidate and UTC window.

All 34 accepted screenshot PNG hashes were rechecked at 2026-10-03T17:26:01Z. That is a screenshot audit timestamp, not a new gate execution. Selected earlier public scorecards demonstrate the actual file format, but are evidence for their own earlier release identity.

Meaning and limits of the decision

The accepted statement is narrow: the report records successful staging fault/recovery verification and subsequent prod-like health verification for the exact candidate above in one owned testnet lab. It does not prove mainnet payments, public-production suitability, multi-region availability, backup restoration, concurrent-fault resilience, or permanent health after the snapshot.

The recorded source/CI checks and reviewed public views increase traceability. They do not create an independent signature-enforcing admission policy, publish private scorecards, or make settlement and URL persistence atomic. See limits of the claim, then use follow one release to connect this record to the implementation.