Skeleton scope. This is the analytical-mode skeleton (Claim → Evidence → Counter-tension → Through-line → Readiness) with two type-specific layers: personalEssay (load-bearing Through-line, critical Counter-tension) and studentSchoolAssignment (subtype variation across argument / expository / research paper / response, with promptAnchor constraining Beats 1, 2, and 5). The forthcoming v1.1 layer analyticalReport will add another type to this skeleton with substance specs around argument-completeness.
Speech subtypes inherit this skeleton. Analytical-mode speech subtypes — keynote, address, presentation — inherit the five-beat analytical skeleton (Claim → Evidence → Counter-tension → Through-line → Readiness) with the performed modifier active throughout. Performed is a content filter, not just a Beat 5 read-aloud check. Evidence (Beat 2) that lands in one breath survives performance — complex statistics, layered syllogisms don't survive without a slide deck or a printout. The performed modifier filters Evidence sufficiency: not just "does it argue for the claim?" but "does it argue for the claim aloud?" Counter-tension (Beat 3) needs to land aloud too — "Some say X; here's why I disagree" lands; "There are seventeen counter-positions in the literature" doesn't. Through-line (Beat 4): performed audiences need reader-stakes early — plant the through-line up front; let it pay off in delivery. Beat 5's read-aloud check is the LAST gate, not the first; performability filtering happens across Beats 1-4. Routing: door classification handles speech when framing is rich enough ("keynote for the conference" → analytical); ambiguous cases go through the discoveryPrelude phase in the master flowmap before landing here.
Argues-for, not illustrates (Beat 2). The most operationally consequential design move in this skeleton. Writers convince themselves their evidence supports their claim when it doesn't — their own evidence always feels persuasive to them. The Evidence beat is a discrete CHECK on accumulated evidence, not the gathering step. Without this discrete check, the failure mode goes undetected. See Beat 2's detail panel.
Reader-stakes addition (Beat 4). Through-line is two sub-checks, not one — distinctiveness AND reader-stakes ("why is this argument worth a reader's time?"). A piece can be technically distinctive but unmotivated; reader-stakes catches that. New from this skeleton's design pass.
Term precision as cross-beat sub-check. Bad analytical writing usually starts with sloppy terminology. Mentor watches for it across Beats 1 and 2 — does X mean the same thing across the claim and the evidence? Sub-check, not its own beat. Surfaced in both beats' detail panels.
Through-line vs. Resonance — blended-mode handling. For personalEssay especially, both framings can come into play. Mentor uses whichever language matches the writer's own — if writer reaches for "what this opens up" (resonance from narrative skeleton) while writing analytically, don't force "your distinctive angle" (through-line) on them. Cognitive frame matters; mentor mirrors.
Conversation-depth-aligned reclassification. Reclassification fires at conversation depth ~turns 2-3 across all skeletons — narrative (Beat 1 / Anchor), transactional (Beat 2 / Recipient), analytical (Beat 1 / Claim). Beat positions differ; conversation depth converges. Turn-count sanity gate also lives at 2-3.
Length-fork (shared with transactional). Beat 5's length-driven terminal action is the same primitive as transactional. For analytical pieces, length=short is rare but reachable (short op-ed ~600 words → inline drafts); length=medium/long is typical (→ exit to Composition).
Open questions retained for prompt design : (1) Counter-tension naming kept; "Pushback" considered as alternative. (2) Evidence as discrete beat (resolved — keep discrete; the beat is the check on accumulated evidence). (3) studentSchoolAssignment subtype detection — inferred from material + promptAnchor during Discovery, not asked at door. (4) Through-line for school work — lower bar, not absent.
Source files referenced : Atticus/Rooms/Concept/DiscoveryConversationService.swift, Atticus/Rooms/Concept/OpenerService.swift, Atticus/Models/WritingType.swift, Atticus/Models/LengthClass.swift. Spin-off references : discovery-architecture.html (master), narrative-skeleton.html + transactional-skeleton.html (sibling skeletons), reflective-offer.md (beat primitive).