Launch Readiness and Quality Gates
Draft 0.1 — 2 August 2026
Passing a launch gate means a defined review was completed against a defined profile. It is not a warranty, certification, legal opinion, or promise that no defect or incident will occur.
Objective
Section titled “Objective”ANUKA products need a common answer to a deceptively simple question:
What must be true before we expose this change to real people, real data, or real money?
Launch readiness turns that question into a versioned evidence record rather than a meeting driven by confidence and calendar pressure.
Launch types
Section titled “Launch types”L0 — Internal prototype
Section titled “L0 — Internal prototype”Characteristics:
- synthetic, public, or tightly controlled data;
- no customer money;
- no external promises;
- no high-impact decisions;
- small internal audience;
- disposable environment.
L1 — Controlled pilot
Section titled “L1 — Controlled pilot”Characteristics:
- invited participants;
- explicit experimental notice;
- bounded data and transaction limits;
- active monitoring;
- direct support;
- feature flags and rollback;
- predefined stop criteria.
L2 — Limited production
Section titled “L2 — Limited production”Characteristics:
- real users and production data;
- limited geography, cohort, or capability;
- support and incident processes active;
- public terms and notices in effect;
- measured reliability target;
- controlled expansion.
L3 — General availability
Section titled “L3 — General availability”Characteristics:
- broadly available within declared markets;
- normal commercial and support commitments;
- stable contracts;
- production SLOs;
- recurring review and maintenance obligations.
L4 — Critical or high-impact production
Section titled “L4 — Critical or high-impact production”Applies when failure or misuse can materially affect:
- money;
- identity;
- employment or eligibility;
- sensitive data;
- public safety;
- legal rights;
- multiple Resident products;
- network governance.
L4 requires stronger independent review, approval, observability, recovery, and human accountability.
Gate philosophy
Section titled “Gate philosophy”A gate must be:
- proportional to risk;
- evidence-based;
- owned;
- time-bounded;
- reproducible;
- capable of failing;
- explicit about exceptions;
- linked to rollback and post-launch review.
A gate that always passes is a ritual, not a control.
Gate record
Section titled “Gate record”Every launch creates a Launch Readiness Record containing:
- launch ID;
- product and environment;
- release or change identifiers;
- launch type;
- intended users and jurisdictions;
- capabilities enabled;
- data classes;
- financial exposure;
- risk classification;
- evidence package;
- gate outcomes;
- exceptions;
- approvers and authority;
- rollout plan;
- stop conditions;
- rollback plan;
- launch window;
- review date.
Gate outcome states
Section titled “Gate outcome states”- pass — requirements satisfied;
- pass with conditions — launch allowed with explicit conditions and expiry;
- defer — evidence incomplete or launch not currently justified;
- fail — unacceptable unresolved risk;
- not applicable — requirement does not apply, with explanation;
- emergency exception — temporary risk acceptance through emergency authority.
Gate 1 — Product clarity
Section titled “Gate 1 — Product clarity”Required evidence:
- problem and intended users;
- user journeys;
- product scope and exclusions;
- launch cohort;
- pricing and commercial terms where applicable;
- current limitations;
- success and guardrail metrics;
- support expectations;
- claim inventory.
Questions:
- Can a user understand what the product does?
- Are experimental and production states distinguishable?
- Are outcomes and limitations stated honestly?
- Are irreversible actions clearly marked?
- Are cancellation, refund, export, and exit paths visible?
Gate 2 — Authority and governance
Section titled “Gate 2 — Authority and governance”Required evidence:
- current Product Charter;
- operator and legal owner;
- release authority;
- data-publication authority;
- payment authority;
- incident authority;
- conflict disclosures;
- founder or steward reserved powers;
- decision record.
No launch may rely on an approver who lacks actual authority.
Gate 3 — Identity, consent, and authorization
Section titled “Gate 3 — Identity, consent, and authorization”Required evidence:
- authentication flows;
- role and capability matrix;
- consent request schemas;
- partial approval behavior;
- revocation behavior;
- recovery and account-transfer behavior;
- agent principal binding;
- sensitive-action step-up;
- authorization tests.
Critical checks:
- no full Passport disclosure by default;
- source access is distinct from one-time presentation;
- least privilege applies;
- denied or revoked consent is enforced;
- authorization is server-side;
- A4 agent actions require human approval.
Gate 4 — Privacy and data governance
Section titled “Gate 4 — Privacy and data governance”Required evidence:
- current data inventory;
- purpose and legal/contractual basis analysis where required;
- classification;
- retention;
- processors and recipients;
- data residency or region assumptions;
- deletion and correction flows;
- training-use and model-provider rules;
- public-data controls;
- privacy notice consistency.
A launch fails if actual production behavior materially contradicts the notice or consent interface.
Gate 5 — Security verification
Section titled “Gate 5 — Security verification”The product selects a versioned security profile.
Default direction:
- ordinary web application: OWASP ASVS 5.0.0 Level 1 baseline plus risk-selected Level 2 requirements;
- products handling sensitive or material transactions: stronger Level 2 or tailored Level 3 requirements;
- shared infrastructure: architecture, operations, supply-chain, and recovery controls in addition to application checks.
Required evidence may include:
- threat model;
- ASVS requirement results;
- authentication and authorization tests;
- dependency and secret scans;
- code review;
- abuse-case tests;
- rate-limit tests;
- penetration testing where justified;
- security findings and disposition;
- vulnerability disclosure path;
- incident exercise.
ASVS references must include the exact version and requirement identifier.
Gate 6 — Secure software supply chain
Section titled “Gate 6 — Secure software supply chain”Required evidence:
- protected source branches;
- required review;
- lockfiles;
- dependency policy;
- secret scanning;
- build isolation;
- artifact digest;
- SBOM profile;
- provenance record;
- deployment identity;
- rollback artifact;
- release authorization.
Extension releases also verify:
- bundled executable code;
- declared permissions;
- store-listing accuracy;
- no prohibited remote code;
- update and rollback process.
Gate 7 — Accessibility and inclusive use
Section titled “Gate 7 — Accessibility and inclusive use”Default public web target:
WCAG 2.2 Level AA for supported critical journeys, with documented exceptions and remediation.
Evidence includes:
- automated scan results;
- keyboard-only testing;
- focus order and visibility;
- screen-reader testing;
- form labels and errors;
- contrast and non-color cues;
- zoom and reflow;
- target size and dragging alternatives;
- captions or media alternatives;
- accessible authentication;
- plain-language and cognitive-load review;
- known barriers;
- accessibility contact and remediation owner.
Automation alone cannot pass the accessibility gate.
Gate 8 — Reliability and operational readiness
Section titled “Gate 8 — Reliability and operational readiness”Required evidence:
- service catalog entry;
- accountable service owner;
- critical user journeys;
- SLIs and SLOs;
- initial error-budget policy;
- dashboards and alerts;
- logs, metrics, and traces;
- queue and retry behavior;
- dependency failure modes;
- capacity assumptions;
- backup and restore status;
- on-call or escalation path;
- runbooks;
- status communication.
An SLO must influence launch decisions. It is not merely a dashboard KPI.
Gate 9 — Release and rollout safety
Section titled “Gate 9 — Release and rollout safety”Required evidence:
- release artifact;
- change summary;
- migration plan;
- feature flags;
- cohort plan;
- exposure logging;
- canary or phased rollout;
- rollback or forward-fix criteria;
- data migration rollback or restore plan;
- launch owner;
- monitoring window;
- automatic stop conditions.
A product must distinguish deploying code from exposing functionality.
Gate 10 — Payments and economic flows
Section titled “Gate 10 — Payments and economic flows”Where relevant:
- test-mode flows completed;
- merchant and processor roles confirmed;
- fee calculation tested;
- ledger entries reconcile;
- payout destination protected;
- refund behavior tested;
- dispute handling assigned;
- tax responsibilities recorded;
- sanctions restrictions implemented;
- negative balance and reserve behavior understood;
- sponsored-feature promises match actual terms.
Production money movement requires an exact approver and environment confirmation.
Gate 11 — Evidence and claims
Section titled “Gate 11 — Evidence and claims”Required evidence:
- public claims inventory;
- support for objective claims;
- source and methodology;
- metric definitions;
- verification status;
- date and scope;
- issuer or reviewer identity;
- correction and expiry;
- distinction between measured, estimated, modeled, and self-reported data.
“Verified” must always answer: verified by whom, for what property, using what evidence, and when?
Gate 12 — Support and user protection
Section titled “Gate 12 — Support and user protection”Required evidence:
- support channels tested;
- response expectations published;
- severity and escalation process;
- user-reporting path;
- abuse and fraud intake;
- refunds and complaints process;
- accessibility-support path;
- privacy and security request path;
- vulnerable-user considerations;
- incident communication templates.
Gate 13 — Legal and jurisdiction review
Section titled “Gate 13 — Legal and jurisdiction review”The launch profile records:
- jurisdictions;
- customer and worker relationships;
- regulated or high-impact uses;
- payment and tax assumptions;
- privacy obligations;
- intellectual-property rights;
- terms and policies;
- required specialist review;
- unresolved legal-watch items.
This gate must not be represented as automated legal compliance.
Gate 14 — Continuity and exit
Section titled “Gate 14 — Continuity and exit”Required evidence:
- key and account recovery;
- operator succession;
- domain and repository continuity;
- provider failure response;
- user data export;
- outstanding-payment handling;
- product transfer process;
- shutdown notice plan;
- archival policy;
- affiliation-removal behavior.
Critical journey testing
Section titled “Critical journey testing”Critical journeys are tested end to end.
Examples:
- sign in and recover access;
- review and partially approve a data request;
- submit a contribution;
- accept or reject work;
- fund and refund a sponsored feature;
- receive or revoke a credential;
- change payout details;
- export data;
- report harm or security issue;
- cancel or exit.
Testing includes happy path, denial, timeout, duplicate, partial failure, revoked permission, and accessibility variants.
Evidence strength
Section titled “Evidence strength”Each gate item can be labeled:
- E0 — assertion only;
- E1 — internal artifact;
- E2 — reproducible test or source-connected evidence;
- E3 — independent review or controlled experiment;
- E4 — strong external assurance or repeated production evidence.
Required strength depends on launch risk.
Exception policy
Section titled “Exception policy”An exception requires:
- exact unmet requirement;
- business reason;
- user and system risk;
- compensating control;
- owner;
- affected cohort;
- monitoring;
- expiry;
- remediation plan;
- approver;
- public disclosure decision.
No exception may silently become permanent.
Launch decision meeting
Section titled “Launch decision meeting”The launch review should be asynchronous-first, using a durable evidence package.
The synchronous meeting focuses on:
- unresolved risks;
- exceptions;
- stop conditions;
- ownership;
- disagreement;
- final decision.
It should not be the first time reviewers see the launch.
Approval matrix
Section titled “Approval matrix”| Launch type | Default approval direction |
|---|---|
| L0 prototype | Product owner or delegated lead |
| L1 pilot | Product owner + technical owner |
| L2 limited production | Product + security/privacy/operations owners as applicable |
| L3 general availability | Product operator under charter approval matrix |
| L4 critical/high-impact | Legal authority + independent specialist and governance review |
Exact authority comes from the Product Charter and governance rules.
Launch stop conditions
Section titled “Launch stop conditions”Examples:
- critical security finding;
- unauthorized disclosure;
- consent failure;
- inaccessible critical journey;
- payment reconciliation failure;
- elevated fraud;
- error-budget burn beyond threshold;
- incorrect public claim;
- missing support coverage;
- failed data migration;
- provider instability;
- incident-response readiness gap.
Stop conditions must have named decision owners.
Post-launch review
Section titled “Post-launch review”A review occurs after the defined observation period.
It records:
- actual cohort and exposure;
- product and guardrail metrics;
- SLO performance;
- incidents and support load;
- accessibility reports;
- security and privacy signals;
- financial reconciliation;
- user feedback;
- unexpected effects;
- whether to expand, hold, roll back, or change.
Readiness dashboard
Section titled “Readiness dashboard”The dashboard may summarize gate status, but it must link to evidence and must not produce a misleading single “quality score.”
Recommended views:
- gate status;
- unresolved findings;
- exceptions and expiry;
- launch owner;
- current rollout percentage;
- stop-condition status;
- SLO and guardrail health;
- next review.
Anti-patterns
Section titled “Anti-patterns”- launching because the date was announced;
- treating all gates as equal checkboxes;
- approving one environment and launching another;
- accepting screenshots instead of reproducible tests where tests are possible;
- claiming WCAG conformance from automated scans alone;
- using penetration testing as a replacement for secure development;
- hiding known risks from pilot users;
- leaving rollback untested;
- assuming feature flags eliminate migration risk;
- using a green dashboard to bypass accountable judgment.
MVP acceptance criteria
Section titled “MVP acceptance criteria”- launch types L0–L4 exist;
- every production launch has a Launch Readiness Record;
- critical journeys and stop conditions are declared;
- security profile references ASVS versioned requirements;
- accessibility includes human testing;
- SLOs and error budgets affect rollout decisions;
- payment flows reconcile before production;
- public claims link to evidence;
- exceptions have owners and expiry;
- rollout uses bounded exposure and rollback;
- post-launch review is scheduled;
- no automated score can approve an L4 launch.
Sources
Section titled “Sources”- WCAG 2.2
- OWASP ASVS
- Google SRE — Implementing SLOs
- OpenFeature Specification
- NIST Secure Software Development Framework
Related documents
Section titled “Related documents”- 058 — Secure Software Supply Chain
- 063 — Experimentation, Feature Flags, and Rollouts
- 065 — Accessibility and Inclusive Product Standard
- 066 — Support, Service Levels, and Incident Communication
Verification record
Section titled “Verification record”- Sources opened and checked: 2 August 2026
- WCAG baseline: 2.2 Recommendation dated 12 December 2024
- OWASP ASVS stable version observed: 5.0.0
- Automated-only accessibility approval: Prohibited
- Human launch authority: Required