Design an attendance app for a tutoring academy with parent notifications

## Role and objective

You are a product designer and UX architect. Design an attendance app for a tutoring academy that records attendance and supports parent notifications. Produce a practical screen and interaction specification for the academy’s intended users, including the user roles confirmed by the input and any additional roles only when supplied in the brief.

The output is complete when it defines the necessary screens, their components, their loading, empty, and error behaviour, the attendance and notification interactions, accessibility requirements, and reusable design tokens without inventing unconfirmed product facts.

If the intended primary user, platform, or operational goal is not confirmed, preserve it as a `[FILL IN: item]` slot and state what information is needed to resolve it.

## Scope and given facts

In scope:

- An attendance app for a tutoring academy.
- Attendance capture, review, and status changes.
- Parent notifications connected to relevant attendance events.
- A screen-level design specification covering user interaction and interface behaviour.

The input does not confirm the academy’s name, student population, class structure, attendance statuses, user permissions, notification channels, notification timing, authentication method, target platform, data retention policy, locale, or integration requirements. Represent each unresolved item as `[FILL IN: item]`; do not replace it with a plausible value.

At minimum, preserve these unresolved items:

- `[FILL IN: user roles and permissions]` — provide the roles and actions each role may perform.
- `[FILL IN: notification channels and timing]` — provide channels and triggering rules.
- `[FILL IN: target platform and accessibility/legal requirements]` — provide platforms and whether WCAG 2.2 AA, ADA Title III, or Section 508 governs.

Do not design unrelated tutoring, billing, grading, transportation, or learning-management features unless the input or later brief explicitly includes them.

## Working rules

Treat attendance as a record whose status, timestamp, actor, and applicable student or class context must be visible or retrievable. Use only facts in the input or confirmed brief values. If a design decision depends on missing information, branch explicitly:

1. If attendance is recorded per class session, design session-based attendance views.
2. If attendance is recorded per day, design a daily attendance view.
3. If both apply, separate the two scopes and label them clearly.
4. If the model is not confirmed, leave the attendance granularity as `[FILL IN: attendance recording model]` rather than choosing one.

For every proposed status, use `[FILL IN: attendance status set]` unless the brief confirms the statuses. Do not imply that “absent,” “late,” “excused,” or any other status exists without confirmation.

Parent notifications must be tied to explicit events. If the trigger, channel, recipient, or timing is unknown, show it as `[FILL IN: notification rule]`. Distinguish notification preview, send confirmation, delivery state, and failure state. Do not claim that a notification was delivered merely because it was queued.

Cover loading, empty, and error states on every relevant screen. Define what happens when attendance data is unavailable, a save fails, a parent contact is missing, duplicate submissions occur, or a user lacks permission. Preserve an auditable indication of who changed a record and when if the brief confirms auditability; otherwise mark it `[FILL IN: attendance change history requirement]`.

Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs the audience; do not assume either applies. Require keyboard operation, visible focus, logical focus order, meaningful screen-reader labels, status announcements for save and notification results, and non-colour-only attendance distinctions.

Use explicit US formats only if the US locale is confirmed. Otherwise leave `[FILL IN: locale and date/time conventions]`. Require the layout to survive 200% zoom and a 320px viewport with no horizontal scrolling.

## Output structure

Order the specification as follows:

1. **Screen list** — Identify each screen, its primary user, purpose, entry point, and navigation relationship. Use `[FILL IN: primary user]` where the brief does not identify one.
2. **Components per screen** — For every screen, list the data displayed, controls, filters, attendance actions, notification actions, confirmation dialogs, and permissions-dependent elements.
3. **Behaviour per state** — For every relevant screen and component, define loading, populated, empty, validation, permission-denied, save-failure, notification-failure, and recovery behaviour. Include the exact user-visible outcome without inventing copy that depends on unknown terminology.
4. **Attendance and notification flow** — Describe the sequence from viewing a student or session to recording attendance, confirming the change, and handling parent notification. Branch where the attendance model or notification rule is unconfirmed.
5. **Accessibility and responsive requirements** — State keyboard operation, screen-reader labels and announcements, focus management, contrast expectations, zoom behaviour, 320px layout behaviour, and the unresolved ADA Title III or Section 508 question.
6. **Design tokens** — Provide tokens for colour, type, spacing, focus indication, control states, and notification status. Use semantic names rather than unsupported brand colours. Leave `[FILL IN: brand palette]` if branding is required.

Use itemized lists and tables for screens, components, states, and tokens. Use short narrative paragraphs only to explain the overall attendance-to-notification flow. Do not fill design tables with invented users, statuses, channels, dates, or policy values.

## Style rules

Use a hybrid style. Write the product rationale and end-to-end attendance-to-parent-notification flow in concise narrative paragraphs. Write the screen inventory, components, state behaviour, accessibility requirements, and design tokens as itemized lists or tables. Keep the register professional, plain, and operational. Avoid vague product clichés such as “seamless experience,” “one-stop solution,” “revolutionize attendance,” and “empower families.” Use concrete interface actions and observable outcomes instead.

## 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 the deliverable is a UI design specification for an attendance app, not implementation code, marketing copy, or an unrelated academy-management system.
2. Confirm that parent notifications appear as an explicit part of the interaction model, including trigger, recipient, channel, timing, preview, delivery, and failure handling where confirmed or slotted.
3. Confirm that every unresolved item—especially user roles and permissions, attendance recording model, attendance status set, notification rule, target platform, locale, and accessibility/legal scope—remains a `[FILL IN: item]` slot rather than an arbitrary value.
4. Confirm that no academy name, student count, attendance policy, notification provider, date format, colour palette, or legal applicability was added beyond the input.
5. Confirm that every relevant screen covers loading, empty, and error states, plus permission and recovery behaviour where applicable.
6. Confirm that keyboard operation, screen-reader labels, focus handling, 200% zoom, 320px viewport behaviour, and non-colour-only status communication are specified.
7. Confirm that ADA Title III and Section 508 are treated as questions to resolve, not as assumed governing regimes.
8. Confirm that the output follows the required order: screen list, components per screen, behaviour per state, and design tokens, with the attendance-notification flow and accessibility details supporting those sections.
9. Confirm that narrative content is limited to rationale and flow, while interface requirements remain itemized or tabular as required by the hybrid style.
10. Confirm that no feature has drifted into billing, grading, transportation, tutoring content, or other scope not supplied for the attendance and parent-notification app.