How ReleaseTwin works
A local runner that proves a release candidate is safe — and a control plane that keeps the history. Execution never leaves your infrastructure.
The two pieces
The CLI loads YAML case files, composes whichever adapters are configured, runs each case's pipeline, and exits non-zero on any failure — safe to wire straight into CI. It runs on your machine or your CI runner. Nothing else is required.
The hosted platform is an optional control plane: self-serve sign-up, projects and API tokens, and a dashboard of uploaded run history and flag-proof results. It is not a test runner — it never executes anything.
What leaves your network
By default, only report metadata is uploaded, and only if you set an API token:
- case ID, oracle reference, fixture hash, pass/fail, failure classification
- never fixture content, request/response bodies, or credentials — the ingest contract has no field for them
You can opt in per project (paid tier) to also upload a redacted evidence document — per-step request/response summaries, assertion detail, screenshots. Redaction runs in your own CLI, before anything is sent: auth headers, credential-shaped fields, and resolved secrets are stripped automatically, plus your own allow/deny rules.
The core mechanics
- Fixture integrity — every case names a fixture by SHA-256; a mismatch fails the case before the pipeline runs.
- Prerequisite ownership — checks are three-state (satisfied / not satisfied / inconclusive) and each names an owner.
- Cleanup — declared per case, runs even when the pipeline fails, no-ops safely when there is nothing to undo.
- Failure classification — a failure is labelled (infrastructure, prerequisite, oracle, …), not just red.
- Flag proof — run the same case known-bad and known-good and report a single discriminating outcome, so a broken build and a fixed one are actually distinguishable.