Feature Freeze
This chapter records the v1 feature freeze packet. It should be updated only when the approval status changes or when an approved post-freeze exception changes the frozen scope.
The frozen-scope candidate is /prd/04-v1-feature-set-selection/. This chapter does not invent new features; it locks or unlocks the selected scope from that chapter.
5.1 — Freeze status
| Field | Value |
|---|---|
| Freeze packet | v1-feature-freeze-2026-05-20 |
| Freeze status | Ready for approval |
| Prepared timestamp | 2026-05-20 09:37 BST |
| Formal approval timestamp | Pending |
| Frozen scope reference | /prd/04-v1-feature-set-selection/ |
| Canonical feature source | /prd/02-feature-specification/ |
| Canonical journey source | /prd/03-user-journey-flows/ |
| Binding architecture source | /architecture/01-architecture-decisions/ |
The scope is not formally frozen until the required approvers in §5.2 mark the packet approved. Once approved, the formal approval timestamp becomes the freeze timestamp and all later scope changes require the exception process in §5.5.
5.2 — Approver list
| Role | Approver (or named delegate) | Approval state | Notes |
|---|---|---|---|
| Product owner | Yayra - Jude | Pending | Confirms the product scope, prioritisation, and monetisation model. |
| Engineering owner | TBD — owner-or-delegate required before formal approval can begin | Pending | Confirms feasibility, architecture alignment, phase gates, and implementation risk. |
| Design owner | TBD — owner-or-delegate required before formal approval can begin | Pending | Confirms onboarding, library, canvas, paywall, settings, and accessibility surface readiness. |
| Content and cultural review owner | TBD — owner-or-delegate required before formal approval can begin | Pending | Confirms launch-library readiness, review process, and publishing workflow. |
| Legal, privacy, and store compliance reviewer | TBD — owner-or-delegate required before formal approval can begin | Pending | Confirms child-mode, analytics, purchases, notifications, and platform policy constraints. |
Approval threshold and delegate rule
- Threshold: all five named owners (or their written delegates) must mark the packet approved for the freeze to take effect. A single dissent blocks the freeze; the dissent reason is recorded alongside the approval state, and the disagreement is resolved before the freeze can land.
- Delegate rule: if an approver is unreachable for more than 72 hours after the packet is published for review, the Product owner may nominate a written delegate. The delegation must be recorded in the relevant row, and the delegate signs off in the same position.
- Status messaging: while any row still shows TBD, the §5.1 freeze status remains “Ready for review” rather than “Ready for approval.” The status only advances to “Approved” when every row carries a real name and a positive approval state.
5.3 — Frozen scope reference and feature counts
| Scope measure | Count | Reference |
|---|---|---|
| In-scope user-facing v1 feature records | 53 | /prd/04-v1-feature-set-selection/ §4.2 |
| Supporting infrastructure feature records | 14 | /prd/02-feature-specification/ “Supporting infrastructure dependencies” |
| Total feature records bound by the freeze | 67 | Sum of the two rows above |
| Explicit post-v1 feature records | 10 | /prd/04-v1-feature-set-selection/ §4.4 |
| Additional out-of-scope MVP classes | 3 | Full admin dashboard, multiplayer, and heavy animation from /spec/19-mvp/. |
| Primary journeys supported | 5 | JRN-P01 to JRN-P05 in /prd/03-user-journey-flows/. |
| Alternate journeys supported | 8 | JRN-A01 to JRN-A08 in /prd/03-user-journey-flows/. |
| Failure journeys supported | 10 | JRN-F01 to JRN-F10 in /prd/03-user-journey-flows/. |
The user-facing count is grouped as follows; area labels match /prd/04-v1-feature-set-selection/ §4.2 exactly.
| Area | Feature count |
|---|---|
| Onboarding and retention | 10 |
| Library and artwork decisioning | 6 |
| Download, cache, and offline reliability | 5 |
| Canvas, palette, and accessibility | 9 |
| Progress and identity | 6 |
| Content-pack monetisation | 4 |
| Settings and notifications | 4 |
| Content pipeline, cultural review, and admin tooling | 5 |
| Observability and release gates | 4 |
| Supporting infrastructure (non-user-facing) | 14 |
5.4 — Scope locked at freeze
When approved, the following statements become binding for v1. Most of them are restatements of decisions already locked in the architecture and the spec; the freeze repeats them here so a single packet approval locks them into the v1 commitment. Where wording differs, the authoritative source listed in parentheses wins.
- v1 includes the 53 user-facing feature records selected in /prd/04-v1-feature-set-selection/ §4.2, plus the 14 supporting infrastructure records in /prd/02-feature-specification/ “Supporting infrastructure dependencies.”
- v1 excludes the post-v1 and out-of-scope items listed in /prd/04-v1-feature-set-selection/ §4.4.
- The Phase 0 performance proof remains a gate before production implementation advances (/architecture/01-architecture-decisions/ ADR-010, /spec/17-phases/).
- Content packs are the only paid model at launch (/spec/04-features/ §4.7, ADR-008, /spec/20-open/ OD-02).
- Cultural review approval is required before any artwork is published (/spec/14-culture/ §14.2, ADR-009).
- The client cannot decide premium access, role escalation, receipt validity, or publication status (/architecture/01-architecture-decisions/ §2.2 trust boundaries, ADR-006, ADR-007).
- Child-mode analytics restrictions are part of the frozen scope (/spec/13-observability/ §13.3).
- Accessibility features named in the architecture decisions are part of the frozen canvas scope (/spec/12-accessibility/, ADR-012).
- Banned UI conventions in /spec/02-product/ §2.5 (no countdowns, no streak mechanics, no rate-this-app during play, no interstitial ads) are part of the frozen scope.
5.5 — Post-freeze change policy
Post-freeze changes require a Six-Dimension Change Exception (sometimes shortened to 6d) when they do any of the following:
- Add, remove, or materially change a v1 feature.
- Move a post-v1 item into v1, or move an in-scope v1 feature into post-v1.
- Change the catalogue Release lane of an existing feature record (e.g. bumping an MVP feature to Post-v1 or vice versa in /prd/02-feature-specification/).
- Change a journey outcome, acceptance gate, or user-visible surface.
- Add a runtime dependency that changes the approved stack or trust boundaries.
- Change monetisation, analytics, child-mode, accessibility, cultural review, or offline guarantees.
- Relax a Phase 0 or release-gate constraint.
The six dimensions
Every approved exception must record the impact across the same six dimensions. The name comes from the six dimensions, not from a six-day deadline.
- User value or risk — what the change does for or to the user; any new compliance, accessibility, or cultural exposure.
- Scope — affected
FEAT-*, journey, ADR, and spec references, including any catalogue lane changes. - Schedule — phase, milestone, and release-date implications.
- Architecture and dependencies — runtime dependency changes, trust-boundary effects, and ADR impact.
- Compliance — legal, privacy, child-mode, accessibility, and cultural-review implications.
- Release gates and rollback — Phase 0 and release-readiness impact, plus the rollback plan if the change ships and needs to be reversed.
A Six-Dimension Change Exception must record one entry per dimension above, plus the decision metadata: final decision (accept / reject), approvers (per §5.2 threshold and delegate rule), approval timestamp, and any deviation from the rollback plan.
flowchart TD
Request["Change requested after freeze"] --> Classify{"Changes frozen scope or catalogue lane?"}
Classify -->|No| Normal["Normal review and implementation"]
Classify -->|Yes| Exception["Create Six-Dimension Change Exception"]
Exception --> Assess["Assess all six dimensions: user value, scope, schedule, architecture, compliance, release gates"]
Assess --> Decide{"Approved by all required owners per §5.2?"}
Decide -->|No or any dissent| Reject["Keep frozen scope unchanged"]
Decide -->|Yes| Update["Update feature selection, freeze record, catalogue lane, and affected source docs"]
Update --> Implement["Implement under revised scope"]5.6 — Changes allowed without a scope exception
The following changes do not require a Six-Dimension Change Exception, provided they stay inside the frozen feature set:
- Copy edits that do not change journey sequence, promise, or compliance meaning.
- Accessibility, performance, reliability, and security improvements that preserve the same user-visible scope.
- Bug fixes and acceptance-criteria clarifications.
- Internal implementation changes that do not introduce new runtime dependencies or trust-boundary changes.
- Content corrections inside an already approved publication and review workflow.
5.7 — Freeze operating rule
The freeze is a product and architecture boundary, not a ban on learning. New information can still change v1, but it must do so openly through the exception process. Any approved exception updates this chapter and the selection chapter in the same change so future implementation work has one clear source of truth.