Product Lifecycle and Quality Source Pack

Source pack version 0.1 — verified 2 August 2026
This registry records what each source supports and what it does not establish. A product must still select an implementation profile and preserve evidence of what it actually tested.

Status labels

• Normative baseline — selected stable standard or official baseline.
• Implementation reference — authoritative practical guidance used to design controls.
• Conformance reference — requirements suitable for versioned verification.
• Risk-management reference — official framework supporting governance and review.
• Legal watch — official source requiring current qualified legal interpretation.
• Tracking — emerging work not yet adopted as stable baseline.

Accessibility

Web Content Accessibility Guidelines 2.2

• Publisher: World Wide Web Consortium
• URL: w3.org/TR/WCAG22
• Status: W3C Recommendation, 12 December 2024
• State: Normative accessibility baseline
• Used for: Perceivable, operable, understandable, and robust web content; testable success criteria; Level A, AA, and AAA conformance.
• ANUKA baseline: WCAG 2.2 Level AA for supported critical public-web journeys, with documented scope, methods, exceptions, and remediation.
• Important limitation: W3C states that even Level AAA does not address every user need. Conformance applies to complete pages and supported uses, not isolated passing components.
• Checked: 2 August 2026

Understanding WCAG 2.2

• Publisher: W3C Web Accessibility Initiative
• URL: w3.org/WAI/WCAG22/Understanding
• State: Implementation reference
• Used for: Intent, benefits, examples, techniques, and common failures for success criteria.
• ANUKA boundary: Understanding documents support implementation but do not replace the normative Recommendation.
• Checked: 2 August 2026

Accessibility Conformance Testing Rules Format 1.1

• Publisher: W3C
• URL: w3.org/TR/act-rules-format-1.1
• State: Conformance-method reference
• Used for: Structuring transparent, repeatable accessibility test rules and applicability expectations.
• Important limitation: Automated rules cover only part of accessibility and do not establish whole-product conformance.
• Checked: 2 August 2026

Application security and launch verification

OWASP Application Security Verification Standard 5.0.0

• Publisher: OWASP Foundation
• URL: owasp.org ASVS
• Stable version observed: 5.0.0, released 30 May 2025
• State: Conformance reference
• Used for: Versioned technical security requirements for application verification, engineering guidance, and procurement.
• ANUKA rule: References must include the ASVS version, for example v5.0.0-1.2.5, because requirement identifiers can change between versions.
• Important limitation: ASVS conformance is one part of security readiness; it does not replace threat modeling, operations, supply-chain controls, incident readiness, or product-specific abuse analysis.
• Checked: 2 August 2026

NIST Secure Software Development Framework 1.1

• Publisher: U.S. National Institute of Standards and Technology
• URL: csrc.nist.gov/pubs/sp/800/218/final
• Publication: NIST SP 800-218, February 2022
• State: Normative secure-development reference
• Used for: Preparing organizations, protecting software, producing well-secured software, and responding to vulnerabilities.
• Current-status note: ANUKA separately tracks the SSDF 1.2 public draft and does not treat it as the final baseline.
• Checked: 2 August 2026

Feature flags and rollout controls

OpenFeature Specification

• Publisher: OpenFeature / CNCF project
• URL: openfeature.dev/specification
• State: Normative implementation candidate
• Used for: Vendor-neutral flag evaluation APIs, providers, evaluation context, hooks, events, tracking, conformance requirements, and stability labels.
• Important status behavior: OpenFeature sections without an explicit stability status are treated as Experimental by the specification.
• ANUKA boundary: Feature evaluation does not replace ANUKA authorization, consent, or governance. A flag cannot grant a capability.
• Checked: 2 August 2026

OpenFeature Introduction

• Publisher: OpenFeature
• URL: openfeature.dev/docs/reference/intro
• State: Implementation reference
• Used for: Release flags, canaries, experiments, safe degradation, dynamic evaluation, and provider-independent client behavior.
• Checked: 2 August 2026

Reliability and service objectives

Google SRE Workbook — Implementing SLOs

• Publisher: Google
• URL: sre.google/workbook/implementing-slos
• State: Implementation reference
• Used for: SLIs, SLOs, error budgets, stakeholder approval, measurable user-centered indicators, and decision policies.
• Critical point: The guidance treats SLOs as decision tools. Without an agreed error-budget policy, an SLO can become merely another KPI.
• ANUKA boundary: Google SRE material is practical guidance, not a universal legal or contractual standard.
• Checked: 2 August 2026

Google SRE Workbook — Canarying Releases

• Publisher: Google
• URL: sre.google/workbook/canarying-releases
• State: Implementation reference
• Used for: Bounded rollout, canary populations, monitoring, comparison, automated analysis, and release-risk reduction.
• ANUKA boundary: A canary supports operational rollout safety but does not automatically create a valid causal product experiment.
• Checked: 2 August 2026

Google SRE Workbook — Incident Response

• Publisher: Google
• URL: sre.google/workbook/incident-response
• State: Implementation reference
• Used for: Incident command, communication, operations, planning, roles, and response discipline.
• Checked: 2 August 2026

Google SRE Workbook — Postmortem Culture

• Publisher: Google
• URL: sre.google/workbook/postmortem-culture
• State: Implementation reference
• Used for: Learning from failure, evidence-based review, action items, and system improvement.
• ANUKA boundary: Blameless learning does not remove legal, governance, fraud, harassment, or intentional-misconduct accountability.
• Checked: 2 August 2026

NIST SP 800-61 Revision 3

• Publisher: NIST
• URL: csrc.nist.gov/pubs/sp/800/61/r3/final
• Finalized: April 2025
• State: Normative incident-response reference
• Used for: Integrating incident response into cybersecurity risk management, preparation, detection, response, recovery, and improvement.
• Checked: 2 August 2026

Privacy-aware analytics and measurement

NIST Privacy Framework

• Publisher: NIST
• URL: nist.gov/privacy-framework
• State: Risk-management reference
• Used for: Identifying and managing privacy risk across data processing, products, organizations, and lifecycles.
• Version note: The source hub includes Privacy Framework 1.0 resources and ongoing later-version work. Each implementation must record its exact selected profile.
• Checked: 2 August 2026

Google Tag Platform Consent Mode

• Publisher: Google
• URL: developers.google.com/tag-platform/security/concepts/consent-mode
• State: Implementation reference
• Used for: Basic and advanced consent-aware behavior for Google tags and consent-state integration patterns.
• ANUKA boundary: Google Consent Mode does not by itself establish lawful collection or compliance for ANUKA or the host product.
• Checked: 2 August 2026

FTC Advertising Substantiation Policy

• Publisher: U.S. Federal Trade Commission
• URL: ftc.gov advertising substantiation policy
• State: Legal watch
• Used for: The principle that objective advertising claims require an appropriate reasonable basis before dissemination.
• ANUKA implication: Analytics-based growth, savings, quality, verification, or performance claims need a metric contract and prior support matching the wording.
• Checked: 2 August 2026

Product lifecycle and operating references

ANUKA Governance Architecture

• Source: 040 — Governance Architecture
• State: Internal normative draft
• Used for: Authority layers, decision classes, legal-versus-community boundaries, and accountable admission decisions.

ANUKA Resident Product Governance

• Source: 044 — Resident Product Governance
• State: Internal normative draft
• Used for: Resident charters, status, autonomy, founder powers, exceptions, separation, and exit.

ANUKA Shared Core Architecture

• Source: 050 — Shared Core Architecture
• State: Internal architecture draft
• Used for: Shared service boundaries, trust zones, tenant and legal-entity isolation, and product integration.

ANUKA Compatibility and Deprecation

• Source: 056 — Compatibility, Versioning, and Deprecation
• State: Internal normative draft
• Used for: Version support, migration, normal and emergency retirement, and historical reproducibility.

Adoption rules for ANUKA

1. WCAG 2.2 Level AA is the default target for supported critical public-web journeys.
2. Accessibility conformance requires human testing; automation is supporting evidence only.
3. OWASP ASVS references include exact versioned identifiers.
4. OpenFeature is the preferred vendor-neutral feature evaluation abstraction where its stability level fits.
5. Feature flags never replace authorization or consent.
6. SLOs include owners, SLI implementations, error budgets, and decision policy.
7. Canary rollout and causal experimentation remain distinct.
8. Analytics collection begins with a decision and purpose, not a desire to retain all possible data.
9. Public claims use versioned metric contracts and prior evidence.
10. Product transfer and shutdown preserve participant rights, money, evidence, and dated affiliation history.

Review procedure

Before each product-profile release:

1. open every cited source;
2. confirm publisher, version, and status;
3. record selected implementation profiles;
4. verify that evidence supports the exact claim;
5. identify experimental sections or drafts;
6. review accessibility with manual methods;
7. review security against exact ASVS identifiers;
8. test rollout and rollback behavior;
9. verify analytics consent and retention behavior;
10. update changed standards and implementation references.

Known follow-up research

• mobile accessibility baselines for native applications;
• jurisdiction-specific accessibility law and procurement obligations;
• statistical review standards for high-impact experiments;
• product safety requirements for regulated sectors;
• customer-support retention and recording rules;
• global consumer notice and subscription-cancellation requirements;
• accessibility of AI-generated adaptive interfaces;
• archival standards for long-lived credential and evidence verification.

---

Registry maintenance

• Last manual validation: 2 August 2026
• WCAG baseline: 2.2 Recommendation
• ASVS baseline: 5.0.0
• OpenFeature baseline: Pin by implementation ADR and section stability
• Next review: Before first Resident pilot or within 90 days, whichever occurs first