Essay Examples

# Essay Examples

A curated collection of high-quality essays that students browse to see what good looks like. V1 ships a library of staff-curated **model essays** Kevin drafts against the rubric. V2 layers in real, consented YAWP! student work — the "platform's own success stories" framing that motivated this spec is the V2 destination; V1 stands the surface up so V2 can plug into it.

May 26 call update: Kevin specifically tied this to revision motivation. Students revising essays need to see that high-scoring work is possible, not only hear that their current draft needs work. This reinforces V1 as staff-curated model essays that can ship before consented student exemplars.

## Problem

Students need models, not just feedback. The tutor and grading assistant handle "what's wrong with mine" — this feature handles "what does a good one actually look like?" Most students have never read many truly good essays in their lives; textbook examples feel distant and curated by committee.

Teachers, similarly, have no structured way to say "this is what I mean when I say a strong essay." A shared library of vetted examples closes both gaps: real model essays for students, a shared reference point for teachers.

Two-stage approach:

- **V1** gets a useful library in front of students fast, with no legal-consent dependencies — Kevin (and other staff) curate the initial pool by drafting essays against the rubric.
- **V2** expands the pool with real student writing once the consent infrastructure is in place.

## V1 scope: staff-curated model essays

### How it works

1. **Authoring.** Kevin (or another staff author) drafts a model essay against an existing rubric. Claude is used as the drafting tool — the rubric criteria, assignment prompt, and target grade level go in; a candidate essay comes out; Kevin reviews and edits to a publishable bar. The final artifact is a piece of writing curated by a human, regardless of how it was drafted.
2. **Upload.** Kevin uses a staff-only admin surface to paste in or upload the essay and tag it with `assignment_type`, `module`, target `grade_level`, and a title (e.g., "Thesis-driven analytical, 11th grade — pandemic-era schooling").
3. **Publish.** The essay appears in both surfaces immediately. No consent gate, no review queue, no reveal threshold.
4. **Edit / remove.** Kevin can edit body content or pull an entry at any time from the same admin surface.

There is **no nomination flow, no student consent, no parental consent, and no eligibility threshold in V1.** Those are V2 concerns.

### Attribution

Model essays are labeled **"Model essay"** (no author attribution). Per the platform brand rule (no AI framing in user-facing UI), the fact that the draft was AI-assisted is **not surfaced** to students. To the student it reads as "an essay the platform's editors put together to show what this assignment can look like at its best." Which is true — a human curates each one before it ships.

When V2 ships and real student essays enter the library, those carry their own grade-level attribution (`"An 11th grade student on YAWP!"`) and are visually distinguishable from model essays via attribution alone.

### Where it surfaces

Same two surfaces, populated from the same library pool — model essays in V1, model essays + consented student essays in V2:

- **In-context gallery on the module page.** A gallery at the bottom of the relevant module page — students working on a thesis-driven essay see thesis-driven model essays right where they're working. Scoped by default to the current module, but filterable (see "Filters" below) so a student can broaden out (e.g., "show me 12th-grade analytical essays from any module") without leaving the page.
- **YAWP! Library.** Standalone, searchable, filterable home for every published example. Visible to both students and teachers; teachers can link a specific YAWP! Library entry directly into an assignment or feedback note.

In V1 there is **no reveal threshold** — the library is visible from launch as long as Kevin has seeded it with a useful starter set (working target: 10–15 model essays spanning the major assignment types and grade levels before flipping the flag on).

#### Filters

Both surfaces use the same filter pattern — modeled on the Daily Pages Prompts Library (see `archive/daily-pages-assignments.md`): a row of **filter chips** along the top, plus a free-text search box. The two surfaces differ only in their default scoping and which chips are pre-applied:

- **Module-page gallery** opens with the current module's chip pre-selected. The student can clear it to broaden out, or layer on additional chips.
- **YAWP! Library** opens with no chips applied — the full pool is browsable.

**Facets (working list):**

- **Grade level** — 9, 10, 11, 12. Multi-select.
- **Assignment type** — thesis-driven analytical, narrative, DBQ, LEQ, etc. Multi-select.
- **Module** — multi-select; pre-applied on the module-page surface.
- **Genre / register** — analytical, narrative, reflective, argumentative. Some overlap with assignment type; included because a single assignment type can host more than one register.
- **Source** (V2-only) — "Model essay" vs. "Student essay." Hidden in V1 since the pool is single-source.
- **Free-text search** across essay body and title.

The pattern intentionally matches Daily Pages so the filter UX feels consistent across the platform — a student or teacher who's used one already knows how to use the other.

#### Naming and placement

The dedicated library is branded **YAWP! Library** (with the exclamation point — matches the existing YAWP! product wordmark). Lives at the **bottom of the left-side navigation**, persistent across student and teacher views. Bottom placement is deliberate: above-the-fold real estate stays for primary task surfaces (My Documents, My Classes, etc.), while YAWP! Library sits as an always-available reference layer the user reaches for *between* tasks rather than during one. Same icon and label for students and teachers — the underlying content pool is identical; only what they do with it differs (students browse and learn; teachers browse and link).

The "collection of YAWPs" framing originally leaned on real student writing. In V1 the library is primarily editorial; the name still works because the platform is YAWP! and these are YAWP!'s curated essays. The framing strengthens as V2 brings real student work in.

### Admin curation

A staff-only admin route lets Kevin (or anyone with admin permission) create, edit, soft-hide, and delete model essays. No moderation queue, no approval workflow — entries go live the moment they're published. The same `is_hidden` lever V2 uses for student essays applies to V1 model essays too, so anything that turns out to need a fix can be pulled fast without losing the row.

### Editorial bar

Model essays should read as **student-realistic** rather than aspirational-best-case. The target register is "the strongest essay a real student in this grade could plausibly produce" — the kind of writing that makes a reader think *I could write this too if I worked at it*, not *no one writes like that*. Models obviously beyond reach undercut the teaching purpose.

### Not in V1 (→ V2)

- Student-nominated essays.
- Student or guardian consent flows.
- Eligibility threshold (90%+ on a submission).
- Reveal threshold (5-essay gate).
- Withdrawal mechanics.
- Frozen content tied to consent.

## V2 scope: student-nominated exemplars

V2 brings real student writing into the same library, behind the consent gates V1's editorial pipeline doesn't need.

### How it works

1. **Nomination (teacher side, separate step).** On the submission detail view, after a grade of 90%+ is recorded, a "Nominate as example" action appears near the grade. Teacher clicks it; small confirmation: "This essay will be offered to the student as an example for other YAWP! students when you release their grade." Nomination is saved but **dormant** until grade release. Decoupling nomination from release lets the teacher grade a full stack first and think about nominations separately, and avoids gumming up the release flow with a second decision.
2. **Consent prompt (student side, at grade release).** When the student opens their released grade, they see a warm, congratulatory prompt below the grade and feedback. The student just wrote something exceptional — the surface should feel like that, not like a legal form:

   ```
   🎉 Nice work — your teacher thought this one was exceptional.

   Out of all the essays written on YAWP! this term, yours stood out.
   Would you let us share it as an example to inspire other students?

   You'd appear anonymously as "An 11th grade student on YAWP!" —
   no name, no school. Just your words, doing the teaching.

     [ Yes, share my essay ]   [ Not this one ]   [ Decide later ]
   ```

   The tone is celebratory; the choice is still genuinely free. All three options are equal weight — no dark patterns, no guilt language, no default-checked boxes. Student can change their mind at any time from their profile settings.

   (Copy is a starting point — refine before launch. Emoji optional; the warmth should come through with or without it.)
3. **Parental consent (guardian side).** Before the essay is published, parental/guardian consent must be recorded. The mechanism, timing, and consent model (blanket vs per-essay, proactive vs reactive, magic-link vs school paperwork vs other) are intentionally left open — see "Open questions" below. The legal requirement is fixed; the implementation is not.
4. **Display.** Approved essays (both student and guardian consents recorded) surface in the same two surfaces as V1 model essays, with grade-level attribution distinguishing them.
5. **Withdrawal.** Either the student or the parent/guardian can withdraw consent at any time. Withdrawal removes the essay from both surfaces immediately.

### Attribution (V2 entries)

**Grade level only**: *"An 11th grade student on YAWP!"* No name (first or last), no school, no city, no state. This removes PII concerns for minors and keeps the surface uniform. Visually distinct from V1's "Model essay" label.

### Eligibility threshold

`numericPercentage >= 90` on the Submission record.

### Reveal threshold (V2-specific UX guard)

The V1 model-essay pool already populates the library, so this isn't a "library feels empty on day one" concern the way it was in the original spec. Instead, the reveal threshold for V2 is about the **student-essay sub-pool** feeling real before the consent prompt's "yours stood out — would you share it?" framing starts going out:

- **Hold the student consent prompt** until the consented student-essay pool reaches 5 site-wide.
- Until then, nominations and consents accumulate quietly. Teachers can keep nominating; we just don't surface the celebratory prompt to students yet.
- Engineering can wire the threshold as a config value so we can tune it once we see how nominations flow in pilot.

Library and module-page surfaces are unaffected — V1 model essays are visible throughout.

### Admin curation (V2)

Staff need a **remove** lever in V2, not a V3 nice-to-have. Even with the 90% threshold, teacher nomination, and student consent all in place, content that slips through (a slur in a quoted passage, off-topic material, an essay that names a real person, anything that becomes a problem in retrospect) has to be removable without ceremony. Cheapest viable shape:

- An `is_hidden` boolean and `hidden_reason` text field on `exemplar_nominations` (mirrors the V1 lever on `model_essays`).
- An admin-only "Hide from library" action on any library entry (and its module-page gallery counterpart). Hiding is reversible; the row stays for audit.
- Hidden entries disappear from both surfaces immediately, identical to a student withdrawal from the user's perspective.
- No public reason given. Staff can leave a private note for themselves in `hidden_reason`.

No moderation queue, no reports-from-students flow, no approval workflow before publish in V2 — those are V3 if they're ever needed. The lever is a safety valve, not a process.

### Not in V2 (→ V3)

- **Upvoting.** Letting students upvote helpful examples (and using upvotes to sort) is a clear V3 candidate — it surfaces "which examples are actually teaching the most" without manual curation.
- See "V3 ideas" at the bottom for the rest.

## Domain notes

- **ModelEssay** (V1, new) — a staff-authored essay tagged by AssignmentType / Module / grade level. No submission link, no consent state, no author user surfaced publicly.
- **Submission** (V2) — the nominated student essay. One nomination per submission.
- **Assignment / AssignmentType / Module** — used for filtering and for scoping the in-context module-page gallery (both V1 and V2).
- **ExemplarNomination** (V2, new) — links a submission to a library entry and tracks consent state.
- **Profile** (V2) — source of the student's grade level for the anonymized attribution. Resolved at display time, not stored as a string, so attribution stays current as the student progresses.

### Consent state machine (V2)

The shape of the state machine depends on which parental-consent model we land on (see open questions). Two of the contours are fixed regardless:

- An essay must have both **student opt-in** and **parental/guardian consent** recorded before it appears in either surface.
- Either party can withdraw at any time, and withdrawal removes the entry from both surfaces immediately. Withdrawal is one-way; a new nomination would be required to restart.

The intermediate states (e.g., whether parental consent is captured per-essay or held as a blanket on-file consent at the student level) will be filled in once the consent model is chosen. Engineering should build the state machine from that decision rather than from the placeholders above.

## Data model implications

### V1: `model_essays`

New table `model_essays`, purely additive:

- `id`
- `title`
- `body` (text — the essay content)
- `assignment_type_id` (FK, nullable to allow cross-type general examples)
- `module_id` (FK, nullable)
- `grade_level` (int or enum)
- `created_by` (FK → users, the staff author — internal, not surfaced to students)
- `created_at` / `updated_at`
- `is_hidden` (bool) / `hidden_reason` (text, nullable) / `hidden_at` / `hidden_by` (audit)

No state machine; presence on the table with `is_hidden = false` means published.

### V2: `exemplar_nominations`

New table `exemplar_nominations` (additive, no changes to `submissions` or `users`):

- `submission_id` (FK → submissions, unique — one nomination per submission)
- `nominated_by` (FK → users, the teacher)
- `nominated_at`
- Consent-state and audit fields **TBD** — depends on which parental-consent model the open questions resolve to. At minimum: a state enum that captures the not-yet-published / both-consents-recorded / declined / withdrawn distinctions, plus timestamps for each consent event and a `withdrawn_by` field (`student` or `guardian`) for audit.
- `is_hidden` (bool, admin curation lever — hides from both surfaces without changing consent state)
- `hidden_reason` (text, nullable, staff-only audit note)
- `hidden_at` / `hidden_by` (nullable, for audit)
- `frozen_content` (text, the essay body captured at the moment of consent — see "Revision flow interaction" below)
- `frozen_at` (timestamp, when the snapshot was taken)

Why a separate table rather than fields on `Submission`: keeps `Submission` focused on its own concerns; cleanly captures the state machine above; makes future additions (e.g., V3 upvotes, multiple nominations per submission, admin curation flags) easier without further `Submission` schema churn. Engineering can refine the exact shape — the requirement is the state machine and a clean point of separation.

Backward-compat: both tables are purely additive. No changes to `Submission` or `users`. Grade-release flow (V2) gets one new hook to flip `nominated → pending_consent` and surface the consent prompt.

### Surfacing both pools in one query

The two surfaces (module-page gallery and YAWP! Library) read from a UNION of `model_essays` (V1) and consented `exemplar_nominations` (V2). Engineering will pick the concrete shape — view, materialized table, or join — but the contract is "one query feeds both surfaces, regardless of source," with attribution-source derived per-row.

### Revision flow interaction (V2)

Library entries from V2 are **frozen at the moment of consent**. When the student picks "Yes, share my essay," the essay body is snapshotted into `frozen_content` on the `exemplar_nominations` row, and the library renders from that snapshot — not from the live submission. If the student later revises the underlying submission (when revision flow ships), the library entry is unaffected: what they consented to share is what stays shared.

Why freeze rather than auto-update: the student consented to a specific piece of writing being public. A later revision is a different piece of writing they haven't been asked about. Freezing keeps consent meaningful and avoids any "I didn't agree to *this* version being out there" surprise.

Withdrawal still works the same way — pulling consent removes the frozen entry from both surfaces immediately.

V1 model essays don't have this concern — Kevin edits in place, and updates surface immediately.

## File paths in `yawp-2.0` likely to change

### V1

- `packages/prisma/schema.prisma` — new `ModelEssay` model
- `packages/prisma/migrations/<timestamp>_model_essays/` — new migration
- New admin route for staff CRUD — likely `services/web-app/app/routes/admin.model-essays/`
- New route for the YAWP! Library — likely `services/web-app/app/routes/app.yawp-library/` with index + filter params
- `services/web-app/app/routes/app.courses.$id/route.tsx` — in-context examples gallery at the bottom of the module page
- The shared left-nav component (wherever the persistent sidebar lives) — add the YAWP! Library entry at the bottom for both student and teacher views
- New API routes for staff CRUD and library queries

### V2

- `packages/prisma/schema.prisma` — new `ExemplarNomination` model
- `packages/prisma/migrations/<timestamp>_exemplar_nominations/` — new migration
- `services/web-app/app/routes/app_.submissions_.$submissionId/teacher-grading/teacher-grading-panel.tsx` — "Nominate as example" action when grade ≥ 90%
- `services/web-app/app/routes/app_.submissions_.$submissionId/route.tsx` — student consent prompt on grade-release view
- New API routes for consent save/revoke
- Library query updated to UNION V1 and V2 sources

Engineering will refine; this is a starting list.

## Open questions

### V1

- [ ] **Admin route placement and permissions.** Where in the admin surface do model essays live? Confirm which users are eligible to author them — Kevin only, all admins, or a specific staff role.
- [ ] **Drafting workflow.** Does Kevin do the Claude drafting in an external tool (claude.ai, etc.) and paste the result into the admin surface, or do we want a Claude-assisted draft surface inside the admin route itself? Lean external for V1 — keep the in-app surface a plain text editor + tags. If that gets clumsy as the pool grows, revisit.
- [ ] **Initial seed size.** How many model essays does Kevin draft before flipping the V1 flag on? Working target: 10–15 spanning the major assignment types and grade levels.
- [ ] **One model essay per slot, or several?** One canonical pick per (AssignmentType × Module × grade level), or multiple? Lean: multiple. The in-context gallery surfaces a small set rather than one canonical pick — variety beats authority.
- [ ] **Provenance metadata.** Do we store anything about how a model essay was drafted (e.g., "Claude-assisted, reviewed by Kevin")? Useful internally for auditing the pool later; never surfaced to students. Lean: yes, an internal-only `drafting_notes` field.
- [ ] **Filter composition.** Same call as daily-pages: do filters compose AND across facets / OR within a facet, or is it single-facet at a time? Lean: AND across, OR within — the standard faceted-search pattern. Worth resolving in lockstep with the daily-pages answer so the two surfaces behave identically.
- [ ] **Module-page gallery: default count and "show more" behavior.** How many essays show up by default before the gallery starts paginating or asking the student to expand? Working target: 3–5 with a "see more in YAWP! Library" link.

### V2

- [ ] **Teacher visibility into consent outcome.** Can teachers see which of their nominated essays were consented vs. declined, or is consent opaque to the teacher to avoid pressure dynamics? Lean opaque for V2.
- [ ] **Parental-consent model: blanket vs per-essay.** Up-front blanket consent ("YAWP! may publish my child's writing, anonymously, if it scores ≥90%") vs per-essay consent at each nomination. Blanket is the standard ed-tech pattern (matches school media-release paperwork) and far less friction; per-essay is more explicit but pings parents repeatedly. Lean blanket, but not committed.
- [ ] **Parental-consent timing: proactive vs reactive.** Capture parental consent at student/school onboarding (so it's on file before the first 90% essay), or capture it the first time the student is nominated. Proactive avoids urgency around a specific celebratory moment; reactive avoids collecting consent for students who'll never be nominated.
- [ ] **Parental-consent mechanism.** Magic-link email to guardian (cheapest, light audit trail), e-signature service like DocuSign (strongest audit trail, more friction), school-administered paperwork rolled into existing annual media releases (lowest parent friction, requires district buy-in), or in-app guardian portal (highest control, highest friction). May be a combination depending on the school.
- [ ] **Parent-email collection: who supplies it.** Teacher-uploaded as part of the existing class roster (likely cleanest if rostering already supports student lists / CSV — needs confirmation in `yawp-2.0`), student-entered with verification email, SIS sync, or some combination. Whatever we pick, this is reusable infrastructure — worth considering whether to spin a separate "parent contact infrastructure" spec out of this one.
- [ ] **Parental-consent failure modes.** What happens when there's no parent email on file, the email bounces, the response window expires, or the guardian declines. Need a defined default for each.
- [ ] **Guardian response window.** If we go with a reactive / per-essay model: how long before a non-response counts as decline? 14 days, 30 days, configurable. Not relevant if we go blanket-up-front.
- [ ] **ToS and privacy-policy updates.** Confirm what disclosures need to land in the platform's terms and privacy policy before launch, and whether existing school-services contracts need an addendum.

## Legal posture

**V1: no parental consent required.** Model essays are staff-authored editorial content. No student PII is involved. The only legal hygiene needed is normal ToS clarity that platform-published example content is owned/licensed by YAWP! and not student work.

**V2 (resolved 2026-05-07): parental consent is required before publishing a minor's essay.** Anonymity (grade-level-only attribution, no name/school/city) reduces risk but does not eliminate the legal requirement on its own. Under the reasonable-person-in-the-school-community test that runs through COPPA, FERPA, and the major state student-privacy regimes, a small pilot is identifiable almost by definition — a teacher and classmates who recognize a writer's voice, topic, or stance would re-identify a "grade 11 student on YAWP!" trivially. So the design assumes a two-stage consent (student + parent/guardian) gates publication, and anonymity is a defense-in-depth layer on top.

What's fixed for V2: the library does not include any V2 entry until both student and parent/guardian consent are recorded; either party can withdraw at any time; anonymity stays as a defense-in-depth layer on top.

What's still open for V2 (see "Open questions"): the consent **model** (per-essay vs blanket), **timing** (proactive at student onboarding vs reactive at first nomination), **mechanism** (magic-link email, e-signature, school-administered paperwork, etc.), and **how parent contact data gets into the system in the first place** (teacher-uploaded as part of the existing roster, student-entered with verification, SIS sync, or some combination). These are deliberately left open for now — the right answer depends on how rostering currently works in `yawp-2.0` and on conversations with pilot schools about their existing parent-comm infrastructure.

ToS and privacy-policy updates, plus whatever consent infrastructure the open questions resolve to, are pre-launch dependencies for V2 only — V1 ships without them.

### Precedent: This I Believe (V2 reference)

[This I Believe](https://thisibelieve.org) (NPR-origin personal-belief essay project, ~20 years running) is the closest existing precedent for what V2 is trying to do, and it's useful to us in two ways.

**Validates the two-stage consent design.** TIB's terms forbid submissions from anyone 12 or under, and require contributors aged 13–17 to obtain parental or guardian permission before submitting any personally identifiable information to the site. A long-running national project landing in the same place as our legal research is strong outside confirmation that the parental-consent gate is the right shape — not a yawp-specific overcorrection.

**Worth studying as a UX and tone reference.** TIB has solved (well) the problem of presenting young writers' work as serious contributions to a larger conversation, not as "kids' essays." That's the exact register we want for YAWP! Library. Our attribution rules are stricter (grade-level only vs. their named contributors with parental consent), but the editorial respect TIB extends to its writers is the calibration target. Pull a handful of TIB essay pages during library visual design as a tone reference.

## Edge cases

### V1

- **Essay needs a correction post-publish.** Kevin edits in place; the revision is visible immediately. No audit trail needed in V1 — these are editorial, not consent-bearing.
- **AssignmentType deleted or renamed.** Model essays linked to it surface a soft warning in the admin route ("tag missing, please re-tag") and are auto-hidden from student-facing surfaces until re-tagged.
- **Module deleted.** Same as above.
- **Grade-level filter on the library.** Model essays specify a target grade level; the filter treats them like any other entry.
- **Author leaves the platform.** Model essays they authored remain published — `created_by` is internal-only and not surfaced to students.

### V2

- **Decide later.** Student picks "Decide later" — the consent prompt remains visible from profile settings until they choose. Library does not include the essay.
- **Decline then change mind.** Student declines, later wants to opt in — must be self-service from profile settings, no teacher intervention.
- **Guardian declines.** Essay does not surface. No detail on guardian's reason is exposed to the student. Exact UX depends on the chosen consent mechanism (open question).
- **Withdraw after consenting (either party).** Essay disappears from both surfaces immediately. The audit record captures which party initiated. Any teacher-linked references (an assignment that links to this specific library essay) should degrade gracefully ("this example is no longer available").
- **No working parent contact on file.** Behavior depends on the chosen mechanism (open question). At minimum: the essay does not publish, and the gap is surfaced somewhere actionable (likely to the teacher, possibly to the student) so the missing data can be supplied.
- **Grade adjusted below 90% after nomination but before release.** Auto-rescind the nomination, or flag the teacher to confirm before the rescind. Prefer rescind with a notification on the next teacher visit.
- **Teacher nominates, then unnominates before release.** Allowed; nomination row is deleted (or moved to a tombstone if we want audit). No student-facing impact since the consent prompt never surfaced.
- **Multiple 90%+ submissions from the same student.** Each is nominated and consented independently.
- **Teacher leaves the platform.** Their nominations and any consented library entries remain; the library is not tied to active teacher accounts.
- **Student grade level changes.** Attribution updates automatically since it's resolved at display time from the student's current profile.
- **Module-page gallery has fewer than N examples.** Show what we have; no "minimum" hides the gallery in-context — that's the dedicated library's concern.

## Test plan

### V1

- **Unit**
  - Staff CRUD: only authorized roles can create / edit / hide / delete model essays.
  - Library and module-page gallery queries return published (non-hidden) model essays only.
  - Filter combinations (grade level × assignment type × module) return correct results.
  - Attribution renders as "Model essay" — never surfaces `created_by`, drafting provenance, or any AI framing.
- **Integration**
  - A newly created model essay appears in the relevant module-page gallery immediately.
  - Hiding a model essay removes it from both surfaces immediately.
  - Tagging an essay against a deleted AssignmentType auto-hides it from student surfaces.
- **E2E (Playwright)**
  - Staff happy path: author logs in, creates a model essay, tags it, publishes, opens student view in another session, sees it on the module page and in the library.
  - Library filters and free-text search return expected results.

### V2

- **Unit**
  - Consent state machine: every valid transition succeeds; every invalid transition is rejected.
  - Anonymized attribution renders grade level only — never first/last name, school, or other identifying data.
  - Eligibility check: nomination action appears only when `numericPercentage >= 90`.
- **Integration**
  - Grade-release flow surfaces the consent prompt to the student.
  - Withdrawal (by either party) removes the essay from both module-page gallery and library query results immediately.
  - Grade re-adjusted below 90% before release auto-rescinds the nomination.
- **E2E (Playwright)**
  - Full happy-path flow once the consent model is chosen: teacher nominates → teacher releases grade → student consents → guardian consent recorded → essay appears in module-page gallery and dedicated library alongside V1 model essays.
  - Decline paths (student declines, guardian declines): essay never appears in either surface.
  - "Decide later" path: state persists; prompt re-surfaces in profile settings.
- **Manual QA**
  - Visual review: confirm no PII beyond grade level visible anywhere on either surface; confirm V1 model essays and V2 student essays are visually distinguishable by attribution alone.

## Rollout

Two feature flags so the work can ship independently:

- `essay_examples_enabled` — gates V1 (admin surface, library, module-page gallery).
- `essay_examples_student_nominated_enabled` — gates V2 (nomination action, consent flow, V2 query inclusion).

### V1: model essays

0. Build admin route + `model_essays` table + library/gallery surfaces.
1. Kevin drafts the initial 10–15 model essays across the major assignment types and grade levels.
2. Flip V1 flag for UA. Then Washington, then Birmingham City.
3. Watch usage signals: library traffic, time-on-essay, teacher links into assignments.

No pre-launch legal dependencies for V1.

### V2: student exemplars

0. **Pre-launch dependencies.** Parental-consent model + mechanism + parent-contact-collection path resolved and built (see open questions); ToS and privacy-policy language updated; school-services contract addendum (if needed) signed. None of the V2 user-facing surfaces ship until these are done.
1. **Single-pilot-teacher seed.** Start with one actively-grading teacher at UA who's willing to nominate. Goal: build a baseline of ~10–20 fully-consented exemplars (student + guardian) before opening the V2 consent prompt to students broadly. Expect lower yield than naive consent counts because of the second gate — plan accordingly.
2. **Flip V2 flag for UA** once the seeded pool clears the 5-essay reveal threshold for the student consent prompt.
3. **Expand to Washington and Birmingham City** after V2 has been validated for tone/quality at UA.

Both V1 and V2 default to OFF until pilot validation.

## V3 ideas (post-launch backlog)

- **Upvoting.** Students can upvote helpful examples; upvotes sort the gallery and library. Separate `EssayExampleUpvote` table keyed on `(entry_id, profile_id)` with a uniqueness constraint, where `entry_id` resolves across both V1 and V2 sources. The most natural V3 enhancement — surfaces "what's actually teaching" without curation effort.
- **Enhanced essay display.** Show the rubric breakdown alongside the essay — which categories scored high and what makes the writing work. Turns a model essay into a teaching tool, not just an example to admire. (Applies to V1 model essays straightforwardly; for V2 student essays it depends on whether the teacher's grading detail can be safely surfaced.)
- **Teacher visibility into reach (V2).** Show teachers a summary: "An essay you nominated from your class is being used as an example in 14 classes." Good for morale; zero effort for the student.
- **Partial-identity option (V2).** Offer students the choice of first name + grade level if they want to be credited by name. Keep grade-only as the default. (Pending legal sign-off on minors.)
- **My Contributions panel (V2).** Section in student profile settings where they can see all their nominated essays and toggle consent on/off in one place.
- **Teacher manual nomination below threshold (V2).** Allow teachers to nominate essays under 90% if they see something exceptional — e.g., a deeply personal essay that demonstrates voice even if structure isn't perfect.
- **Inline comment view (V2).** Optionally surface the teacher's inline comments on the example essay (with teacher approval), showing students not just what a good essay looks like but why it's good at the sentence level.
- **Cross-assignment examples.** Surface examples from similar assignment types across modules — useful for skill-building (e.g., "good hooks from across all thesis-driven essays").
- **Structured peer feedback tags.** Beyond raw upvotes, let students mark what they found helpful: "Good hook," "Clear structure," "Strong voice" — richer signal than a thumbs-up count.

## Engineering handoff checklist

- [ ] Domain context covered
- [ ] File paths in `yawp-2.0` listed
- [ ] Data model implications spelled out, including backward-compat plan
- [ ] UX sketch in prose
- [ ] Edge cases enumerated
- [ ] Test plan written
- [ ] Rollout plan decided