The 12-Gate Release Standard
A working demo is not a production release. This standard sets out twelve gates, grouped in four phases, that a BotLane release has to clear. Each gate says what it checks, what evidence it expects, and when it rejects a release.
Evidence, not assertions
Every gate is judged on evidence tied to the exact repository, commit, artifact, environment and policy version being released.
Missing means blocked
Missing, stale or failed evidence never quietly becomes a pass. A gate that doesn't apply needs a reviewed equivalent or an approved exception.
People authorize production
Approving a release's quality and authorizing its deployment are separate human decisions. Irreversible steps always need a person's sign-off.
- 01 / 07
A working demo isn't a release
This update works in the demo. Before it can reach production, it has to clear twelve gates, in four phases, in order.
- 02 / 07
Source: where it comes from
Each gate asks for evidence, not assurances: a verified commit and dependencies, a build that installs the same way every time, a locked-down runtime.
- 03 / 07
Security: what ships, what it sees
The artifact is traced to its source and scanned, every setting is validated, and credentials are checked for exposure, without ever being revealed.
- 04 / 07
Recovery: staying up, coming back
Health checks must notice when something breaks. Backups are restored, not just taken. And there's a tested way back to the last good version.
- 05 / 07
Missing means blocked
The restore drill hasn't been run, so gate 08 blocks the release. Missing evidence never becomes a pass. It waits until the drill exists for this commit.
- 06 / 07
Launch: hardened, accepted, owned
Permissions and exposure are reviewed, tests prove no required sign-off can be bypassed, and runbooks name an owner who answers when something breaks.
- 07 / 07
People authorize production
Every gate holds evidence, and production still waits. Approving quality and authorizing deployment are two separate decisions, made by people.
Full gate reference
Open any gate for the evidence it expects and what gets a release rejected.
01Provenance
Confirm the source, ownership, version and dependencies of what is being released.
- The exact commit, with its signature verified
- A pinned dependency lockfile and its hash
- An archived software bill of materials (SBOM)
- Who wrote and who reviewed the change
The source can't be verified, dependencies float outside the approved policy, or the SBOM is missing.
02Repeatable Installation
Show that it installs the same way every time, from documented steps.
- Logs from a cold build in a clean environment
- Toolchain and environment versions
- Build output checksums across runs
- Install steps and their exit codes
A clean install fails or the build isn't reproducible. Any platform-specific difference is recorded and justified, never papered over.
03Containerization
Package the release into a controlled, portable runtime with minimal privileges.
- The image or bundle identifier
- An inspection of what the runtime contains
- Runtime security settings: unprivileged, read-only where possible
The runtime is unidentified, over-privileged, or not the one that was reviewed.
04OCI Artifacts
Produce versioned, traceable deployment artifacts that can be verified.
- The artifact's immutable digest or version id
- A vulnerability scan with no open critical or high findings
- A signature and provenance attestation that verify
The artifact can't be traced to its source, fails verification, or carries unresolved critical findings.
05Configuration Validation
Validate every setting and reject unsafe or incomplete configuration before it runs.
- A schema validation report for each target environment, with private values redacted
- The version of the schema used
- Tests showing bad configuration is refused
Required settings are missing or malformed, unsafe defaults apply, or unknown settings skip validation.
06Secrets Handling
Store, access and rotate credentials without ever exposing them.
- A secrets scan of code, history and build output
- A review of who and what can read each secret
- How secrets are injected at runtime, redacted
- Rotation records
A credential appears in plain text anywhere, access is broader than needed, or rotation is overdue.
07Health Checks
Verify that the application and the services it depends on are healthy.
- Health signals suited to the runtime
- Synthetic checks that exercise real paths
- Error and latency alerts, and proof they fire
There is no reliable way to tell the service is unhealthy, or alerts aren't verified.
08Backup & Restore
Prove the release can be recovered, not just that a backup exists.
- The backup policy and where backups go
- Logs from a restore drill
- Integrity checks on restored data
- Measured recovery point and recovery time
No restore has been tested, or restored data fails integrity checks.
09Upgrade & Rollback
Upgrade safely and return to a known-good version when something goes wrong.
- The last known-good version
- A rollback rehearsal and its result
- Monitoring during rollout
- Compatibility results for any data migration
There is no tested way back, or a migration can't be reversed safely.
10Security Hardening
Review permissions, network exposure, dependencies and transport security.
- A least-privilege review of every permission
- Dependency findings and how each was handled
- TLS and security header configuration
- Application security tests and an exposure review
Permissions exceed what the release needs, exposure is unreviewed, or known findings are unaddressed.
11Acceptance Testing
Verify functional, integration, safety and human sign-off criteria.
- The test suite revision and its results
- The agreed acceptance scenarios
- Tests confirming that any step set to need human sign-off can't proceed without it
- Results for failure and fallback paths
A required sign-off can be bypassed, or a critical end-to-end scenario fails.
12Documentation & Runbooks
Set out procedures, ownership, monitoring, incident response and recovery.
- Reviewed runbooks
- A named owner and on-call escalation path
- A recovery drill record
- Audit trail retention settings
There is no accountable owner, no recovery process, or the documents contradict how the system actually behaves.
Every gate records one of six outcomes.
Outcomes belong to one release: one commit, one artifact, one environment. A result from an earlier version never carries over.
- Pending
- Evidence hasn't been collected yet.
- Passed
- Current evidence for this exact version meets the gate.
- Failed
- Evidence shows the gate isn't met.
- Blocked
- Evidence is missing or stale. This never becomes a pass.
- Equivalent verified
- The gate was met through a documented, reviewed equivalent for this runtime.
- Exception approved
- A time-limited, reviewed exception. It can't waive a required human sign-off.
What this page is. It describes the standard and the evidence each gate expects. It is not a report on any particular release, and nothing on it should be read as a pass result. Any illustration elsewhere on this site that shows gate results is labelled as illustrative.