Design an attendance app for a tutoring academy with parent notifications

## Role and objective

<instructions>
You are a product designer creating an attendance-management app for a tutoring academy. Design the screens, components, states, interactions, accessibility behaviour, and notification flow for academy staff, tutors, students, and parents. Produce a practical UI specification rather than implementation code.

Before presenting conclusions, show concise reasoning steps: identify the users and tasks, map the attendance flow, resolve ambiguities through explicit branches, and justify the proposed structure.

The output form is a screen-and-flow specification organized by the required sections below. Completion means every required screen state, accessibility item, US-format item, and parent-notification interaction is either specified from the given facts or marked with the correct slot.
</instructions>
<context>
The confirmed request is: “Design an attendance app for a tutoring academy with parent notifications.”

Unconfirmed project values must remain slots. Fill each slot only with information supplied by the requester or a later confirmed answer. For example, [FILL IN: platform and target devices] must be filled with the supported platform and devices, not guessed from common academy practice.
</context>
<output_format>
Return the design specification in the required section structure. Include reasoning before the final design decisions, while keeping the reasoning concise and directly tied to the attendance and notification experience.
</output_format>

## Scope and given facts

<instructions>
In scope: attendance recording, attendance status management, academy-facing workflows, parent notifications, student and parent-facing visibility where needed, and the screens required to support these flows.

Out of scope unless later confirmed: curriculum management, payments, grading, messaging unrelated to attendance, staff payroll, and technical implementation details.

Treat only these facts as confirmed:
- The product is an attendance app.
- The setting is a tutoring academy.
- Parent notifications are required.

Use these slots for missing project facts:
- [FILL IN: platform and target devices]
- [FILL IN: brand description or brandAnchor, if any]
- [FILL IN: attendance statuses and correction policy]
- [FILL IN: notification channels and message requirements]
- [FILL IN: date, number, currency, and address-format requirements, if applicable]

Add one line after the slot list explaining that the requester must replace each slot with the corresponding confirmed project requirement. Do not invent a project name, academy identity, attendance policy, notification timing, legal obligation, or visual brand system.
</instructions>
<context>
The design must work for the academy context while keeping academy-specific policy decisions visibly unresolved until confirmed.
</context>
<output_format>
Present the scope as two brief lists: “In scope” and “Out of scope,” followed by “Confirmed facts” and “Information to fill in.”
</output_format>

## Working rules

<instructions>
Use this sequence before designing:
1. Identify each actor’s attendance task and permission need.
2. Map the normal flow from class selection to attendance recording to parent notification.
3. Identify exceptions such as late arrival, absence, duplicate recording, correction, failed notification, and offline or unavailable service.
4. Choose a design only where the input supports it; otherwise branch explicitly.

For every proposed screen, judge whether it lets the intended user complete a defined task, see the current attendance state, recover from an error, and understand whether a parent notification was sent. Do not treat a notification as successful merely because a user pressed “send.”

If attendance statuses are confirmed, use them exactly. If they are not confirmed, label status choices as [FILL IN: attendance statuses and correction policy] and show the interface as a policy-dependent design. If notification channels are confirmed, map the design to them. If not, use [FILL IN: notification channels and message requirements] and do not assume SMS, email, push, or any other channel.

Keep academy staff and tutor permissions separate unless the input confirms they are identical. If permissions are unknown, show the distinction as a decision branch rather than selecting one arbitrarily.

Set the accessibility target as WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs the audience, and leave the applicable answer as [FILL IN: governing accessibility regime] until confirmed. Require keyboard operation, visible focus, sufficient non-colour status cues, and screen-reader labels.

Use US date, number, currency, and address formats explicitly where those fields appear. Leave the exact formats as [FILL IN: US formatting requirements] if the product requirements do not specify them. Require the layout to survive 200% zoom and a 320px viewport without horizontal scrolling.

For parent notifications, show recipient, event, status, timestamp, channel, and delivery state only when those data are available. Do not invent retention periods, consent rules, or statutory applicability; mark unresolved governance items [VERIFY].
</instructions>
<context>
The central workflow is attendance tracking for a tutoring academy with parent notifications. No platform, brand, policy, channel, or accessibility-governance details were supplied.
</context>
<output_format>
Use the reasoning sequence first. Then apply the design rules to the screen list, user flows, states, permissions, and notification behaviour.
</output_format>

## Output structure

<instructions>
Produce the following four parts in order:

1. Screen list — list each screen, its primary user, purpose, entry point, and exit path. Include only screens needed for attendance and parent notifications.
2. Components per screen — identify controls, data displayed, action labels, validation, permissions, keyboard operation, and screen-reader labels.
3. Behaviour per state — specify loading, empty, error, success, offline or unavailable-service, duplicate-entry, correction, and failed-notification behaviour wherever relevant. State the user-visible message and recovery action; leave exact copy as [FILL IN: approved interface copy] if not supplied.
4. Design tokens — specify colour roles, typography, spacing, focus treatment, status indicators, and notification indicators. If no brandAnchor is supplied, use [FILL IN: brand description or brandAnchor, if any] rather than inventing brand values.

Include the parent-notification flow in the relevant screens: when a notification is triggered, what the user can review, how delivery is represented, and how a failed delivery is retried or escalated. Do not imply a delivery channel or timing that has not been confirmed.

Show reasoning before the final recommendations. Use concise tables or lists for screen and component inventories, but explain important workflow choices in short prose.
</instructions>
<context>
The deliverable is a UI design specification for an attendance app used in a tutoring academy, including parent notifications.
</context>
<output_format>
Use headings and compact tables for inventories. Keep unresolved values as slots. Include a short rationale for the selected information architecture and notification flow before the final token specification.
</output_format>

## Style rules

<instructions>
Use a hybrid style. Use itemized form for the screen inventory, component specifications, state rules, design tokens, permissions, and verification criteria. Use short narrative paragraphs for the reasoning, workflow rationale, and explanations of branches.

Keep the register professional, clear, and operational. Avoid generic product clichés such as “seamless experience,” “next-generation solution,” “revolutionary platform,” and “empower users.” Prefer concrete interface language, explicit conditions, and observable outcomes.
</instructions>

## 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

<instructions>
Before delivery, run this numbered checklist and report the result briefly:

1. Confirm that the design remains an attendance app for a tutoring academy and does not become a general school-management product.
2. Confirm that parent notifications appear in the workflow, screen components, relevant states, and delivery-status handling.
3. Confirm that every unresolved platform, brand, attendance-policy, notification-channel, and governance value remains a slot or [VERIFY] marker.
4. Confirm that no attendance status, notification timing, channel, permission model, legal rule, or interface copy was invented.
5. Confirm that loading, empty, error, success, offline or unavailable-service, duplicate-entry, correction, and failed-notification states are covered.
6. Confirm that keyboard operation, screen-reader labels, WCAG 2.2 AA, 200% zoom, and 320px viewport requirements are addressed.
7. Confirm that US date, number, currency, and address-format decisions are explicit wherever relevant rather than silently assumed.
8. Confirm that each screen has a purpose, user, entry path, exit path, and permission treatment.
9. Confirm that the final deliverable is a UI and user-flow specification, not code or an invented finished product.
10. Confirm that the reasoning precedes the conclusions and that hybrid formatting is visibly maintained.
11. Confirm that no content was added beyond the supplied request except clearly marked design requirements or unresolved slots.
12. Confirm that no section drifts into payments, grading, curriculum, payroll, or unrelated messaging.

After the checklist, state the total number of checks completed: 12.
</instructions>
<context>
The self-check must use the actual request details: attendance, tutoring academy, and parent notifications.
</context>
<output_format>
Provide the checklist as a numbered list followed by a one-line count.
</output_format>