Phase 5 — Validation

Phase 5 -- Architecture Validation Report

Version: 1.0 Date: February 25, 2026 Input: Phase 4 Architecture Specification v1.0 Validator role: Independent review against Phase 2 quality bar, WWDC25 Field Guide tests, User Capability Map [Core] tasks, and P0 issues from Phase 1 Verdict: CONDITIONAL PASS -- architecture is sound; 4 findings require resolution before implementation

How This Validation Was Conducted

Each test was evaluated by checking the specific claim against the specific evidence in the Phase 4 document. Where the architecture makes a tap-count claim, the actual flow table was traced step by step and the count was verified independently. Where the architecture claims a feature is discoverable, the path was reconstructed from the screen specifications and navigation hierarchy. Failures and borderline cases are noted explicitly. The architecture's own self-assessment (Section 4's "Quality Bar Validation") was treated as a claim to be verified, not as evidence.

Validation Checklist

The following tests are drawn from the WWDC25 Field Guide and Phase 2 design principles. Each is evaluated against the Phase 4 architecture specification.

[Core] Task Coverage

The following table traces every [Core]-tagged task from the User Capability Map (Sections 2-6) through the Phase 4 architecture. The tap count is measured from the tab bar -- meaning the student is already in the app, on a tab. "0 taps" means visible on the current screen. "1 tap" means one interaction from the tab bar or current screen. All counts assume the student is starting from the app launch state (Today screen visible).

[Core] Task Coverage Summary

Total [Core] tasks in User Capability Map: 27 Fully covered: 24 Partially covered or underspecified: 3 (Year 2 appointment tasks 5A.1 and 5A.2, and the pre-assessment waiting state for 2A.2) Not covered: 0

Note: Tasks 5A.1, 5A.2, and 5A.3 (Year 2 appointment management) are referenced in the architecture but have no corresponding screen specifications. The architecture explicitly defers this to a Year 2 design phase, which is a reasonable decision but should be documented as out-of-scope rather than counted as covered.

P0 Issue Resolution

The six P0 issues from the original audit, plus "feedback hard to find" from the PM Discussion (treated as P0 in the Capability Map):

P0 Resolution verdict: All 7 P0 issues are addressed at the architecture/design level. Two items (video playback and notification delivery) have engineering dependencies that the architecture cannot guarantee but correctly specifies.

Tap Count Audit

The following audits the claimed tap counts against the actual flow steps in the Phase 4 document. A "tap" is defined as one deliberate user interaction (press, tap). Opening the app does not count as a tap. Navigating to a tab counts as 1 tap.

Claimed: All [Core] tasks reachable in 2 taps (Phase 2 test S3)

The architecture's self-assessment in Section 4 claims all [Core] tasks satisfy the 2-tap rule. Let us verify the ones most likely to be tight:

Findings and Recommendations

The following findings were identified during validation. They are numbered in order of severity.

FINDING 1 -- Join Session Tap Count is Misleading (Medium Severity)

What the architecture claims: "Total taps on critical path: 2 (Open > session card > Join Zoom)" for Flow 5.

What actually happens: The "Join Zoom" button is only active "when session is within 15 minutes of start or currently live." If a student taps a session card outside that window, they reach the Session Detail modal -- but the Join button is inactive. They cannot join from there. To join, they must wait until the button activates. This is not a design flaw (the session cannot be joined before it starts), but the tap-count claim conflates two different moments in time. The claim is technically true only at the exact moment the student is joining a live or imminent session. For any other use of the 2-tap path (checking session details, adding to calendar, RSVPing), the count is accurate but the "Join" action is not available.

Impact: The 2-tap-to-join claim is correct for the live-session scenario. It is potentially confusing in documentation when the student follows the same 2-tap path and finds the Join button grayed out.

Recommendation: In the Session Detail modal spec, explicitly state what the student sees when "Join Zoom" is inactive: a countdown ("Join available in [X] hours [Y] minutes") so the modal is useful and not confusing at any time of day. The Architecture section 4.3 Schedule screen addresses "Not yet available" as a P1 fix but does not specify what inactive Join looks like in the modal. This needs to be specified.

FINDING 2 -- Tap Count Discrepancy in Flow 3 Summary (Low Severity)

What the architecture claims: "Taps from app launch to recording start: 4" (Flow 3 summary line).

What the actual flow table shows:

• Step 1: Open app (Today, primary action card shows "Record Submission")
• Step 2: Tap "Record Submission" (opens Learn, Submission segment) -- this is tap 1
• Step 3: Tap "Record Submission" button in Submission segment (opens Recording Screen) -- this is tap 2
• Step 4: Tap Record (starts recording) -- this is tap 3

The recording starts at tap 3, not tap 4. The flow table itself has 9 steps but only 7 are actual taps -- steps 1 and 6 are passive events (opening app, listening to recording). The "4" figure appears to be an error in the summary line. The actual count (3 taps to recording start) is better than claimed, not worse.

Impact: The architecture passes its own targets -- this is a documentation inconsistency, not a design failure. However, it signals that the tap counts in the summary lines were not cross-checked against the actual flow tables. Other summary claims may have similar drift.

Recommendation: Before finalizing the document for handoff to engineering, reconcile every tap-count summary line against its corresponding flow table. Specifically check Flow 2's "5 taps on critical path" (tracing: Today > Start Lesson (1) > Learn tab with Lesson segment > video tap (2) > back (3) > Video 2 tap (4) -- that's 4 taps to complete two videos, not 5 including "Mark Complete" which would be 5 -- this appears correct), and Flow 5's "2 taps" claim which is correct only at join time.

FINDING 3 -- Pre-Assessment Waiting State is Underspecified (Medium Severity)

The gap: Section 4.8 (Onboarding) notes: "If the student opens the app before placement (assessment submitted but not yet reviewed), they see a waiting state: 'We're reviewing your assessment. You'll be placed in a level within 48 hours.'" Section 4.3 Today screen mentions it: "Empty / First Use (post-assessment) -- Waiting for level placement."

What is missing: No specification of what the other tabs show in this state. If a student taps Learn, Schedule, or Profile before receiving placement, what do they see? The current architecture specifies Today's waiting state but leaves the other three tabs undefined. This matters because:

1. Students will explore the app while waiting 48 hours for placement
2. An empty or broken tab during this waiting period creates the exact disorientation the architecture is designed to prevent
3. Phase 2 Principle 5 ("No dead ends") requires that every state provides a clear next action

Impact: Medium. This is a transition state that every student passes through. If the other tabs show errors or empty screens, it undermines the onboarding experience at the most critical moment (first impressions).

Recommendation: Add a "Pre-Placement" state to the Learn, Schedule, and Profile tab specifications. Minimum viable:

• Learn tab (pre-placement): "Your journey begins once you're placed in a level. Assessment results expected within 48 hours." with orientation video embedded.
• Schedule tab (pre-placement): Show pre-semester/housewarming sessions if available, or "Sessions begin once your semester starts" with expected date if known.
• Profile tab (pre-placement): Already handled ("Never truly empty. Even pre-semester, the profile card shows the student's name, level, and assigned coach.") -- but if level and coach are not yet assigned, this promise cannot be kept. Specify the fallback: "Level: Pending Assessment Review" with expected timeline.

FINDING 4 -- Year 2 Appointment Flow Has No Screen Specification (Low-to-Medium Severity, Scope-Dependent)

The gap: The architecture correctly identifies Year 2 as a different learning model and describes how the tab bar adapts. Section 4.9 states: "Schedule tab: Includes appointment booking alongside live sessions (new 'Appointments' section)." But no screen specification exists for:

• How appointment slots are displayed (calendar? list? TA-by-TA?)
• How booking confirmation works
• How appointments relate to the Today screen in Year 2 mode
• What the Learn tab shows for elective content

Why this matters: The architecture document covers Year 1 Year-2 transition at the graduation level (Section 4.9) and at the tab-adaptation level ("Today screen: Shows upcoming appointments instead of weekly lesson/submission/feedback") but the actual interaction model for Year 2 is unspecified. Three [Core] tasks for Year 2 students (5A.1, 5A.2, 5A.3) have no home in the architecture's screen specs.

Scope judgment: If Year 2 is explicitly out of scope for this design phase, this should be stated clearly in the document as a known gap rather than left implied. The Capability Map Coverage table in Section 4 says "75%" for Year 2 but the reality is closer to 25% (only the transition experience is designed; the actual Year 2 interaction model is not).

Recommendation: Either (a) add a note to Section 4.9 explicitly stating "Year 2 interaction design is deferred to a separate design phase; this architecture covers only the Year 1-to-Year 2 transition experience" and remove Year 2 tasks from the coverage count, or (b) add a basic Year 2 screen specification for the Schedule tab's Appointments section and the Learn tab's elective content view. Option (a) is faster and honest.

FINDING 5 -- C1 (7-Item Rule) Needs Verification for Live Session Edge Cases (Low Severity)

The concern: Phase 2 test C1 states "No default list view shows more than 7 items without a progressive disclosure mechanism." The architecture claims PASS.

The edge case: The Schedule tab's session list is filtered by day by default (the calendar day strip highlights the current day). This is an effective progressive disclosure mechanism -- it reduces a potential 20-session week to the 3-5 sessions on a given day. However, the architecture does not specify a maximum number of sessions per day before a further disclosure mechanism is triggered. On a day with, say, 8 sessions (multiple QRC time slots across different gender/level groupings), the list would exceed 7 items.

Evidence from Phase 1: "Up to 20 sessions per week" is documented. While 8+ sessions in a single day is unlikely, it is not impossible during peak weeks.

Impact: Low. The day-level filtering already provides strong scannability. The failure mode (8+ sessions on one day) is rare and still preferable to the current "wall of unstructured text" described in the audit.

Recommendation: Add a soft cap to the Schedule tab spec: "If more than 7 sessions are displayed for a single day, group them by session type (Level Classes, QRCs, Office Hours) with collapsed sections, each expandable. Show count in collapsed header: 'QRCs (5)' -- tap to expand." This would satisfy C1 formally and improve scannability on dense days.

Summary Assessment

What the Architecture Gets Right

The architecture's core design decisions are well-reasoned and directly address the problems identified in the audit. The weekly rhythm organizing principle is correct for this user population. The four-tab structure is correct -- it passes the Tab Worthiness Test at every position. The Today screen design is the strongest part of the document: the week header as the dominant visual element, the context-dependent primary action card, and the status triptych together solve the disorientation problem completely.

The P0 issues are resolved in the right places. Font is addressed in onboarding (not just settings). Feedback is co-located with submissions (not in a separate archive). Notifications are specified with content and deep links. The schedule is a tab (not 5 clicks deep). The profile is a full information hub (not a minimal screen).

The progressive disclosure approach throughout (day-filtered sessions, "This Week" default on Learn, collapsed week cards, "See Full Schedule" from Today) is correct and consistent with the WWDC25 Field Guide principles.

The lifecycle state machine is thorough: pre-semester, active (default, submission pending, feedback ready, all done, behind), EOC phase, graduation, Year 2 transition. Each state is specified for the Today and Learn screens. This is production-ready thinking.

What Needs Resolution Before Implementation

Overall Verdict

CONDITIONAL PASS. The architecture satisfies all mandatory Phase 2 quality bar criteria for Year 1 design. The four open findings are gaps rather than design failures -- they do not invalidate the core structure or require revisiting the fundamental decisions. Findings F1 and F3 should be resolved before the document is handed to engineering, as they affect states that every student will encounter. Findings F2, F4, and F5 can be addressed in a targeted revision or carried forward into the detailed design phase with explicit documentation.

The architecture is ready to proceed to detailed design (wireframes/mockups) for Year 1, with the understanding that the five findings above are resolved either in a document revision or in the wireframe phase.

End of Phase 5 Validation Report