Skip to content
ANUKA Foundation

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”

Readiness indicator

Launch readiness ladder

Each level increases the evidence and accountability expected before exposing a product to more people, money or consequential decisions.

  1. L0
    Internal prototype

    Controlled data, no customer money and a disposable environment.

  2. L1
    Controlled pilot

    Invited participants, notice, monitoring, support and rollback.

  3. L2
    Limited production

    Real users with bounded exposure and active support operations.

  4. L3
    General availability

    Declared markets, stable contracts and production SLOs.

  5. L4
    Critical production

    Independent review and stronger recovery for high-impact surfaces.

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 typeDefault approval direction
L0 prototypeProduct owner or delegated lead
L1 pilotProduct owner + technical owner
L2 limited productionProduct + security/privacy/operations owners as applicable
L3 general availabilityProduct operator under charter approval matrix
L4 critical/high-impactLegal 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”
Section titled “Related documents”

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