S6 Schools User Manual

S6 Schools is a multi-tenant South African school management and learning platform.

This manual explains how school staff, leaders, parents, learners, and support users should use the platform during a local demo or school pilot.

For a short setup path, start with docs/EASY_START_GUIDE.md.

1. Core Concepts

1.1 Tenant

A tenant is one school. School-owned records must remain inside that school's data boundary.

The platform derives school context from the authenticated user session. Users should not supply or rely on frontend schoolId values.

1.2 Roles

Each user has a role that controls:

• The landing dashboard.
• Which menu items are visible.
• Which routes can be opened.
• Which records can be read or changed.
• Which actions create audit logs.

1.3 Linked Child Scoping

Parents only see learners linked to their guardian account.

Learners only see their own data.

1.4 Teacher Scope

Teachers normally work with assigned classes and subjects. Broader access belongs to school admin, principal, deputy principal, or HOD roles where the permission model allows it.

1.5 Audit Logs

Sensitive writes create audit logs. Examples include:

• Login events.
• Learner, guardian, staff, class, and subject changes.
• Login-detail reissue.
• Attendance submission or locked-entry change.
• Gradebook and report publishing.
• Admissions conversion.
• Payment and invoice changes.
• Privacy exports and sensitive data access.

1.6 Notifications

Major user-facing workflow events create notifications where relevant. Examples include announcements, messages, homework, reports, quizzes, attendance events, intervention assignments, admissions updates, and behaviour events.

2. Getting In

2.1 Local Login

Open:

http://localhost:3000/login

Local demo accounts use:

edupilot123

2.2 Demo Accounts

2.3 Logging Out

Use the visible logout control in the app shell or dashboard. Logging out clears the local session and returns the user to login.

3. Role Menu Structure

3.1 Super Admin

Landing:

• /dashboard/super-admin

Main use:

• Platform health.
• Provider configuration status.
• High-level platform oversight.

School app modules are intentionally restricted for this role in the current frontend.

3.2 School Admin

Landing:

• /dashboard/admin

Can access:

• Overview: /app
• Records: /app/records
• Communications: /app/communications
• Consents: /app/consents
• Bookings: /app/bookings
• Learning: /app/learning
• Resources: /app/resources
• Attendance: /app/attendance
• Gradebook: /app/gradebook
• Reports: /app/reports
• Insights: /app/insights
• Data Quality: /app/data-quality
• Quizzes: /app/quizzes
• Question Bank: /app/question-bank
• Admissions: /app/admissions
• Timetable: /app/timetable
• Behaviour: /app/behaviour
• Finance: /app/finance
• Settings: /app/settings
• South African Readiness: /app/south-africa

Best for:

• Initial school setup.
• Records management.
• User login distribution.
• Data quality cleanup.
• Operational oversight.

3.3 Principal and Deputy Principal

Landing:

• /dashboard/principal

Can access broad school-wide academic and operational views where permitted, including:

• Attendance.
• Resources.
• Question bank.
• SMS campaigns.
• Insights.
• Reports and report governance.
• Timetable.
• Behaviour.
• Finance.
• Data quality.
• SA Readiness.

Best for:

• Whole-school performance monitoring.
• Report approval and publishing.
• Academic risk and intervention oversight.
• Operational governance.

3.4 HOD

Landing:

• /dashboard/hod

Can access:

• Department dashboard.
• Department-scoped records and reports where permitted.
• Learning, resources, question bank, attendance, insights, quizzes, timetable, and behaviour.

Best for:

• Department performance.
• Teacher and class comparison.
• Moderation queue.
• At-risk learner follow-up.

3.5 Teacher

Landing:

• /dashboard/teacher

Can access:

• Communications.
• Consents.
• Bookings.
• Learning.
• Resources.
• Question Bank.
• Attendance.
• Reports.
• Quizzes.
• Timetable.
• Behaviour.
• Own-scope insights.

Best for:

• Daily class workflow.
• Attendance capture.
• Homework and marking.
• Gradebook updates.
• Quiz and resource authoring.
• Parent communication.

3.6 Parent

Landing:

• /dashboard/parent

Can access linked-child data only:

• Communications.
• Consents.
• Bookings.
• Learning and homework.
• Resources.
• Reports.
• Gradebook.
• Timetable.
• Behaviour summaries.
• Finance statements.

Parents cannot submit homework as learners and cannot access unlinked learners.

3.7 Learner

Landing:

• /dashboard/learner

Can access own data only:

• Communications.
• Learning and homework.
• Resources.
• Quizzes.
• Timetable.
• Behaviour summaries where visible.
• Results and feedback.

3.8 Admissions

Landing:

• /app/admissions

Best for:

• Application pipeline work.
• Status updates.
• Document review.
• Accepted-to-learner conversion.

3.9 Finance

Landing:

• /dashboard/admin

Main workspace:

• /app/finance

Best for:

• Fee accounts.
• Invoices.
• Manual payments.
• Statements.
• Debtor aging.

Teachers, learners, HODs, and admissions users do not access finance by default.

3.10 Support

Landing:

• /dashboard/support

Best for:

• Support-safe system health.
• Data quality issue triage.
• Support shortcuts.
• Audit follow-up without broad learner-sensitive access.

4. School Setup Workflow

4.1 Guided School Setup Hub

Route:

• /app/onboarding
• Visual first-school-admin walkthrough: /manual/school-setup

Available to:

• School admin.
• Principal.
• Deputy principal.
• Support in read-only mode where permitted.

Use the School Setup hub when onboarding a new tenant or preparing a school for a pilot.

The hub shows:

• Overall setup percentage.
• Required setup progress.
• Next recommended action.
• Critical blockers.
• Required setup cards.
• Recommended setup cards.
• Evidence from real tenant data.
• Deep links into existing modules.

For a first-time administrator, use the Visual School Setup Guide before working through the hub. The guide follows the recommended order: school profile and calendar, optional curriculum starting point, core records, timetable, login distribution, data quality, then setup completion.

Required readiness checks include:

• School profile and academic defaults.
• Classes and subjects.
• Staff records.
• Learners, guardians, and guardian links.
• Login cards or credential issuing audit.
• Current data quality scan.

When the controlled-beta curriculum feature is enabled for a newly provisioned school, the hub also offers Curriculum foundation. Complete its preview-and-apply flow or choose Blank/custom before creating the manual academic structure. This optional path does not change the required manual setup checks.

Recommended checks include import/export readiness, communications, attendance, report readiness, timetable readiness, and admissions readiness.

Actions:

1. Open /app/onboarding.
2. Work through the required cards from top to bottom.
3. Use each card CTA instead of recreating setup records inside onboarding.
4. Run the data quality scan from the hub.
5. Skip optional cards only when the school does not need them for the current rollout.
6. Mark setup complete after all required checks pass.

Important:

• Onboarding is guided but non-blocking.
• Existing modules remain the source of truth.
• Completion writes audit logs and notifies school leadership users where relevant.

4.2 Super-Admin Tenant Provisioning

Route:

• /dashboard/super-admin

Super admin can:

• View tenant schools and their onboarding status.
• Create a new school with code, slug, province, timezone, academic year, and term.
• Create the first school admin account.
• Generate a one-time printable login card.
• Send the first admin invite by local/SMTP email and SMS provider path when configured.

Safety rules:

• The first admin is created with mustChangePassword=true.
• Temporary credentials are shown/sent once and are not stored as plain text.
• Normal school roles cannot create tenants.
• Tenant creation writes audit logs.

4.3 School Profile

Route:

• /app/settings

Use this first when preparing a school.

Set:

• School name.
• Contact details.
• Address details.
• Branding colours.
• Logo.
• Academic year and term defaults.
• Report defaults.
• School file library.

Recommended sequence:

1. Confirm school identity.
2. Upload logo.
3. Configure report defaults.
4. Add any files used for signatures or report templates.
5. Save and reload to confirm persistence.

4.4 Core Records

Route:

• /app/records

Tabs:

• Learners.
• Guardians.
• Staff.
• Classes.
• Subjects.
• Login cards.
• Imports/exports.

Recommended sequence:

1. Create subjects.
2. Create staff users and assign roles.
3. Create classes and assign class teachers.
4. Create learners and assign classes.
5. Create guardians and link them to learners.
6. Generate login cards or send login details.
7. Run a data quality scan.

4.5 Login Distribution

Use Records > Login Cards.

Supported actions:

• Generate printable learner and guardian cards.
• Issue temporary passwords.
• Reissue staff credentials.
• Send SMS login details through SMSMessenger when configured.
• Send email login details through local dry-run or SMTP provider when configured.

Safety rules:

• Temporary passwords should only be shown or sent once.
• Plain passwords must not be stored.
• Live SMS and SMTP require environment configuration.
• Delivery attempts are logged without exposing secrets.

4.6 Bulk Import and Export

Use Records and South African Readiness workspaces for CSV templates, previews, commits, and exports.

Always preview before commit.

Do not import real school data into a demo database unless the environment is approved for that data.

5. Daily School Operations

5.1 Attendance

Route:

• /app/attendance

Teachers can:

• Create daily, period, or subject attendance sessions for assigned classes.
• Mark learners present, absent, late, excused, or left early.
• Add reason and note.
• Submit a register.

Admin, principal, and deputy can:

• View broader summaries.
• Review absence notes.
• Track absent count, unexplained absences, class attendance percentage, chronic absentee list, and learner history.

Parents can:

• View linked-child attendance summaries.
• Submit absence notes for linked children.

Important:

• Submitted attendance writes audit logs.
• Unexplained absence can create parent notifications.
• Advanced timetable-linked automation remains future work.

5.2 Communications

Route:

• /app/communications

Use for:

• Announcements.
• Conversations.
• Replies.
• Assignment.
• Conversation status.
• SMS campaigns.

Announcement workflow:

1. Draft announcement.
2. Choose audience.
3. Publish.
4. Notifications are created for recipients.

Conversation workflow:

1. Create a conversation with subject, body, participants, and category.
2. Reply in thread.
3. Assign to a staff member if needed.
4. Update status to open, pending, closed, or escalated.

SMS campaign workflow:

1. Create campaign title and message.
2. Choose audience: whole-school guardians, grade guardians, class guardians, staff, or custom CSV where available.
3. Preview recipients.
4. Review skipped/invalid recipients.
5. Send or schedule.

SMS defaults to dry-run unless SMSMessenger credentials are configured.

5.3 Office Hours and Escalation

Communication policy controls:

• Office hours.
• After-hours notice.
• Direct parent-teacher messaging.
• Escalation records.
• Default category assignment.

Use this to keep parent communication school-safe and auditable.

5.4 Notifications

Users can:

• View notifications.
• See unread count.
• Mark notifications read.
• Configure notification preferences.

Preferences include:

• In-app.
• SMS.
• Email.
• WhatsApp placeholder.
• Categories such as announcements, attendance, homework, reports, and messages.

Critical notices may still require school policy decisions and are not a substitute for legal communication procedures.

6. Teaching and Learning

6.1 Homework

Route:

• /app/learning

Teacher workflow:

1. Create homework with class, title, instructions, due date, and max marks.
2. Attach resources or file references where available.
3. Publish homework.
4. Review learner submissions.
5. Add mark, feedback, and feedback attachments.
6. Request resubmission where needed.

Learner workflow:

1. Open assigned homework.
2. Read instructions.
3. Submit response text and file references where available.
4. Review teacher feedback.

Parent workflow:

1. Open homework dashboard.
2. Filter by child.
3. View due today, due this week, overdue, submitted, and marked work.
4. View feedback and marks.

Parents cannot submit as learners.

6.2 Resource Library

Route:

• /app/resources

Teachers and permitted leaders can:

• Create resources.
• Add title, description, type, subject, grade, class, folder, topic, visibility, and status.
• Publish resources to class, grade, school, or staff scopes.
• Generate public resource links for published resources.
• Revoke public links.
• View resource preview metadata.
• View and restore resource versions.
• Submit resources for review or publish/request changes where permitted.

Learners see only published resources in their scope.

Parents see only resources visible to linked children.

6.3 Curriculum Topics

Topics support CAPS-style mapping across:

• Homework.
• Resources.
• Assessments.
• Gradebook entries.
• Quizzes.
• Question bank questions.

Use topics consistently to improve analytics, study paths, and risk indicators.

6.4 Question Bank

Route:

• /app/question-bank

Teachers and permitted leaders can:

• Create reusable questions.
• Add options.
• Mark correct answers.
• Add explanation.
• Set difficulty.
• Set status.
• Link topic and subject.
• Duplicate or archive questions.
• Add bank questions to quizzes.
• Submit questions for review.
• Approve or request changes where permitted.
• View and restore question versions.

Learners cannot access draft or review-only questions.

6.5 Rubrics

Route:

• /app/question-bank

Rubrics support:

• Project marking.
• Essay marking.
• Practical marking.
• Manual feedback.

Teachers can:

• Create rubric title and description.
• Add criteria.
• Add levels and marks.
• Attach rubrics to homework or assessment workflows where supported.
• Mark submissions using rubric assessments.
• Submit rubrics for review.
• View and restore rubric versions.

Parents and learners see rubric feedback only where published through scoped homework/report data.

6.6 Quizzes

Route:

• /app/quizzes

Teacher workflow:

1. Create quiz.
2. Add questions.
3. Reuse question-bank questions.
4. Publish quiz.
5. Review attempts and analytics.

Learner workflow:

1. Start quiz attempt.
2. Save answers.
3. Submit.
4. View score and feedback where available.

Analytics include:

• Average score.
• Completion rate.
• Attempt count.
• Most missed questions.
• Common wrong options.
• Topic performance.
• Learner risk list.

6.7 Study Path

Study recommendations are rule-based.

They may use:

• Quiz attempts.
• Homework status.
• Gradebook marks.
• Attendance.
• Topic performance.
• Upcoming assessments.

Do not present study path results as AI predictions. They are deterministic recommendations based on current records.

7. Reports and Academic Leadership

7.1 Gradebook and Assessments

Route:

• /app/gradebook

Teachers and academic leaders can:

• Select a sticky class, subject, term and academic-year context.
• Save and confirm a versioned report-category policy; included weights must total 100%.
• Capture timetable-aware participation and behaviour/commitment observations.
• Create itemised assessments and record Achieved, Not achieved, Absent or Not assessed for every item.
• Review homework completion and project draft/final milestones.
• Review learner/class insights, explicit missing evidence and mastery bands.
• Write teacher-reviewed developmental comments from curated templates.
• Submit class/subject marks only after policy confirmation and complete assessment evidence.
• Print branded class gradebooks and learner progress reports as PDFs.

Attendance-derived absences and not-assessed results are excluded from relevant denominators. Blank evidence is not treated as a mark. Locked edits require elevated permission and audit logging.

The initial mastery bands are 80–100% Mastered, 60–under 80% Needs Improvement and under 60% Not Yet Achieved. A full illustrated first-setup guide is available at /manual/gradebook and in docs/GRADEBOOK_GUIDE.md.

7.2 Report Cards

Report workflow:

1. Capture assessments and marks.
2. Generate report card.
3. Submit for review.
4. HOD reviews.
5. HOD approves or requests changes.
6. Principal/admin publishes.
7. Parent sees published report only.
8. Export PDF.

PDFs support:

• School branding.
• Header and footer text.
• Configurable sections.
• Attendance section.
• Class average section.
• Teacher comments.
• Principal signature image when configured.

7.3 Report Template Designer

Route:

• /app/reports

Template controls:

• Template name and type.
• Default template flag.
• Primary and secondary colours.
• Header and footer text.
• Attendance visibility.
• Class average visibility.
• Teacher comments visibility.
• Signature visibility.
• Signature image file.
• Section ordering and enable/disable controls.

Full freeform/page-canvas drag-and-drop report design remains future work.

7.4 HOD Dashboard

Route:

• /dashboard/hod

Shows:

• Department subjects.
• Average by subject.
• Weak topic heatmap.
• Teacher and class comparison.
• Moderation queue.
• Report readiness.
• At-risk learners.
• Quiz completion.
• Homework completion.

HODs see assigned departments only.

7.5 Academic Risk and Interventions

Route:

• /app/insights

Use for:

• Risk snapshot generation.
• At-risk learner tables.
• Risk reasons.
• Intervention plans.
• Intervention actions.
• Owner and due-date tracking.

Risk scoring is rule-based. It is not AI-driven.

Parent-facing wording should be supportive and should not expose internal risk reasons unless the school deliberately publishes an intervention summary.

7.6 Data Quality

Route:

• /app/data-quality

Scans can flag:

• Learner missing guardian.
• Guardian missing phone/email.
• Learner missing class.
• Staff missing role.
• Subject without class.
• Duplicate contact data.
• Invalid South African mobile number.
• Admissions accepted but not converted.
• Report missing marks.
• Attendance not captured today.
• File metadata without binary file.

Use fix links to move to the relevant module.

8. Admissions and Parent Engagement

8.1 Admissions Workspace

Route:

• /app/admissions

Admissions users and permitted staff can:

• Create applications.
• Edit applications.
• Update pipeline status.
• Review documents.
• Request resubmission.
• Convert accepted applications to learners.

Pipeline statuses include:

• New.
• Documents missing.
• Review.
• Screening.
• Interview.
• Accepted.
• Waitlisted.
• Rejected.
• Enrolled.
• Declined.

8.2 Public Application Form

Route pattern:

• /apply/:schoolSlug

Public applicants can:

• Enter learner details.
• Enter grade and academic year.
• Enter current school.
• Enter guardian details.
• Confirm declarations.
• Submit application.
• Receive a reference number.

The public route exposes only safe school application configuration.

8.3 Admissions Documents

Document requirements may include:

• Birth certificate.
• Learner ID or passport.
• Guardian ID or passport.
• Proof of residence.
• Latest school report.
• Immunisation card.
• Transfer letter.
• Additional documents.

Staff can:

• Review document checklist.
• Accept document.
• Reject document.
• Request resubmission.
• Add notes.

Current public admissions upload is MVP-depth. Full unauthenticated binary upload and virus scanning are future/provider-gated.

8.4 Consents

Route:

• /app/consents

Consent types:

• Excursion.
• Photo/media.
• Medical.
• Policy.
• Indemnity.
• Other.

Staff workflow:

1. Create consent form.
2. Choose audience.
3. Publish.
4. Review pending, accepted, and declined responses.
5. Export or view certificate where available.

Parent workflow:

1. View pending consents.
2. Select linked child.
3. Accept or decline.
4. Add note where needed.
5. Download certificate where available.

Consent certificates record operational evidence. They are not a claim of advanced legal e-signature certification.

8.5 Parent Evening Bookings

Route:

• /app/bookings

Admin workflow:

1. Create booking event.
2. Create teacher slots.
3. Open event.
4. Monitor bookings.

Teacher workflow:

1. View own schedule.
2. Track booked slots.

Parent workflow:

1. Select linked child.
2. Select teacher and available slot.
3. Book.
4. Cancel where policy allows.

Recurring availability and calendar sync remain future work.

9. Timetable and Behaviour

9.1 Timetable

Route:

• /app/timetable

Admin and school leaders can:

• Create timetable cycles.
• Create periods.
• Create entries with class, subject, teacher, room, period, and effective dates.
• Move existing entries through a grid-based designer.
• Create substitutions.
• Export timetable PDF or CSV.

Conflict checks reject:

• Teacher double-booking.
• Class double-booking.
• Room double-booking.

Teachers see their own timetable.

Parents see linked-child timetables.

Learners see their own timetable.

Automatic scheduling and advanced constraints remain future work.

9.2 Behaviour and Discipline

Route:

• /app/behaviour

Staff can:

• Log behaviour incidents.
• Set severity.
• Add location and occurred time.
• Set parent visibility.
• Add actions.
• Track status.

Actions include:

• Merit.
• Demerit.
• Warning.
• Detention.
• Suspension.
• Parent meeting.
• Counselling.
• Other.

Leaders can:

• Review.
• Escalate.
• Resolve.
• Export hearing pack PDFs where permitted.

Parents see parent-visible incidents for linked children only.

Serious incidents can create notifications for management or parents.

10. Finance and Payments

10.1 Finance Workspace

Route:

• /app/finance

Finance users, school admins, principals, and deputies can:

• View fee accounts.
• Create invoices.
• Add invoice lines.
• Record manual payments.
• Allocate payments to invoices.
• View account statements.
• Export statement PDFs.
• View debtor aging buckets.

Parents can:

• View linked fee accounts only.
• View invoices, payments, balance, and statements.
• Use demo checkout where dummy provider is enabled.

Teachers and learners cannot access finance workflows by default.

10.2 Payment Provider Safety

The default provider is dummy/local.

Live PayFast, Yoco, or Paystack integrations are not enabled in the current MVP. Do not mark payments as live-ready until provider contracts, credentials, and webhook verification are implemented and tested.

10.3 Accounting Boundary

Finance is a school fee visibility and payment-tracking foundation. It is not a full accounting system.

Future accounting depth includes:

• Bank reconciliation.
• Credit-note UX.
• Refund workflows.
• Chargebacks.
• Settlement automation.
• Debtor automation.

11. South African Readiness and POPIA

11.1 South African Readiness

Route:

• /app/south-africa

Supports:

• SA-SAMS-style CSV/XLS mapping.
• Import jobs.
• Preview and commit.
• Export jobs.
• Learner local identifiers.
• Guardian local identifiers.
• School EMIS/localisation fields.
• Academic rule sets.

Important:

This is a CSV/XLS mapping foundation. It is not official SA-SAMS certification and does not claim proprietary/binary SA-SAMS integration.

11.2 Local Identifiers

Learner fields may include:

• SA ID.
• Passport.
• Learner number.
• EMIS/LURITS placeholder.
• Home language.
• Citizenship.
• Province.
• Transport mode.

Guardian fields may include:

• SA ID or passport.
• Relationship.
• Preferred language.
• Communication preference.
• South African mobile number.

Identifier fields are sensitive and should be role-restricted.

11.3 Academic Rules

Academic rule sets support:

• Achievement levels.
• Weightings.
• Promotion placeholders.
• Report display settings.

Schools must confirm official DBE, IEB, or school-specific promotion rules before relying on configured rules for official decisions.

11.4 POPIA Operations

Tools include:

• Privacy notice text.
• Retention policy settings.
• Learner data export.
• Sensitive access log viewer.
• Privacy request register.
• Data incident register.

These tools support operational compliance but are not legal advice.

Schools remain responsible for:

• Lawful basis.
• Retention schedules.
• Incident response.
• Regulator or parent notices.
• Internal policies and staff training.

12. Production and Operations

12.1 Deployment

Use:

• docs/VPS_DEPLOYMENT.md
• docs/DEPLOYMENT.md

Production deployment includes:

• Production Docker Compose.
• Caddy reverse proxy.
• Web container.
• API container.
• Private PostgreSQL.
• Private Redis.
• Health checks.
• Persistent volumes.

Do not expose PostgreSQL or Redis publicly.

12.2 Environment Variables

Use .env.example, .env.production.example, and .env.staging.example.

Never commit:

• JWT secrets.
• Database passwords.
• SMTP credentials.
• SMSMessenger credentials.
• rclone config.
• Payment provider secrets.
• Sentry DSN for private projects unless policy allows it.

12.3 Backups

Use:

• docs/BACKUP_RESTORE.md
• infra/scripts/backup-db.sh
• infra/scripts/restore-db.sh
• infra/scripts/backup-files.sh
• infra/scripts/restore-files.sh
• infra/scripts/restore-drill.sh

Before onboarding a real school:

1. Configure backup destination.
2. Run a database backup.
3. Run a file backup.
4. Run a restore drill.
5. Record evidence.
6. Confirm retention policy.

12.4 Health Checks

Routes:

• /api/health
• /api/health/live
• /api/health/ready

Readiness checks include:

• Database.
• Redis.
• Storage.
• Backup configuration status.
• Observability configured yes/no.
• SMS provider configured yes/no.
• Email provider configured yes/no.
• Payment provider configured yes/no.

Health checks must not expose secrets.

12.5 Smoke Tests

Run:

npm run smoke

Smoke checks:

• API live health.
• API ready health.
• Demo login in non-production.
• Dashboard endpoint.
• Notification count.

13. Security Rules For Operators

Follow these rules:

• Use real secrets outside local development.
• Do not share demo credentials with real school users.
• Do not run demo seed in production unless explicitly allowed for a controlled pilot reset.
• Do not put provider credentials in code.
• Do not import real learner data into a local demo database without approval.
• Do not bypass route permissions by sharing direct URLs.
• Review audit logs after sensitive operations.
• Keep backups encrypted and off-server for production.
• Use HTTPS in staging and production.
• Restrict database and Redis to private Docker networks or private hosts.

14. Recommended Pilot Checklist

Before a school pilot:

• Confirm VPS deployment.
• Confirm HTTPS.
• Confirm production environment validation passes.
• Confirm real JWT_SECRET.
• Confirm database is private.
• Confirm Redis is private.
• Confirm backups run.
• Confirm restore drill succeeds.
• Confirm smoke test passes.
• Confirm SMS is dry-run or live by deliberate choice.
• Confirm email is dry-run or SMTP by deliberate choice.
• Confirm payment provider is dummy unless live gateway is fully implemented.
• Confirm school profile and logo.
• Confirm admin users.
• Confirm role access matrix.
• Confirm parent/learner scoping.
• Confirm data quality scan.
• Confirm report template.
• Confirm attendance workflow.
• Confirm parent communication policy.
• Confirm known limitations are understood.

15. Current Boundaries

The current MVP is broad and pilot-ready for controlled evaluation, but the following remain intentionally limited or future:

• Live WhatsApp delivery provider.
• Broader email campaign and fallback routing beyond login-detail delivery.
• Live payment gateways.
• Full accounting system.
• Automatic timetable generation.
• Full freeform drag-and-drop report designer.
• Rich embedded LMS file viewers and annotation.
• Full moderation queues and visual version diffs.
• Official SA-SAMS certification.
• Legal-grade digital signature certification.
• Native mobile apps.
• Real VPS and restore-drill evidence for each specific school deployment.

For the latest status, read:

• FEATURES.md
• PRODUCT.md
• docs/KNOWN_LIMITATIONS.md
• docs/ROADMAP.md

16. Support Notes

When reporting an issue, include:

• User role.
• Route.
• Browser and device.
• Expected result.
• Actual result.
• Screenshot if available.
• Whether the issue appears on desktop, mobile, or both.
• Whether API health is ready.
• Time of the event.

For security or privacy issues, include as little personal learner data as possible and refer to record IDs where practical.