Close the student-support loop

Seven-minute guided demonstration

This read-only simulation explains the existing workflow; it does not create records, book appointments, or send referrals. Staff still need to verify recommendations and record evidence in the authenticated workspace.

1. 0:00–1:00 Explain synthetic data, consent, and support—not diagnosis.
2. 1:00–2:00 Review intake for Cases A and B.
3. 2:00–3:00 Explain why each service was recommended.
4. 3:00–4:00 Assign owners and confirm consented referrals.
5. 4:00–5:00 Show attendance and follow-up evidence.
6. 5:00–6:00 Record one met goal and one remaining need.
7. 6:00–7:00 Review outcomes, privacy, integrations, and quote gates.

Short demo recording

A 70-second silent, captioned summary of the seven-minute presenter agenda. Synthetic cases and illustrative results only. The agenda above also serves as its text transcript.

Download the short recording (WebM)

Illustrative outcomes and measurement rules

Reporting period: September 1–14, 2026 (UTC). Two synthetic intakes on September 1. First support on September 3 and 5. All listed events and follow-ups fall inside this period.

For empty denominators report “N/A,” not 0% success. Report pending referrals and missing evidence, deduplicate events, and agree cohort rules before comparing periods. These four definitions extend beyond the current workspace's basic counts.

Promotion gate: only publish verified, permissioned, appropriately de-identified institutional evidence, with sample size, period, missing-data caveats, and review approval. Before/after observations do not establish causation. Do not promise grade or retention gains.

Institutional privacy and data-flow supplement

This ASC-specific technical summary supplements the website privacy policy; it is not a signed data-processing agreement, legal advice, or a compliance certification. Institutional privacy staff must approve handling before any real student data is used.

Operational flow and fields

Authenticated browser → same-origin ASC support API → configured persistent store → authorized record views and program summaries. Intake includes student name/identifier, program, goals, responses, optional sensitive barriers, permissions, and a support plan. Staff can add referral service/appointment, intervention date/attendance/usefulness, and follow-up outcomes. Audit events retain actor, role, action, record ID, and time; record-view access is logged.

The persistent-store abstraction defaults to SQLite, with file storage depending on configuration/fallback. IT must document the actual hosting region, durable storage path, backups, transport encryption, at-rest encryption, and access controls; none are certified by this page. This demonstration stores no case data and loads only its static assets, including the recording when requested.

Aggregate export: the workspace export contains metric labels and counts only, applies a minimum group size of five, and omits names, record IDs, and programs. Small-cell suppression does not guarantee anonymity when data can be combined with external information; review exports before sharing.

Current role boundaries—not an institution-specific role matrix

• Admins can access full records; teachers can access records they created or those shared to their named email; tutors can read only named learning handoffs. Students can read their own record using the matching authenticated email. Only admins and teachers can manage cases; other roles are rejected for writes.
• Only admins receive full responses and sensitive-barrier details. Tutor and teacher views contain their authorized learning handoff, not the full intake. Student views omit staff-only recommendation review notes and internal audit data.
• Sharing permissions are record-specific, student-controlled, and revocable for future access. Staff should use a student-approved named handoff and never copy sensitive barriers into a learning note. Do not treat field omission as complete de-identification.
• Explicit user scopes are checked, but default/unscoped compatibility exists. IT must verify isolation with real account configurations and reject inappropriate cross-institution access before launch.

Consent, retention, and deletion

Creation requires support-record consent; evaluation and research modes require separate consent, and sensitive responses are rejected in other modes. Student-facing creation records explicit coordination consent. Students can revoke future named sharing and optional evaluation, research, or referral-coordination use, or delete their record. Explain purposes, recipients, optional fields, withdrawal, and non-diagnostic use.

Records default to one-year retention and expired records are purged when the ASC API is accessed; this is request-triggered expiration, not a scheduled deletion service. Associated audit entries are removed and audit/access logs are limited to one year. Students may delete their own record; admins may delete records. Backup expiry, legal holds, identity verification, and deletion proof are not automated; agree a reviewed institutional process with IT before launch.

Providers and incident handling

The repository targets Render hosting and uses SendGrid for email elsewhere, plus Calendly and Stripe for booking/payment elsewhere on the site. The ASC support endpoint itself does not send messages or synchronize those providers. Confirm actual deployed providers, subprocessors, regions, contracts, and whether any will receive ASC data; do not assume the website's provider list is an approved institutional list.

Designate an institution privacy/incident lead and vendor contact (support@examexperts.org). Before launch agree reporting channels, acknowledgment and notification deadlines, containment/revocation, log preservation, impact review, and recovery tests. Do not email sensitive records to the general inquiry address. Incident SLAs remain subject to written agreement.

Integration capability register

“Existing” describes code paths, not deployment acceptance. External connectors below are proposed work, not available integrations or promises.

Implementation requirements and launch acceptance

Complete this checklist with the institution; it is a readiness checklist, not a claim that configuration or approval has happened. No real student data is needed for acceptance testing.

• □ ASC owner: nominate the accountable lead, referral coordinators, coverage, service capacity, and authorized staff.
• □ IT and privacy contacts: name account/storage/integration owners and a privacy/incident lead; sign data-handling terms.
• □ Service destinations: confirm eligibility, contact/booking route, availability, owner, warm-handoff process, and fallback for unavailable services.
• □ Escalation: agree urgent/safety review and after-hours procedures. This workflow is not an emergency or diagnostic service.
• □ Consent/retention: approve wording and explicit optional choices, sensitive-field handling, withdrawal/deletion, and backup retention.
• □ Outcome definitions: approve goals, due dates, evidence sources, event matching, missing-data rules, and denominators from the metrics section.
• □ Training: practice intake, recommendation review, service mapping, attendance recording, follow-up, and sensitive-context handling.
• □ Accessibility acceptance: test keyboard/focus, screen-reader labels, captions/transcripts, contrast, mobile/reflow, and language needs.
• □ Permissions acceptance: verify each role, student identity boundaries, revoked sessions, sensitive text, and cross-institution rejection.
• □ Data-separation acceptance: demonstrate this static page makes no operational requests or writes; run operational testing in approved nonproduction scope.
• □ Reporting acceptance: reconcile synthetic evidence to all four metrics, test empty denominators and missing follow-up, and confirm operational reports do not silently imply these metrics are already automated.
• □ Commercial acceptance: approve the written scope, fees, support coverage, service targets, exit/data export/deletion, and exclusions.

Launch gate: ASC owner, IT owner, privacy lead, and purchasing owner sign off on evidence of the checks above. Record unresolved gaps and owners; do not launch real-data processing while privacy or isolation gaps remain.

Institutional pricing and support disclosure

Quote required; institutional rates and SLAs are not yet published or approved. No invented dollar amounts, free-access promises, or consumer tutoring prices are presented as institutional fees. Request a written itemized quote before purchase; the following is its required structure, not an offer or contract.

Terms to resolve in writing: contract length and minimum spend, renewal mechanism and notice, cancellation/termination fees, price changes, refund rules, data export/exit assistance and deletion timing, support hours and response targets. All are “to be agreed,” not assumed zero or unlimited.

Scope boundaries: no grade/retention guarantees, campus SSO/LMS/SIS/calendar connectors, emergency response, legal certification, or unlimited tutoring/support are implied by this package. Any contracted additions and third-party costs must be itemized.

Inquiry channel: Request an itemized institutional quote. Published general contact hours elsewhere on the website are not an institutional SLA.