Design an attendance app for a tutoring academy with parent notifications

## Role and objective

You are a product designer creating a screen and user-flow specification for an attendance app used by a tutoring academy. Produce a design that enables authorized academy staff to record attendance and enables parents to receive relevant attendance notifications. Do not assume features, policies, users, platforms, or notification rules that the input does not confirm; use slots for them.

The deliverable must be a structured UI specification covering screens, components, state behaviour, accessibility, formatting, and design tokens. Completion is demonstrated when an implementer can identify the required screens, understand each screen’s loading, empty, and error behaviour, and trace how an attendance action leads to a parent notification without relying on invented requirements.

## Scope and given facts

In scope:

- Attendance management for a tutoring academy.
- Parent notifications connected to attendance.
- The interface and user flow needed to support these functions.
- Staff- or tutor-facing actions only where necessary to record or correct attendance.
- Parent-facing information only where necessary to receive or review attendance notifications.

Confirmed facts from the input:

- The product is an attendance app.
- The organization is a tutoring academy.
- Parent notifications are required.

Leave the following as slots unless the user supplies them:

- Platform: [FILL IN: target platform and supported devices; fill this with the confirmed web, iOS, Android, or cross-platform target].
- Roles: [FILL IN: authorized user roles; fill this with the academy’s confirmed staff, tutor, administrator, and parent permissions].
- Attendance model: [FILL IN: attendance statuses and correction policy; fill this with the academy’s approved statuses and rules].
- Notification triggers: [FILL IN: events and delivery channels; fill this with the academy’s confirmed notification events and channels].
- Privacy requirements: [FILL IN: governing privacy requirements; fill this with the applicable requirements confirmed by the academy].

Do not arbitrarily fill the attendance statuses, notification triggers, platform, or privacy requirements.

## Working rules

Apply the UI modality rules. Preserve any fixed brand description only if the input later supplies a `brandAnchor`; otherwise use `[FILL IN: brand description]`. Always specify loading, empty, and error states for every relevant screen. Treat keyboard operation and screen-reader labels as required design items, not optional implementation notes.

Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs the intended audience; if unknown, mark it `[VERIFY]` rather than deciding. Require the design to remain usable at 200% zoom and at a 320px viewport without horizontal scrolling.

Judge each proposed interaction against these conditions:

1. If a user records attendance, show confirmation, the resulting status, and the notification outcome or pending state.
2. If an attendance record is missing, show an empty state that explains the next available action without implying that the learner was absent.
3. If a notification fails, show an actionable error and preserve or identify the attendance record’s status; do not claim delivery.
4. If a user lacks permission, show an authorization state and do not expose controls for restricted actions.
5. If a status or trigger is unconfirmed, use `[FILL IN: attendance status or notification trigger]` and state what information is needed.

State date, number, currency, and address formats explicitly where those fields appear. Do not add fields merely because they are common in academy software. Ground every requirement in either the user’s input, a clearly labelled slot, or a cited accessibility or platform reference. Mark any external requirement or unresolved applicability `[VERIFY]`.

## Output structure

Order the specification as follows:

1. **Screen list** — name each required screen, identify its user role, and state its primary purpose. Include only screens needed for attendance recording, attendance review, notification handling, and access or error recovery.
2. **Components per screen** — list navigation, learner or class context, attendance controls, status indicators, notification controls, confirmation elements, and accessibility labels where applicable. Mark unconfirmed components with `[FILL IN: component or rule]`.
3. **Behaviour per state** — for each screen, describe normal, loading, empty, error, unauthorized, and notification-pending or notification-failed behaviour where relevant. Include the transition from attendance submission to parent notification. Distinguish “record saved” from “notification delivered.”
4. **Design tokens** — specify colour, type, spacing, focus treatment, status differentiation, and responsive rules. Use `[FILL IN: token value]` for values not provided. Ensure status meaning is not conveyed by colour alone.
5. **Open decisions** — list only unresolved slots and the exact information needed to resolve each.

Use concise tables or bullet lists for the screen list, component inventory, state matrix, and design tokens. Use short narrative paragraphs only to explain the end-to-end attendance-to-notification flow and accessibility rationale. Do not produce implementation code or invent visual values.

## Style rules

Use a hybrid style. Present screens, components, states, tokens, and unresolved decisions in itemized form; write the user-flow explanation and rationale as brief narrative paragraphs. Use a clear product-design register suitable for academy administrators and implementation teams. Avoid vague interface clichés such as “seamless experience,” “intuitive design,” “robust solution,” and “keep users in the loop.” Replace them with observable actions, states, and outcomes.

## 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 and user-flow specification, not a finished app, codebase, or marketing description.
2. Confirm that every required feature is tied to the subject: tutoring-academy attendance or parent notifications.
3. Confirm that the platform, roles, attendance statuses, notification triggers, privacy requirements, and brand details remain slots when absent from the input.
4. Confirm that no slot for the target platform was filled arbitrarily with web, iOS, Android, or cross-platform.
5. Confirm that no attendance status, parent notification event, delivery channel, or correction policy was invented.
6. Confirm that every relevant screen includes loading, empty, and error behaviour.
7. Confirm that keyboard operation, screen-reader labels, WCAG 2.2 AA, 200% zoom, and the 320px viewport are addressed.
8. Confirm that ADA Title III or Section 508 applicability is marked `[VERIFY]` when not supplied.
9. Confirm that the design distinguishes an attendance record being saved from a parent notification being delivered.
10. Confirm that facts added beyond the user’s input are either grounded in a named requirement or visibly marked `[VERIFY]`.
11. Confirm that no work drifts into unrelated academy functions such as billing, curriculum, grading, or student messaging unless explicitly required.
12. Confirm that tables and lists contain no invented values, dates, currencies, addresses, metrics, or design-token numbers.
13. Confirm that the hybrid style boundary is followed: operational inventories are itemized, while flow rationale is narrative.
14. Confirm that the final specification is implementable without silently resolving any remaining `[FILL IN]` slot.