REWIND — Rollback Safety Before Release

• 

  01 / The problem: candidate writes can break old-code reads. Explanatory diagram of the tested PostgreSQL contract.

• 

  02 / Actual GitLab capture: the failed child has only gate_blocked. No release job exists; the failed attempt builds no image.

• 

  03 / Actual GitLab capture: Duo proposes, automation validates and commits. Only candidate-plan.json changes; full validation reruns.

• 

  04 / Actual GitLab capture: immutable image, candidate health, production health, then a real Release with linked proof.

Inspiration

A release can pass its own tests and still make rollback unsafe. New code writes a new data shape; the old container comes back, but the old code can no longer read the database. Container rollback alone cannot reverse those writes.

REWIND is built for engineers releasing applications with shared, evolving data contracts. It asks a concrete question before release: can yesterday's code still operate on the state today's code will create?

What it does

REWIND runs a stable-to-candidate migration and write rehearsal in disposable PostgreSQL 16.15, then executes the old application contract against the new data. A deterministic gate requires compatibility, rollback invariants, unchanged source evidence, and successful native GitLab Secret Detection.

On failure, the generated child pipeline contains only a blocking job. There is no release job. GitLab Duo receives the precise failure and a one-file repair scope: candidate-plan.json. Automation independently validates the proposed Git tree and allowed operation, commits the repair, and explicitly starts a new pipeline on the repaired SHA. The entire rehearsal runs again. Duo never decides whether a release is safe.

A passing candidate is packaged by immutable image digest. REWIND deploys an isolated Railway candidate and checks exact commit, plan, build and role identity three times. Only then does it update production. Three production health samples must pass before GitLab Release creation. The release links the proof artifact and native Release Evidence.

How we built it

GitLab CI is the durable orchestrator; GitLab Duo Agent Platform supplies bounded repair reasoning. Python implements the rehearsal, diff validator and release controller. PostgreSQL provides the real migration/data contract. GitLab Container Registry publishes the immutable image; Railway hosts separate candidate and production services.

The permitted repair adds customer_name as an alias of display_name without overwriting conflicting existing values. A conflicting case remains blocked and exhausts the two-attempt budget. We also proved that an HTTP 200 response and native deployment success are insufficient: a wrong candidate runtime identity blocks promotion and leaves production unchanged.

Latest working evidence — October 23

An independent October 23 replay after security hardening repeated the full hands-off path: unsafe attempt 0 blocked, Duo session 9958274, automated repair commit cae3031950c1a1f877832cd757e7e228aed6753e, repaired pipeline with 225 passing tests, and verified Railway Release. A separate candidate identity-fault run failed closed after its PostgreSQL/security gate passed; it did not promote production or create a successful Release. The positive and negative proof artifacts are public. The video uses authentic GitLab footage from the earlier completed run and clearly labeled receipt summaries for the independent October 23 replay; the later summaries are not live screen recordings.

Earlier integrated evidence — October 17

The complete integrated run starts at original SHA 087ffa3f2f97b04854993b6125e2a3e83640887b:

• Attempt 0 — incompatible state blocked
• Duo session 9628389, with independently validated diff
• Repair SHA e1193cb1e5f69ab1045ef32c638c4dcaa2c7ef04, created by automation without human repair edits
• Repaired pipeline — PostgreSQL, 108 native tests, security and release PASS
• Real GitLab Release, including release-proof.json and native Release Evidence
• Separate live health-failure and unchanged-production evidence

Public repository receipts preserve both attempts and the earlier exhausted negative case. Duo session pages may require an authorized account; their non-secret receipts are preserved publicly. An offline audit checks 29 integrated receipts without credentials or network access. Receipts document history; they cannot authorize a new release.

Additional recorded walkthroughs (optional)

The first walkthrough (October 17, 2:38) and second walkthrough (October 18, 2:49) show earlier completed GitLab runs. They are supplementary recordings; the embedded October 23 video remains the main demo, and the linked pipelines and proof artifacts are authoritative for the latest run.

Challenges and lessons

The important boundary is between proposing a repair and granting release authority. We enforced the repair as a strict plan schema and Git diff, rather than trusting a model's claim that it fixed the problem. Explicit pipeline creation also avoids relying on CI_JOB_TOKEN pushes to trigger another pipeline or on dotenv values inside rules.

Google Cloud signup was unavailable to this participant. We preserved the keyless Cloud Run implementation and demonstrated the actual release on Railway instead. No Google Cloud deployment or bonus is claimed. Temporary GitLab and Railway credentials were revoked and their CI variables removed after the proof.

Lifecycle coverage

Plan: bounded repair intent and compatibility plan. Create: Duo proposal and automated repair commit. Verify: PostgreSQL rehearsal and tests. Package: immutable registry image. Secure: native Secret Detection. Release: verified production deployment and GitLab Release. Configure: provider service and runtime identity. Monitor: deterministic deployment-time health probes. Govern: lineage, fail-closed decisions and native Release Evidence. These claims are linked in the repository stage ledger; monitoring is not continuous observability.

Accomplishments and limits

One initial unsafe candidate completed the hands-off loop to a real release. Original tests and fixtures were not changed to manufacture success. Both incompatible-data and health-failure cases demonstrate prevention, not merely a green happy path.

This is a bounded release-safety implementation, not a universal migration repair engine. The small hosted health-contract app does not host the ephemeral rehearsal database. Railway uses isolated services rather than Cloud Run revision traffic splitting, and trial hosting is finite. A production organization would separately protect the trusted verifier and candidate boundary. No measured financial savings, carbon reductions or unrestricted production readiness are claimed.

What's next

Broader migration contracts, organizationally protected verifier execution, and sustainable hosting beyond the trial are future work. The current submission stays focused on a reproducible, evidence-backed unsafe-change-to-safe-release workflow.

Built With

• docker
• gitlab
• gitlab-duo
• postgresql
• python
• railway