One day, sixteen deploys: the R-Series goes live end to end

This is the first of a new series: every week, a plain account of what actually went live, what's still dark behind a flag, and what we deliberately did not ship. No roadmap language. If something in this post can't be checked from the outside, we say so explicitly.

June 4–5 was the densest shipping window since launch. Across roughly twenty-four hours, the R-Series went from "verified in the sandbox" to "running in production end to end" — API, cryptography, verify app, and the legacy site, in that order.

What shipped

1 · Trust SKU verification API — live on api.dcslabs.ai

The first commercial surface for R+2 verification is in production. The catalog and detect endpoints were smoke-tested directly against the live deployment on api.dcslabs.ai, the database migration is applied, and the feature flag is on. This is the API that lets an integrator submit a receipt and get a verification verdict from our infrastructure instead of running the verifier locally — useful when you want a third party on the hook for the answer.

Alongside it, the same wiring wave brought a Redis-backed rate limiter, interop detection for SCITT/AP2/AAT-shaped payloads, and status-list proof support for wallet credentials. One deploy, smoke-tested in production before anything else moved.

2 · Post-quantum hybrid co-signatures — deployed dark

The R+3 ML-DSA co-signature path went live on the r3-service on June 4, additive and behind its own flags. Later that night, the bigger piece followed: hybrid post-quantum receipts — every receipt carries its classical Ed25519 signature plus an ML-DSA co-signature — were wired into the production API and deployed dark.

"Dark" means exactly what it sounds like: the code is running in production, but the PQ leg is disabled by its flag. Before the deploy was allowed, the change had to pass an 8-verifier regression gate — eight independent verifier configurations all had to confirm that the PQ leg is purely additive, that the content identifier of every receipt stays stable, and that legacy output is byte-identical with the flag off. After deploy, a dark smoke test confirmed the live health and catalog responses are byte-identical to before. The flag stays off until the soak period is done and the integrator green-lights the flip.

3 · The verify app, rebuilt

The public verification surface at verify.dcslabs.ai went through four production uploads across the window. It now ships as an installable PWA with offline support, a rebuilt docs section, a knowledge base, proper 404/500 pages, search, and — the part we're most attached to — a status page generated at build time from real checks, not a hand-edited "all systems operational" banner. If a check didn't run green at build time, the page says so.

4 · a legacy property moved to the new stack

A legacy web property was migrated onto the same deployment pipeline and shared navigation contract as the rest of the stack, with performance and metadata fixes in the same wave. One pipeline, one set of CI gates, every property.

The discipline that made it safe

Sixteen production deploys in a day sounds reckless. It wasn't, because every one of them went through the same four rules — rules we adopted precisely so that a high-velocity day doesn't become a high-risk day.

• Sandbox-prove before deploy. Nothing reaches production until the exact change has been proven in an isolated environment — for the PQ work, that meant a 13-check sandbox proof plus a full API round-trip (hybrid receipt valid, co-signature present, content ID stable, legacy path byte-identical) before railway up was even typed.
• Flags default-off. New capability ships disabled. The Trust SKU flag was flipped on only after production smoke tests; the PQ flag, the business-backend flag, and the settlement flags are all still off, on purpose, until their gates clear.
• One flip at a time. Flags get enabled individually, each with its own smoke test and its own rollback, never as a batch. If something regresses, we know exactly which flip did it.
• The integrator reruns everything. No coworker's test results are taken on faith. Every delivered suite is rerun from scratch by the integrator before anything is marked verified — across the build phase and rounds three through seven, that's 1,400+ checks (internal, integrator-rerun), every one green before its work item was allowed near a deploy queue.

The rule isn't "ship fast." The rule is "prove first, ship behind a flag, flip one thing at a time, and let someone else rerun your tests." Fast is just what that looks like when the queue is deep.

What is not live (and we want you to know it)

The week behind the day

The shipping day was the visible tip of a wider verification push. Over the same window, the integrator audited and reran rounds three through seven of coworker deliveries — site builds, crypto continuity suites, commercial and conformance packs, evaluation fixtures, and sovereign-pilot drills — all green on rerun. Technical Note TN-001, our evidence write-up for the R+2 anchor path, reached citation-complete status with its on-chain transaction hash and green CI run URL filled in; it publishes after a final read. The master pending roadmap stands at 45% cleared, and a 20-step deploy plan now maps the next three calendar waves, each step with its own test and rollback.

That's the cadence we intend to keep: build verified, deploy dark, flip deliberately, and write it up here every week — including the weeks where the honest-limits section is longer than the shipped section.

— Deepak