Design an attendance app for a tutoring academy with parent notifications

## Role and objective

You are a product designer and UX architect. Design a tutoring academy attendance app that records attendance and supports notifications to parents. Produce a screen and user-flow design specification for the people who will use, review, or build the app: academy staff, parents, and the implementation team.

Use only the confirmed brief and clearly marked assumptions. Treat every missing product decision as a slot rather than inventing it.

Completion means the specification covers the attendance workflow, parent-notification workflow, all required screen states, accessibility behaviour, and the design tokens needed to implement a coherent interface. The final response must be a Markdown document with the required sections, tables where requested, and no unmarked invented requirements.

## Scope and given facts

In scope:

- An attendance app for a tutoring academy.
- Attendance-related screens and interactions.
- Parent notifications connected to attendance events.
- Staff-facing and parent-facing experiences where needed to complete the workflow.
- Loading, empty, and error states.
- Keyboard operation and screen-reader labelling.
- Responsive and accessible interface requirements.

Confirmed facts from the request:

- Product type: attendance app.
- Context: tutoring academy.
- Required related capability: parent notifications.

Out of scope unless explicitly supplied or necessary to describe an integration boundary:

- Student grading, payments, lesson content, transportation, payroll, admissions, or general academy administration.
- Backend architecture, implementation code, vendor selection, or legal conclusions.
- Notification content, delivery timing, user roles, attendance statuses, and escalation rules beyond the confirmed requirement.

Use these slots for unresolved decisions:

- `[FILL IN: user roles and permissions]` — specify which academy users can view, create, edit, approve, or correct attendance.
- `[FILL IN: notification channels and timing rules]` — specify channels such as in-app, email, SMS, or push, and when each notification is sent.
- `[FILL IN: target platform and technical constraints]` — specify web, iOS, Android, or another platform and any implementation limits.

Do not fill the “parent notifications” requirement with invented message text, delivery guarantees, or timing.

## Working rules

Judge each proposed screen by whether its purpose is explicit, its primary user action is identifiable, and its data is sufficient to complete the attendance or notification task without unnecessary scope. For every flow, identify the initiating user, required inputs, resulting state, and next available action.

Apply the UI modality rules:

1. Preserve any fixed brand description as `brandAnchor` if one is later provided. No `brandAnchor` was supplied here, so do not invent branding.
2. Always specify loading, empty, and error states for each relevant screen.
3. Name keyboard operation requirements and screen-reader labels as implementation requirements, not optional polish.
4. Define how attendance records are created, reviewed, corrected, and displayed only when supported by confirmed requirements or marked slots.
5. Treat notification status as distinct from attendance status. If the brief does not establish delivery states, use `[FILL IN: notification status model]`.

For jurisdiction-specific accessibility handling, set the accessibility target to WCAG 2.2 AA and ask whether ADA Title III or Section 508 governs the intended audience. Do not assume either regime applies. Require the layout to remain usable at 200% zoom and at a 320px viewport without horizontal scrolling. Specify date, number, currency, and address formats explicitly; if a format is unnecessary for this attendance product, state that it is not used rather than inventing one.

When a requirement has two valid paths, branch explicitly: if staff record attendance in real time, describe the live check-in path; if staff enter attendance later, describe the retrospective-entry path. If parents can acknowledge notifications, include that branch only when `[FILL IN: parent acknowledgement behaviour]` is confirmed.

## Output structure

Produce the answer in this order:

1. **Goal and stack** — State the product goal, confirmed users, platform as `[FILL IN: target platform and technical constraints]`, and any confirmed technology or dependency information. Do not invent a stack.
2. **Numbered acceptance criteria** — Provide observable criteria for attendance capture, attendance visibility, parent-notification initiation, notification status handling, permissions, responsive behaviour, accessibility, and the three required interface states. Mark unresolved criteria with their relevant slots.
3. **Edge cases** — Cover duplicate attendance entry, missing student records, late or corrected attendance, unavailable notification channels, failed notification delivery, unauthorized edits, offline or interrupted submission, and conflicting updates. For each, state the visible outcome, user action, and data-preservation rule. Where the brief does not determine behaviour, use a slot.
4. **How it is verified** — Give test scenarios tied to the acceptance criteria. Include keyboard-only navigation, screen-reader labels, 200% zoom, 320px viewport, loading, empty, error, attendance correction, and parent-notification failure tests.

Use tables for the screen inventory, state matrix, acceptance criteria, edge cases, and verification scenarios. Include, for every screen, its user, purpose, entry point, primary action, data displayed, and exit path. Allocate enough detail to make the specification implementable, but do not add unrelated academy-management features.

The output contract is:

- Markdown only.
- Use the four required top-level content parts in the stated order.
- Include screen list, components per screen, behaviour per state, and design tokens.
- Include loading, empty, and error behaviour.
- Include keyboard and screen-reader requirements.
- Include WCAG 2.2 AA, 200% zoom, and 320px viewport checks.
- Use `[FILL IN: item]` for every unresolved value.
- Do not provide production code or invented technical facts.

## Style rules

Use a hybrid style. Use concise tables and numbered lists for screens, criteria, states, edge cases, and tests. Use short narrative paragraphs for the product goal, workflow rationale, accessibility decisions, and scope boundaries. Keep the register professional, operational, and understandable to both academy staff and parents. Avoid generic product clichés such as “seamless experience,” “revolutionize attendance,” “best-in-class,” and “one-stop solution.” Do not use promotional claims.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that every proposed feature serves attendance recording, attendance visibility, or parent notifications for the tutoring academy.
2. Confirm that the deliverable follows the required order: goal and stack, numbered acceptance criteria, edge cases, and how it is verified.
3. Check that user roles and permissions remain `[FILL IN: user roles and permissions]` unless the input supplies them.
4. Check that notification channels and timing are not invented and remain `[FILL IN: notification channels and timing rules]` where unresolved.
5. Check that no target platform, runtime, framework, or dependency was filled arbitrarily.
6. Check that loading, empty, and error states appear for every relevant attendance and notification screen.
7. Check that keyboard operation and screen-reader labels are explicit requirements.
8. Check that WCAG 2.2 AA, ADA Title III or Section 508 applicability, 200% zoom, and the 320px viewport are addressed without assuming legal applicability.
9. Check that attendance status and notification status are not conflated.
10. Check that edge cases include duplicate entries, corrections, failed delivery, unauthorized edits, interruption, and conflicting updates.
11. Check that no facts were added beyond the brief, including invented academy names, student data, notification promises, or technical specifications.
12. Check that no unresolved slot was filled with a plausible guess, especially the parent-notification rules.
13. Check that the work has not drifted into grading, payments, lesson management, or unrelated academy administration.
14. Confirm that all tables and test scenarios are concrete enough to verify, while unsupported behaviours are marked with the appropriate slot.