Release 2 Daily Administration, Medical, Operational Workforce, Communication, And Compliance User Stories#

Scope note#

This file assumes the agreed Release 2 scope is:

full medical IMP and ISP lifecycle workflows become native read-write workflows in the new platform
allergy IAP lifecycle and allergy-and-food plan approval workflows become native read-write workflows for enrolled-child changes
medication compliance follow-up, exception review, notice history, and audit workflows use Release 1 medication authorization and administration records as their source
incident and illness workflows move beyond Release 1 event capture into supervisor review, parent notification history, serious-occurrence notices, and compliance follow-up
parent, staff, room, and campus communications become native message workflows with delivery history and notification queues
operational workforce scheduling, staff attendance review, ratio review, and timecard-preparation workflows become native operational workflows
staff can sign into the app with Auth0, be matched to imported staff state by email, view their own schedule and timecard, submit leave requests, and send documents
building, health-and-safety, fire-drill, water-flushing exception review, kitchen temperature exception review, and facilities evidence workflows become native compliance workflows
repair orders and maintenance work orders are not native Release 2 workflows; Release 2 links checklist and compliance items to the stakeholder-maintained external repair and maintenance system
Release 2 does not include new-hire intake, HR staff profile administration, staff qualification maintenance, leave balance administration, or staff review administration; those remain Release 3 scope
Release 2 does not include enrollment or finance ownership; those remain Release 3 scope

Module And Role Index#

Role	Primary Release 2 modules	Story numbers
Health leads and program supervisors	medical plan lifecycle, allergy `IAP` workflow, medication exception review, medication audit follow-up, incident and illness review, health dashboards	`1-14`, `27`, `37-40`
Classroom staff and educators	event follow-up, staff plan acknowledgment, allergy `IAP` acknowledgment, parent and room communications	`5`, `11-13`, `15-18`, `40`
Parents and guardians	plan signatures, allergy-and-food approvals, medication and event notices, pending approvals, message delivery, communication history	`4`, `7`, `10`, `12`, `15-17`, `19-20`, `39`
Campus supervisors and district managers	campus health queue, allergy and food-plan follow-up, cross-room communication, attendance review, ratio review, compliance queue, escalation dashboards	`6`, `11`, `14`, `16`, `18`, `20-24`, `27`, `37-40`
Payroll-adjacent operations users	attendance exception review, timecard preparation, attendance export, schedule-to-attendance reconciliation	`21-24`
Staff members	`Auth0` sign-in, self-service schedule view, self-service timecard view, leave request submission, document submission	`32-36`
Compliance and quality users	allergy and food-plan review, plan completeness, medication exception review, incident quality, parent notice evidence, checklist compliance, external repair links, fire drills, audit review	`6`, `8-11`, `14`, `25-31`, `37-39`
Operations and maintenance coordinators	health-and-safety checklists, external repair-system links, kitchen temperature exception follow-up, water-flushing exception follow-up, fire drills, facilities follow-up	`25-31`
System jobs and delivery services	plan-generation jobs, renewal reminders, dashboard items, notification routing, delivery retries, repair-link synchronization, fire-drill reminders, audit locking, staff identity linking support, allergy-and-food state tracking, and request routing	`3`, `6`, `7`, `14`, `19`, `24`, `26-31`, `32`, `35-36`, `37-40`

Story Modules#

Module	Primary roles	Stories	Ownership	Evidence
Medical Plan Lifecycle: `IMP` And `ISP`	Health lead, program supervisor, parent, staff, system	`1-7`	`Read-write native`	Legacy medical and support-plan workflows clearly show end-to-end draft, approval, signature, renewal, and staff-acknowledgment needs.
Medication, Incident, Illness, And Health Follow-Up	Supervisor, health lead, parent, compliance	`8-14`	`Read-write native`	Existing health operations show a separate layer of exception review, notices, parent follow-up, and compliance oversight around daily records.
Communication, Messaging, And Notifications	Staff, supervisor, parent, district manager, system	`15-20`	`Read-write native`	Legacy communications support room, child, parent, staff, and campus messaging with delivery and history tracking.
Operational Workforce Scheduling And Attendance Review	Supervisor, operations user, payroll-adjacent user, system	`21-24`	`Read-write native`	Current workforce operations include schedule review, attendance reconciliation, ratio visibility, exports, and timecard preparation.
Compliance Dashboards, Facilities, And Evidence	Compliance, quality, operations, maintenance coordinator, supervisor, system	`25-31`	`Read-write native with external repair-system integration`	Existing compliance workflows rely on exception queues, checklist evidence, fire-drill tracking, facilities follow-up, and links to the external repair system.
Staff Self-Service Identity, Schedule, And Requests	Staff member, supervisor, HR coordinator, system	`32-36`	`Read-write native`	Release 2 adds staff self-service sign-in, schedule and timecard visibility, leave requests, and document submission on top of imported staff context.
Allergy `IAP` And Allergy/Food Plan Approval	Health lead, supervisor, parent, staff, compliance, system	`37-40`	`Read-write native`	Existing allergy operations show enrolled-child allergy maintenance, formal allergy-plan approval, parent sign-off, and staff acknowledgment needs.

Module: Medical Plan Lifecycle: `IMP` And `ISP`#

Primary roles: Health lead, program supervisor, parent, staff, system

Purpose: Create, review, sign, renew, archive, and audit medical and support plans in the new platform instead of treating imported FileMaker plans as read-only classroom context.

Evidence: Directly evidenced by the legacy medical and support-plan workflows, including draft creation, approval, signature, staff acknowledgment, archival history, and health-context relationships.

Included stories: Story 1, Story 2, Story 3, Story 4, Story 5, Story 6, Story 7

Story 1#

Title#

Create and edit a child IMP from medical-condition context

User Story#

As a health lead I want to create and edit a child IMP from the child's medical conditions So that medical plans are current, operational, and owned in the new platform

Acceptance Criteria (Gherkin)#

Feature: IMP creation and editing

Scenario: Create a draft IMP for a child with medical conditions Given a child has active medical-condition records When I create an IMP Then the system should create a draft medical plan And link the plan to the child And copy the relevant medical-condition context into the draft plan

Scenario: Validate required IMP content before approval Given a draft IMP exists When I submit it for approval Then the system should require plan details, risk-reduction steps, emergency actions, responsible staff context, and effective dates And the plan should remain in draft status until all required content is complete

Scenario: Preserve edit audit details Given I update an existing IMP When I save the plan Then the system should store the modifying user, timestamp, changed fields, and prior plan version

Story 2#

Title#

Create and edit a child ISP from special-need context

User Story#

As a health lead I want to create and edit a child ISP from the child's support needs So that individualized support plans are actionable for classroom and supervisor teams

Acceptance Criteria (Gherkin)#

Feature: ISP creation and editing

Scenario: Create a draft ISP for a child with active support needs Given a child has active special-need records When I create an ISP Then the system should create a draft support plan And link the plan to the child And copy the relevant support-need context into the draft plan

Scenario: Validate required ISP content before approval Given a draft ISP exists When I submit it for approval Then the system should require support strategies, symptom or trigger context, classroom guidance, responsible staff context, and effective dates And the plan should remain in draft status until all required content is complete

Scenario: Show active ISP details in classroom context Given an ISP is approved and active When classroom staff open the child's plan context Then the system should show the approved support-plan summary And prevent classroom staff from editing the approved plan unless they have plan-maintenance permission

Story 3#

Title#

Generate missing plan drafts for eligible children

User Story#

As a system administrator I want the platform to identify children who need missing IMP or ISP drafts So that plan creation does not depend on manual FileMaker cleanup scripts

Acceptance Criteria (Gherkin)#

Feature: Missing child plan generation

Scenario: Generate missing IMP drafts Given a child has medical-condition records And the child does not already have an active or draft IMP When the missing-plan job runs Then the system should create a draft IMP for that child And add the draft to the health lead review queue

Scenario: Generate missing ISP drafts Given a child has special-need records And the child does not already have an active or draft ISP When the missing-plan job runs Then the system should create a draft ISP for that child And add the draft to the health lead review queue

Scenario: Avoid duplicate drafts Given a child already has an active, draft, or pending-approval plan of the same type When the missing-plan job runs Then the system should not create another draft for that plan type

Story 4#

Title#

Route child plans for parent signature

User Story#

As a program supervisor I want approved child plans routed to parents for signature So that parent acknowledgment is captured before the plan becomes operational

Acceptance Criteria (Gherkin)#

Feature: Parent plan signature

Scenario: Route an approved plan to parents Given an IMP or ISP has supervisor approval When I send the plan for parent signature Then the system should create a parent signature request And notify the authorized parents or guardians And link the request to the plan version

Scenario: Capture parent signature Given a parent opens a pending plan signature request When the parent signs the plan Then the system should store parent, timestamp, source channel, and signed plan version And mark the signature request complete

Scenario: Keep unsigned plans visible Given a plan requires parent signature And the signature is still missing When the health lead opens the plan queue Then the system should show the missing-signature task with child, plan type, campus, due date, and parent recipients

Story 5#

Title#

Capture staff acknowledgment of approved plans

User Story#

As a program supervisor I want staff acknowledgments captured for approved child plans So that the center can prove staff reviewed the current plan version

Acceptance Criteria (Gherkin)#

Feature: Staff plan acknowledgment

Scenario: Assign staff acknowledgment tasks Given an IMP or ISP is approved When the plan becomes active Then the system should create acknowledgment tasks for assigned staff And include child, plan type, plan version, staff member, and due date

Scenario: Record staff acknowledgment Given a staff member has a pending plan acknowledgment task When the staff member signs the plan acknowledgment Then the system should store staff, timestamp, plan version, and source channel And clear that staff member's active task

Scenario: Add missing staff members to plan acknowledgment tasks Given a staff member is assigned to a room or child after the plan is active When the plan acknowledgment job runs Then the system should add a missing acknowledgment task for that staff member And preserve the original plan version context

Story 6#

Title#

Monitor plan completeness, expiry, and renewal

User Story#

As a health lead or compliance user I want incomplete and expiring plans surfaced automatically So that plan follow-up is handled before classroom risk increases

Acceptance Criteria (Gherkin)#

Feature: Plan completeness and renewal monitoring

Scenario: Detect incomplete plan content Given a draft or active plan is missing required details, signature, or approval evidence When plan monitoring runs Then the system should create or refresh a plan exception And include child, plan type, missing requirement, due date, and responsible role

Scenario: Detect plan expiry Given an active IMP or ISP is approaching its renewal date When renewal monitoring runs Then the system should create a renewal reminder And route it to the health lead or program supervisor

Scenario: Clear resolved plan exception Given a plan exception exists When the source plan is completed, renewed, signed, or archived Then the system should clear the active dashboard item And keep the exception history for audit

Story 7#

Title#

Archive and version child plans

User Story#

As a health lead I want plan revisions archived with version history So that staff see the current plan while auditors can review prior versions

Acceptance Criteria (Gherkin)#

Feature: Plan versioning and archive

Scenario: Archive prior plan version Given an active plan is updated and approved When the new version becomes active Then the system should archive the prior plan version And preserve signatures, acknowledgments, effective dates, and attachment references

Scenario: Show only current plan in operational context Given a child has current and archived plan versions When classroom staff open the plan context Then the system should show the active plan by default And require archive permission to view prior versions

Scenario: Preserve archive audit trail Given a plan version is archived When an authorized user opens the archive history Then the system should show who archived it, when it was archived, the reason, and the replacing version when applicable

Module: Medication, Incident, Illness, And Health Follow-Up#

Primary roles: Supervisor, health lead, parent, compliance

Purpose: Add health-event review, medication exception monitoring, parent notice audit, serious-occurrence notices, and compliance follow-up around Release 1 operational health records.

Evidence: Directly evidenced by the current medication, incident, illness, notice, and serious-occurrence workflows that sit on top of daily health records and compliance review.

Included stories: Story 8, Story 9, Story 10, Story 11, Story 12, Story 13, Story 14

Story 8#

Title#

Monitor medication authorization completeness and renewal exceptions

User Story#

As a health lead or compliance user I want incomplete, expired, or soon-to-expire medication authorizations surfaced from Release 1 medication records So that medication safety follow-up happens without duplicating Release 1 medication entry workflows

Acceptance Criteria (Gherkin)#

Feature: Medication authorization compliance monitoring

Scenario: Detect incomplete medication authorization Given a Release 1 medication authorization is missing required instructions, dosage, date, signature, or storage information When compliance processing runs Then the system should create or refresh a medication authorization exception And include child, room, campus, missing fields, due date, and follow-up owner

Scenario: Detect expiring medication authorization Given a Release 1 medication authorization is expired or approaching expiry When renewal monitoring runs Then the system should create a renewal follow-up item And include medication, child, parent contact context, expiry date, and supervisor owner

Scenario: Clear resolved authorization exception Given a medication authorization exception is tied to a Release 1 authorization record When the source authorization is corrected, renewed, or marked no longer active Then the system should clear the active exception And preserve the exception history for audit

Story 9#

Title#

Review medication administration exceptions from Release 1 records

User Story#

As a supervisor or compliance user I want missed, late, refused, or incomplete medication administrations surfaced from Release 1 records So that follow-up happens without moving classroom administration entry out of Release 1

Acceptance Criteria (Gherkin)#

Feature: Medication administration exception review

Scenario: Detect missed or overdue medication administration Given a Release 1 medication authorization has a due administration window When the due window passes without a completed medication administration entry Then the system should create a medication administration exception And include child, room, authorization, due time, campus, and responsible follow-up role

Scenario: Detect refused, late, or incomplete administration Given a Release 1 medication administration entry exists And the administration is marked refused, late, incomplete, or missing required staff or dosage context When compliance processing runs Then the system should create or refresh the medication follow-up item And link it to the source administration record

Scenario: Complete supervisor follow-up Given a medication administration exception is open When an authorized supervisor records the follow-up decision Then the system should store reviewer, timestamp, action taken, and notes And clear the active exception when follow-up is complete

Story 10#

Title#

Audit parent medication notices and failed delivery follow-up

User Story#

As a supervisor or compliance user I want parent medication notice history and failed delivery follow-up visible from Release 1 medication records So that medication communication is reviewable without duplicating the Release 1 administration workflow

Acceptance Criteria (Gherkin)#

Feature: Medication notice audit

Scenario: Review medication notice history Given a Release 1 medication administration has parent notice evidence When an authorized user reviews medication audit history Then the system should show recipient, channel, delivery status, actor, timestamp, and linked administration record

Scenario: Surface failed medication notice delivery Given a parent medication notice failed or was not confirmed as delivered When delivery monitoring runs Then the system should create a medication notice follow-up item And include child, parent recipient, channel, source administration, failure reason, and retry state

Scenario: Preserve medication notice audit trail Given a medication notice follow-up is resolved When the notice history is reviewed later Then the system should show the original notice, failed or successful delivery attempts, resolution actor, and resolution timestamp

Story 11#

Title#

Complete supervisor review for incidents and illness events

User Story#

As a supervisor I want to review incident and illness records before completion So that event details, signatures, parent notices, and follow-up are complete

Acceptance Criteria (Gherkin)#

Feature: Incident and illness review

Scenario: Review incomplete incident or illness events Given staff have created incident or illness records When I open the health-event summary queue Then the system should show incomplete events by type, room, child, occurrence time, and required follow-up

Scenario: Block completion when required details are missing Given an incident or illness record is missing required detail text, symptoms, actions taken, signature, or notification state When I mark the event complete Then the system should block completion And keep the event in the incomplete queue

Scenario: Lock completed event records Given an incident or illness record has all required detail, signatures, and notification evidence When I mark it complete Then the system should lock the record And remove active pending-review dashboard tasks for that event

Story 12#

Title#

Track parent notification and approval for health events

User Story#

As a parent or guardian I want to receive and acknowledge incident and illness information So that I know what happened and the center has a record of my response

Acceptance Criteria (Gherkin)#

Feature: Parent health-event notification

Scenario: Send initial incident or illness notice Given an incident or illness record is created When the event requires parent notification Then the system should send a parent notice using the configured communication channel And store child, event, room, timestamp, and recipient details

Scenario: Capture parent approval or acknowledgment Given a parent opens a pending health-event approval When the parent acknowledges the event Then the system should store the parent, timestamp, response, and related event ID And remove the pending parent approval from the active queue

Scenario: Keep unresolved approvals visible Given a parent acknowledgment is required and has not been received When a supervisor opens the child health queue Then the system should show the unresolved parent approval with due and escalation state

Story 13#

Title#

Attach health events to communication context

User Story#

As a classroom staff member I want incidents and illness records linked to communication context when they start from a message So that health follow-up and communication history stay connected

Acceptance Criteria (Gherkin)#

Feature: Health-event communication linking

Scenario: Start an incident from a communication record Given a communication record references a child and room When I create an incident from that communication Then the system should create the incident with the child, room, and source communication context And show the linked communication in the incident record

Scenario: Start an illness from a communication record Given a communication record references a child and room When I create an illness from that communication Then the system should create the illness with the child, room, and source communication context And show the linked communication in the illness record

Scenario: Preserve linked health history Given a communication is linked to an incident or illness When an authorized user opens child communication history Then the system should show the related health event without duplicating the message

Story 14#

Title#

Send serious-occurrence notices and compliance alerts

User Story#

As a compliance user I want serious-occurrence notices generated from qualifying health events So that regulatory follow-up is not missed

Acceptance Criteria (Gherkin)#

Feature: Serious-occurrence notices

Scenario: Identify a serious-occurrence event Given an incident or illness event is marked with a serious-occurrence type When the event is saved Then the system should require occurrence type, occurrence timestamp, event date, child, room, and supervisor review details

Scenario: Send serious-occurrence notice Given a serious-occurrence event has required details When the supervisor completes the event Then the system should send the serious-occurrence notice And store notice history, sender, recipients, event type, and timestamp

Scenario: Create compliance follow-up task Given a serious-occurrence notice is sent When the compliance dashboard refreshes Then the system should show the event in the compliance follow-up queue until required follow-up is complete

Module: Communication, Messaging, And Notifications#

Primary roles: Staff, supervisor, parent, district manager, system

Purpose: Replace FileMaker communication surfaces with native parent, staff, room, campus, email, mobile, SMS, in-app, and notification workflows that preserve audience and delivery evidence.

Evidence: Directly evidenced by the current room, child, staff, campus, email, text, and mobile-message workflows, along with their delivery and history tracking.

Included stories: Story 15, Story 16, Story 17, Story 18, Story 19, Story 20

Story 15#

Title#

Send room or child messages to parent mobile accounts

User Story#

As a classroom staff member or supervisor I want to send a message to parents for a room or selected children So that families receive timely operational communication

Acceptance Criteria (Gherkin)#

Feature: Parent mobile messaging

Scenario: Resolve parent mobile audience from a room Given I choose a room audience When I start a parent mobile message Then the system should resolve scheduled children for that room And include parents or guardians with active mobile access for those children

Scenario: Resolve parent mobile audience from selected children Given I choose one or more children When I start a parent mobile message Then the system should include authorized parent mobile accounts for the selected children And show the resolved child-to-recipient mapping before sending

Scenario: Store sent message history Given I send a parent mobile message When delivery is queued Then the system should create a communication record with room, child, sender, message, channel, and timestamp context

Story 16#

Title#

Send parent email with consent and campus context

User Story#

As a supervisor I want parent email recipients filtered by consent and child context So that email communication follows family preferences and preserves campus oversight

Acceptance Criteria (Gherkin)#

Feature: Parent email

Scenario: Resolve opted-in parent emails Given I send an email for a room or child list When the audience is resolved Then the system should include parents who are authorized for the children And exclude parents who are not opted into email communication

Scenario: Include campus oversight context Given a parent email is sent from a campus context When the email is queued Then the system should attach campus, room, child, sender, and district oversight context

Scenario: Store parent email history Given a parent email has been sent When the communication history is reviewed Then the system should show body, sender, recipients, delivery status, related children, and attachments

Story 17#

Title#

Receive and route parent replies

User Story#

As a supervisor or classroom staff member I want parent replies routed to the right room or campus queue So that responses do not depend on external inbox monitoring

Acceptance Criteria (Gherkin)#

Feature: Parent reply routing

Scenario: Route a parent reply to a room inbox Given a parent replies to a room-linked message When the reply is received Then the system should add it to the room inbox And preserve sender, child, original thread, channel, timestamp, and read state

Scenario: Route a parent reply to a campus inbox Given a parent reply cannot be tied to one room When the reply is received Then the system should route it to the campus inbox And flag it for supervisor review

Scenario: Clear unread reply dashboard item Given an unread parent reply has created a dashboard item When an authorized staff member marks the thread read Then the system should clear the active dashboard item And preserve read history

Story 18#

Title#

Send staff and campus communications

User Story#

As a campus supervisor or district manager I want to send staff and campus communications from the platform So that operational announcements and internal follow-up are part of the same communication record

Acceptance Criteria (Gherkin)#

Feature: Staff and campus communication

Scenario: Send a staff message Given I select a staff audience When I send a staff communication Then the system should resolve staff recipients And create a communication record with sender, recipients, campus, message, and channel

Scenario: Send a campus-wide communication Given I have campus communication permission When I send a campus-wide communication Then the system should route the message to the selected staff or family audience And store the selected campus and audience criteria

Scenario: Review sent communication Given a staff or campus communication has been sent When I open communication history Then the system should show sender, audience, channel, body, delivery state, and attachments

Story 19#

Title#

Manage notification delivery and retries

User Story#

As a system operator I want notification delivery state tracked and retried So that important messages do not disappear when email, SMS, or push delivery fails

Acceptance Criteria (Gherkin)#

Feature: Notification delivery

Scenario: Queue notification delivery Given a workflow creates a parent, staff, health, or compliance notification When the notification is queued Then the system should store recipient, channel, message type, source record, and delivery attempt state

Scenario: Retry failed delivery Given a notification attempt fails When retry policy allows another attempt Then the system should retry delivery And update the attempt history with provider response details

Scenario: Escalate exhausted delivery Given all retry attempts have failed When the delivery job completes Then the system should create a follow-up task for the responsible role And show the failed channel and reason

Story 20#

Title#

Search communication history by child, room, staff, and campus

User Story#

As a supervisor or district manager I want communication history searchable by child, room, staff, and campus So that operational decisions have complete message context

Acceptance Criteria (Gherkin)#

Feature: Communication history

Scenario: Search communication history by child Given a child has communications, emails, health-event notices, and parent replies When I open the child communication history Then the system should show all authorized communication records linked to that child

Scenario: Search communication history by room or campus Given communication records are linked to rooms and campus context When I filter by room or campus Then the system should show matching records with sender, recipients, channel, status, and date

Scenario: Preserve immutable history after lock period Given a communication is older than the configured edit window When a user opens the message Then the system should show it as read-only And preserve its original sender, recipients, body, and delivery audit details

Module: Operational Workforce Scheduling And Attendance Review#

Primary roles: Supervisor, operations user, payroll-adjacent user, system

Purpose: Own operational staff schedules, attendance exceptions, ratio review, and timecard-preparation workflows while leaving new hires, HR profile administration, qualifications, leave administration, and staff reviews to Release 3.

Evidence: Directly evidenced by the current schedule review, attendance reconciliation, ratio reporting, export, and timecard-preparation workflows used by operations teams.

Included stories: Story 21, Story 22, Story 23, Story 24

Story 21#

Title#

Review staff attendance exceptions

User Story#

As a campus supervisor I want to review staff attendance exceptions by date, room, and staff member So that operational attendance records are corrected before timecard preparation

Acceptance Criteria (Gherkin)#

Feature: Staff attendance exception review

Scenario: Show missing check-out records Given staff attendance records exist for a date range When I open attendance exception review Then the system should show records with missing check-out times And group exceptions by staff, room, date, and campus

Scenario: Show overlapping or duplicate attendance records Given a staff member has multiple attendance records for the same time window When I open attendance exception review Then the system should flag overlapping or duplicate attendance intervals And require supervisor resolution before timecard preparation

Scenario: Save supervisor correction notes Given I correct or annotate an attendance exception When I save the review Then the system should store the reviewer, timestamp, reason, previous values, and corrected values

Story 22#

Title#

Review room ratio and time-above-ratio from staff attendance

User Story#

As a supervisor I want room ratio review connected to staff attendance So that staffing risk can be reviewed and corrected from the same operational evidence

Acceptance Criteria (Gherkin)#

Feature: Room ratio review from staff attendance

Scenario: Generate room attendance ratio report Given child attendance and staff attendance records exist for a room and date range When I generate a room attendance ratio report Then the system should calculate room coverage intervals And show any time above the configured ratio threshold

Scenario: Drill into ratio issue details Given a ratio issue is listed When I open the issue Then the system should show room, children present, staff present, timestamps, and source attendance records

Scenario: Record supervisor follow-up Given a ratio issue requires explanation When I add follow-up Then the system should store the supervisor note and mark whether the issue is resolved or still open

Story 23#

Title#

Prepare operational timecard review output

User Story#

As a payroll-adjacent operations user I want a timecard review output generated from approved staff attendance So that payroll preparation has clean operational source data

Acceptance Criteria (Gherkin)#

Feature: Timecard preparation

Scenario: Create payroll-review report Given staff attendance records have been reviewed for a pay period When I start payroll-review report generation Then the system should produce a timecard-preparation output grouped by staff and date And include attendance intervals, rooms, notes, and unresolved exception indicators

Scenario: Block final timecard output with unresolved exceptions Given attendance exceptions remain unresolved for the selected period When I generate final timecard output Then the system should block finalization And list the unresolved exceptions that need supervisor review

Scenario: Export staff attendance for review Given a user has export permission When the user exports staff attendance Then the system should export staff name, room, timestamps, notes, and reviewed status for the selected date range

Story 24#

Title#

Reconcile planned staff assignments with actual attendance

User Story#

As an operations user I want planned staff assignments compared with actual check-in and check-out data So that supervisors can identify coverage gaps before they affect compliance or payroll review

Acceptance Criteria (Gherkin)#

Feature: Staff assignment reconciliation

Scenario: Compare shift assignment to attendance Given planned shift assignments and actual attendance exist for a staff member When the reconciliation job runs Then the system should compare scheduled room, scheduled date, actual room, and actual attendance interval

Scenario: Flag assignment mismatch Given a staff member worked in a different room or outside the planned assignment window When reconciliation completes Then the system should create an operational follow-up item And link the item to the assignment and attendance records

Scenario: Clear resolved assignment mismatch Given a supervisor corrects or approves an assignment mismatch When the reconciliation job runs again Then the system should mark the follow-up item resolved And keep the resolution history available for audit

Module: Compliance Dashboards, Facilities, And Evidence#

Primary roles: Compliance, quality, operations, maintenance coordinator, supervisor, system

Purpose: Provide native compliance queues and evidence capture for health records, plans, checklists, external repair-system links, kitchen temperature exception review, water-flushing exception review, fire drills, and audit follow-up.

Evidence: Directly evidenced by the existing compliance queues for missing signatures, facilities exceptions, water-flushing follow-up, kitchen temperature follow-up, fire drills, and linked repair actions.

Included stories: Story 25, Story 26, Story 27, Story 28, Story 29, Story 30, Story 31

Story 25#

Title#

Complete health-and-safety checklist

User Story#

As an operations or compliance user I want to complete health-and-safety checklists in the platform So that facility compliance evidence is structured and reviewable

Acceptance Criteria (Gherkin)#

Feature: Health-and-safety checklist

Scenario: Start checklist for a campus Given I have checklist permission for a campus When I start a health-and-safety checklist Then the system should create a checklist for that campus with frequency, check date, and checklist items

Scenario: Complete checklist items Given checklist items are available When I mark an item okay or not okay Then the system should store item status, issues, description, user, and timestamp

Scenario: Sign completed checklist Given all required checklist items are completed When I sign the checklist Then the system should store signature method, signer name, completion timestamp, and campus context

Story 26#

Title#

Link checklist issues to the external repair and maintenance system

User Story#

As an operations or compliance user I want checklist issues linked to the stakeholder-maintained repair and maintenance system So that the childcare platform can track compliance context without owning repair-order workflow

Acceptance Criteria (Gherkin)#

Feature: External repair and maintenance integration

Scenario: Send repair follow-up context to external system Given a health-and-safety checklist item requires repair follow-up When I choose to create or link external repair work Then the platform should send or store campus, room or location, checklist item, issue description, priority, and source record context for the external system And the platform should not create a native repair-order lifecycle

Scenario: Store external repair reference Given the external repair and maintenance system returns or provides a work-order reference When the reference is saved Then the platform should store external ID, link, status snapshot, linked checklist item, campus, room or location, and last sync timestamp

Scenario: Surface external repair status in compliance review Given a checklist item is linked to an external repair or maintenance record When a compliance user opens the checklist exception Then the system should show the external status, link, last status update, and responsible follow-up role

Story 27#

Title#

Run compliance dashboard for health and facilities risk

User Story#

As a compliance user I want one dashboard for health, plan, communication, checklist, and facilities exceptions So that risk can be managed across rooms and campuses

Acceptance Criteria (Gherkin)#

Feature: Compliance dashboard

Scenario: Show health and plan exceptions Given incomplete medication authorizations, unsigned plans, incomplete events, or missing parent approvals exist When I open the compliance dashboard Then the system should show each exception with child, room, campus, due date, and responsible role

Scenario: Show facilities exceptions Given incomplete water-flushing logs, inadequate flushing time, missing or out-of-range kitchen temperature records, missing monthly fire drills, externally linked repair follow-up, or incomplete checklists exist When I open the compliance dashboard Then the system should show each exception with campus, room or location, issue type, due date, external repair link when applicable, and follow-up owner

Scenario: Clear dashboard item when source issue is resolved Given a dashboard item is tied to a source health, checklist, facilities, or external repair-link issue When the source issue is completed, corrected, or confirmed resolved in the external system Then the system should clear the active dashboard item And preserve dashboard history for audit

Story 28#

Title#

Monitor kitchen temperature compliance exceptions

User Story#

As a compliance or supervisor user I want missing or out-of-range kitchen temperature evidence surfaced from Release 1 kitchen records So that food-safety follow-up happens without moving daily temperature logging out of Release 1

Acceptance Criteria (Gherkin)#

Feature: Kitchen temperature compliance monitoring

Scenario: Detect missing appliance temperature evidence Given an appliance temperature reading is required for a campus, kitchen log date, and timing window When compliance processing runs And no Release 1 appliance temperature reading exists for that timing window Then the system should create a dashboard item for the missing appliance reading And include campus, log date, appliance item, timing window, and follow-up reason

Scenario: Detect out-of-range food temperatures Given Release 1 food temperature records exist for a kitchen log And a cooked or served temperature is outside the configured food-temperature threshold When compliance processing runs Then the system should create or refresh a food-safety exception And include meal, food-temperature category, expected threshold, actual value, campus, and log date

Scenario: Clear resolved temperature exception Given a temperature dashboard item is tied to a Release 1 kitchen log issue When the source reading is corrected or the exception is acknowledged by an authorized user Then the system should clear the active dashboard item And preserve the dashboard history for compliance audit

Story 29#

Title#

Monitor water-flushing compliance exceptions

User Story#

As a compliance or supervisor user I want missing, incomplete, and inadequate water-flushing logs surfaced from Release 1 kitchen records So that follow-up happens without moving the daily logging workflow out of Release 1

Acceptance Criteria (Gherkin)#

Feature: Water-flushing compliance monitoring

Scenario: Detect a missing required water-flushing log Given a water-flushing log is required for a campus and date When compliance processing runs And no Release 1 water-flushing log exists for that required date Then the system should create a dashboard item for the missing log And include campus, log date, kitchen-room context, and follow-up reason

Scenario: Detect an incomplete water-flushing log Given a Release 1 water-flushing log exists And the log is marked incomplete When compliance processing runs Then the system should create or refresh a dashboard item for the incomplete log And include the incomplete fixture or item context when available

Scenario: Detect inadequate water-flushing time Given a Release 1 water-flushing item requires a five-to-ten-minute flush And the recorded elapsed time is below the required threshold When compliance processing runs Then the system should create a dashboard item for inadequate flush time And include campus, log date, fixture, elapsed time, and required follow-up

Scenario: Clear resolved water-flushing exception Given a water-flushing dashboard item is tied to a Release 1 log issue When the source log is completed or corrected Then the system should clear the active dashboard item And preserve the dashboard history for compliance audit

Story 30#

Title#

Record and monitor campus fire drills

User Story#

As an operations or compliance user I want campus fire drills recorded with attendance and safety-check evidence So that monthly fire-drill compliance is visible and auditable

Acceptance Criteria (Gherkin)#

Feature: Campus fire drills

Scenario: Create a new fire drill from current campus attendance Given a campus is running a fire drill When I create a new fire drill record Then the system should create a fire drill record for the campus And prefill the number of checked-in children and checked-in staff from current attendance

Scenario: Complete fire-drill evidence Given a fire drill record exists When I complete the fire drill Then the system should require drill date, drill time, evacuation time, number of children, number of adults, exit-light check, fire-exit check, device used, and comments when applicable And store the user and timestamp audit context

Scenario: Forward missing monthly fire-drill notice to dashboard Given no complete fire drill exists for the current month When fire-drill notice processing runs Then the system should create a campus dashboard item for the missing monthly fire drill And set the dashboard item expiry to the end of that month

Scenario: Clear completed fire-drill dashboard notice Given a dashboard item exists for a monthly fire drill And a complete fire drill record exists for that month When dashboard cleanup runs Then the system should clear the active fire-drill dashboard item And preserve the fire-drill record for compliance review

Story 31#

Title#

Preserve compliance evidence and audit trail

User Story#

As a quality or compliance user I want compliance evidence records to preserve who did what and when So that audits can be answered from the new platform

Acceptance Criteria (Gherkin)#

Feature: Compliance evidence audit trail

Scenario: Store evidence metadata Given a user completes a checklist, external repair-system link, temperature exception review, water-flushing exception review, fire drill, health event, or plan approval When the record is saved Then the system should store creator, modifier, timestamps, campus, source record, and role context

Scenario: Attach supporting evidence Given a compliance record supports attachments When a user adds evidence Then the system should link the attachment to the source record And preserve filename, uploader, timestamp, and document type

Scenario: Restrict edits after completion Given a compliance record is completed or locked When a user without override permission opens it Then the system should show the record as read-only And require a correction workflow for later changes

Module: Staff Self-Service Identity, Schedule, And Requests#

Primary roles: Staff member, supervisor, HR coordinator, system

Purpose: Allow staff to sign into the app with Auth0, match that identity to imported FileMaker staff state by email, view their own schedule and timecard, submit leave requests, and send supporting documents without pulling full HR administration forward from Release 3.

Evidence: Target-state release requirement based on imported staff identity and workforce context, plus existing document-sharing patterns. Legacy staff-portal history informs the migration context, but the new platform uses Auth0 rather than recreating the old login model.

Included stories: Story 32, Story 33, Story 34, Story 35, Story 36

Story 32#

Title#

Sign into the staff app with Auth0 and match to imported staff state

User Story#

As a staff member I want to sign into the app with Auth0 So that the platform can match me to my imported staff profile and give me the right self-service access

Acceptance Criteria (Gherkin)#

Feature: Staff Auth0 sign-in and identity matching

Scenario: Match a first-time sign-in to an imported staff record Given an active imported staff record exists with a unique email address When I complete Auth0 sign-in with that same email address Then the system should match the Auth0 identity to the imported staff record And create a staff app session with the correct campus, role, and staff context

Scenario: Block unmatched or ambiguous sign-in Given no active imported staff record matches my Auth0 email address Or more than one active imported staff record matches that email address When I complete sign-in Then the system should block staff self-service access And show that account setup requires administrator review And create an access-resolution task for an authorized user

Scenario: Preserve the staff identity link after later imports Given my Auth0 identity is already linked to a staff record When a later FileMaker import updates my staff profile details Then the system should preserve the existing identity link And refresh imported staff profile fields without creating a duplicate account

Story 33#

Title#

View my published work schedule in the app

User Story#

As a staff member I want to view my schedule in the app So that I can see where and when I am expected to work

Acceptance Criteria (Gherkin)#

Feature: Staff schedule self-service

Scenario: View scheduled shifts for a date range Given published shifts exist for me When I open my schedule Then the system should show my shifts by date, time, campus, and room And highlight any room or campus changes across the selected period

Scenario: Show only the signed-in staff member's schedule Given I am signed into the app When I open the schedule screen Then the system should show only my own assignments by default And should not allow me to browse another staff member's schedule without elevated permission

Scenario: Show an empty state when no shifts are published Given no published assignments exist for my selected date range When I open my schedule Then the system should show that no published schedule is available for that period And keep the screen read-only

Story 34#

Title#

View my timecard and attendance summary

User Story#

As a staff member I want to view my timecard and attendance summary So that I can confirm the operational attendance records that will feed payroll review

Acceptance Criteria (Gherkin)#

Feature: Staff timecard self-service

Scenario: View attendance intervals for a pay period Given reviewed or in-progress attendance records exist for me When I open my timecard for a pay period Then the system should show check-in and check-out intervals, rooms, dates, and current review status

Scenario: Show unresolved attendance issues Given one of my attendance records has an unresolved exception When I open my timecard Then the system should show that the entry is pending supervisor review And distinguish pending items from finalized attendance entries

Scenario: Keep timecard self-service read-only Given I am viewing my timecard When I see an incorrect attendance entry Then the system should not let me edit the timecard directly from self-service And should provide a way to flag the issue for supervisor follow-up

Story 35#

Title#

Submit a leave request from the app

User Story#

As a staff member I want to submit a leave request from the app So that my absence request reaches the center or HR workflow without paper or email handoff

Acceptance Criteria (Gherkin)#

Feature: Staff leave request submission

Scenario: Create a leave request Given I am signed into the app as a matched staff member When I submit a leave request with date range, leave type, and reason Then the system should create a pending request linked to my staff record And store the submitted dates, leave type, reason, and submission timestamp

Scenario: Route the leave request for follow-up Given I submit a leave request When the request is saved Then the system should notify the configured supervisor or HR review queue And show the request in their intake view with staff, campus, date range, and submitted reason

Scenario: Show request status to the staff member Given I previously submitted a leave request When I open my leave requests Then the system should show whether each request is pending, approved, declined, or needs follow-up And preserve the original submission details and any returned comments

Story 36#

Title#

Send supporting documents to administration or HR from the app

User Story#

As a staff member I want to send documents from the app So that required forms or supporting evidence can reach administration securely

Acceptance Criteria (Gherkin)#

Feature: Staff document submission

Scenario: Upload a document with metadata Given I am signed into the app as a matched staff member When I upload a document and choose a document type Then the system should store the file in secure attachment storage And save uploader, staff record, document type, filename, and submission timestamp

Scenario: Route the document to the right intake queue Given I upload a document When the submission is saved Then the system should route it to the configured administration or HR intake queue And notify the responsible role with the staff member, document type, and submission context

Scenario: Show document submission history Given I have submitted one or more documents When I open my document history Then the system should show submission date, document type, and current review status And should not expose documents submitted by other staff members

Module: Allergy `IAP` And Allergy/Food Plan Approval#

Primary roles: Health lead, supervisor, parent, staff, compliance, system

Purpose: Maintain enrolled-child allergy and food-risk changes, create and approve allergy IAP plans for strong allergies, route parent approval when allergy-and-food content changes, and capture staff acknowledgment for active allergy plans.

Evidence: Directly evidenced by the legacy enrolled-child allergy maintenance, allergy-plan approval, parent sign-off, and staff acknowledgment workflows.

Included stories: Story 37, Story 38, Story 39, Story 40

Story 37#

Title#

Update enrolled child allergy and food-risk records

User Story#

As a supervisor or compliance user I want to add and update a child's allergy and related food-risk details after enrollment So that the child profile, classroom safety context, and follow-up plan workflow stay current

Acceptance Criteria (Gherkin)#

Feature: Enrolled child allergy and food-risk maintenance

Scenario: Save a mild allergy for an enrolled child Given an enrolled child has a newly identified mild allergy When I save the allergen, severity, symptoms, details, and food-related context Then the system should create or update the child's allergy entry And keep the allergy available to classroom, kitchen, and parent-view contexts

Scenario: Route a strong allergy into draft plan workflow Given an enrolled child allergy is saved with severity Strong (Anaphylaxis) When the change is committed Then the system should create or update the draft allergy workflow records for that child And create or refresh a related draft allergy plan

Scenario: Preserve allergy and food-risk change history Given allergy, food restriction, or feeding-practice data changed for a child When the change is committed Then the system should create a new allergy-and-food approval baseline snapshot And create a child-data-change event with the updating actor, timestamp, and affected child

Story 38#

Title#

Create, review, and approve a child allergy IAP

User Story#

As a health lead or supervisor I want strong allergies managed through a formal allergy IAP workflow So that severe allergy response plans are reviewed, versioned, and current

Acceptance Criteria (Gherkin)#

Feature: Child allergy IAP lifecycle

Scenario: Create a missing allergy IAP draft Given a child has a strong allergy And the child does not already have an active or draft allergy IAP When I open the allergy plan workflow or the missing-plan job runs Then the system should create a draft allergy response plan for that child And place it in the health review queue

Scenario: Approve a draft allergy IAP Given a draft allergy IAP contains the required response details, emergency support instructions, and review dates When I approve the draft Then the system should archive any prior active allergy IAP And promote the draft to the active allergy plan And preserve the approval date and approving user

Scenario: Keep incomplete allergy IAP in draft state Given an allergy IAP draft is missing required content or required signatures When I attempt approval Then the system should block promotion to active And show the missing requirement in the plan review queue

Story 39#

Title#

Request parent signature when allergy or food-plan data changes

User Story#

As a supervisor or compliance user I want parent approval requested when allergy or food-plan content changes So that the signed plan matches the current risk data

Acceptance Criteria (Gherkin)#

Feature: Allergy and food plan parent approval

Scenario: Create a pending approval after allergy or food-plan changes Given a child's allergy, food restriction, or feeding-practice data changes When the change results in a different allergy-and-food data state Then the system should create or refresh a pending parent approval for the updated allergy and food plan And notify the relevant parent or guardian

Scenario: Capture parent signature for the updated allergy and food plan Given a parent opens a pending allergy and food plan approval When the parent signs the plan Then the system should store the parent, timestamp, signature method, and signed plan version And clear the active pending approval for that version

Scenario: Keep unsigned allergy and food plans visible Given an allergy and food plan approval is still outstanding When the supervisor opens pending approvals Then the system should show child, campus, pending-since date, and approval status

Story 40#

Title#

Capture staff acknowledgment of approved child allergy IAP records

User Story#

As a program supervisor I want staff acknowledgments captured for approved allergy IAP records So that the center can prove assigned staff reviewed the child's severe-allergy plan

Acceptance Criteria (Gherkin)#

Feature: Staff acknowledgment of approved allergy IAP

Scenario: Create acknowledgment tasks for assigned staff Given a child allergy IAP becomes active When staff are assigned to the child's room or child context Then the system should create staff acknowledgment tasks for those staff And include child, plan version, staff member, and due status

Scenario: Record staff acknowledgment with secure confirmation Given a staff member has a pending allergy IAP acknowledgment When the staff member signs off with the required secure confirmation Then the system should store staff, approval timestamp, source channel, and plan version And clear the pending task for that staff member

Scenario: Add newly assigned staff to the acknowledgment queue Given an approved child allergy IAP exists And a new staff member is assigned later When acknowledgment maintenance runs Then the system should add a missing acknowledgment task for the newly assigned staff member And preserve the active plan version context

Table And ER References#

Capability	Representative legacy/new-platform tables	Target ownership	ER docs
Child allergy and allergy/food plan workflow	`childAllergy`, `childAllergyDraft`, `childFoodRestriction`, `childFeedingPractice`, `childAllergyIAP`, `childAllergyIAPDraft`, `childAllergyIAPArchive`, `childAllergyIAPStaffApproval`, `childAllergyAndFoodDataState`, `childPendingReportApproval`	`Read-write native` for enrolled-child allergy changes, allergy `IAP` lifecycle, parent approval, and staff acknowledgment	Health, Children, Shared Evidence
Medical plan lifecycle	`childMedicalIMP`, `childMedicalIMPDraft`, `childMedicalIMPArchive`, `childMedicalIMPStaffApproval`, `childSupportISP`, `childSupportISPDraft`, `childSupportISPArchive`, `childSupportISPStaffApproval`, `childMedicalCondition`, `childSpecialNeed`	`Read-write native`	Health, Children
Medication compliance follow-up and audit	Release 1 `childMedAuthorization`, `childMedAdministration`, medication schedule and dosage records, medication exception dashboard records	Release 1 owns authorization and administration entry; Release 2 owns exception review, renewal follow-up, notice audit, and compliance dashboards	Health
Incident, illness, and health follow-up	`childIncident`, `childIllness`, `childPendingReportApproval`, `childIncidentParentNotification`, `childIllnessParentNotification`, `lastNoticeItem`, `dashboardItem`	`Read-write native`	Operations, Health, Communications
Parent, staff, and campus communication	`communication`, `email`, `emailAttachment`, `textMessage`, `mobileMessage`, `mobileAppUserAccount`, `childParent`, `parent`, `staff`	`Read-write native`	Communications, Family, Platform
Operational workforce scheduling and attendance review	`staff`, `staffShiftAssignment`, `staffAttendance`, `staffDailyAttendance`, `timecardDay`, attendance review report data	`Read-write native`	Staff
Staff self-service identity, schedule, leave, and documents	imported `staff` email state, `staffShiftAssignment`, `staffAttendance`, `timecardDay`, target `staffIdentityLink`, `staffLeaveRequest`, `staffDocumentSubmission`, and attachment metadata	`Read-write native` for `Auth0` sign-in, self-service schedule/timecard views, leave request submission, and document submission; Release 3 owns HR administration, balances, and reviews	Staff, Platform, Shared Evidence
Compliance dashboards and tasks	`dashboardItem`, plan/task helper records, notification delivery records	`Read-write native`	Communications, Shared Evidence
Facilities checklists and fire drills	`healthSafetyChecklist`, `healthSafetyChecklistItem`, `fireDrill`, `healthSafetyMeeting`, `healthSafetyMeetingStaff`	`Read-write native`	Facilities
External repair and maintenance links	External repair IDs, work-order URLs, status snapshots, campus/room/checklist context, sync timestamps	External system owns repair and maintenance lifecycle; Release 2 stores links, status snapshots, and compliance references	Facilities, Shared Evidence
Water-flushing compliance monitoring	Release 1 `waterFlushingLog` and `waterFlushingLogItem` records, `dashboardItem` exception records	Release 1 owns log entry; Release 2 owns compliance follow-up	Facilities, Operations
Kitchen temperature compliance monitoring	Release 1 `kitchenLog`, `foodTemperatureItem`, `kitchenApplianceTemperatureItem`, and `kitchenApplianceKitchenLog` records, `dashboardItem` exception records	Release 1 owns log entry; Release 2 owns compliance follow-up	Facilities, Operations

Explicit Release 2 Exclusions#

Excluded workflow	Release target or owner	Reason
Medication authorization and medication administration entry	Release 1	Release 1 owns the operational classroom medication authorization, due-medication, and administration entry workflows.
Repair-order and maintenance work-order lifecycle	External stakeholder-maintained system	Stakeholders already developed another repair and maintenance system; the childcare platform links to it instead of owning repair work orders.
New-hire intake, onboarding, and HR-controlled document administration	Release 3	Candidate onboarding, onboarding document packs, and HR-controlled document maintenance remain Release 3 even though active staff can submit documents in Release 2.
HR staff profile administration	Release 3	Staff master profile, departure fields, personnel records, and HR-controlled staff maintenance are back-office HR workflows.
Staff qualification maintenance	Release 3	`Populate staffQualification` and related qualification inventory scripts are HR maintenance workflows, not Release 2 operational scheduling.
Staff leave balance administration and staff reviews	Release 3	Release 2 covers staff leave-request submission only; leave balances, approval rules, bank maintenance, and review workflows remain with HR/back-office ownership.
Enrollment and family finance	Release 3	Admissions, enrollment, parent accounts, billing, subsidies, EFT, receivables, and finance dashboards are separate Release 3 domains.