Language / IdiomaEnglish original · Reviewed Spanish critical content is required before a live pilot.
Independent limited public walkthrough · Fictional scenarios only · District pilot status: HOLD / REMEDIATE · Fictional school examples · No district affiliation
Dedicated IT + security experience

Automate the routine. Govern the exceptions.

A vendor-neutral reference architecture for identity, roster feeds, role-based access, parent consent, secure reminders, retention, auditing, incident response, and automatic offboarding.

Targetno recurring individual enrollment or duplicate roster work
Reference architecture

One account lifecycle. Several authoritative sources.

All integrations shown are simulations. No specific platform is represented as a participating district system without verification.

Identity

District SSO + JIT

Authenticated entry creates the account only when needed.

Relationships

SIS · LMS · HR

Courses, rosters, staff roles, transfers, and status changes.

Authorization

RBAC + consent

Minimum-necessary access, guardian decisions, Support Circle scope.

Experience

Role workspace

Pre-populated dashboard, consolidated digest, exception queue.

Required guardrail

Transfer, role change, consent revocation, Support Circle removal, and offboarding must recalculate access across the app, exports, reminders, and external links—not only the main screen.

Pattern simulator

Compare three implementation approaches.

The recommended hybrid design is a starting point. Each district confirms its authoritative systems, integration contracts, and operational capacity.

Recommended Default

Hybrid recommended

District SSO establishes identity; SIS/LMS supplies students, courses, sections, and enrollment; HR supplies staff role/status; approved guardian and athletics sources add bounded relationships.

Moderateimplementation effort
Lowest duplicate-work riskprimary risk posture
Event + scheduledprovisioning cadence
Field · source · protocol matrix

Define the contract before connecting the system.

Every item below is a future secure-pilot requirement—not an implemented integration or claim about district systems.

Authoritative sourceMinimum fieldsProtocol targetCadenceAcceptance criterion
Identity providerOpaque user key; authentication state; approved groupsOIDC or SAML; JIT after district validationSign-in + lifecycle eventsNo local password; failed/offboarded identity cannot regain access
SIS / LMSCourse, section, enrollment, school, term; minimum necessaryOneRoster 1.2 or approved vendor APIEvent where available + scheduled reconciliationTransfer and withdrawal update every dependent permission and reminder
HR / staff authorityStaff key, status, job/assignment—not broad personnel recordsApproved HR feed or secure mappingDaily + urgent disable pathRole change and separation remove old access within the approved service level
Guardian / consentVerified relationship, consent purpose/scope/version/statusDistrict-approved guardian and e-sign workflowOn decision + revocation eventRevocation blocks sharing, reminders, exports, and future access
Athletics / supportVerified assignment and approved milestones onlyApproved API/file or governed exception queueScheduled + human exceptionNo family finance, contracts, counseling notes, or unrelated records
Required control

Security + privacy

TLS 1.2+ in transit; approved encryption at rest; managed secrets; least privilege; tenant separation; data-flow inventory; no model training on district data; tested deletion and backup handling.

Required control

Logging + detection

Tamper-evident access, export, consent, configuration, AI-draft, human-decision, exception, and admin logs—with role-limited visibility, alerts, retention, and review ownership.

Required control

Incident + recovery

Named severity levels, disable switch, token revocation, job stop, output quarantine, evidence preservation, notice/communications path, rollback, recovery target, and after-action review.

Future 30 / 60 / 90 sequence

Earn technical release in stages.

This sequence cannot begin with real data while the project remains HOLD / REMEDIATE. Dates begin only after written district authorization and named owners.

Days 1–30

Inventory + govern

Confirm systems and owners; map data/purpose; threat model; legal/privacy/accessibility review; architecture decision; acceptance criteria; incident roles; synthetic baseline.

Days 31–60

Configure + test

Build sandbox connectors; test identity and offboarding; validate RBAC/consent; run PII, export, translation, accessibility, load, failover, backup/deletion, and shutdown exercises.

Days 61–90

Shadow + decide

Use only approved bounded data; no autonomous writeback; measure workload and exceptions; rehearse incident response; resolve every Stop; document residual risk and release decision.

Current boundary: design target / not implemented

No connector, SSO, roster, message, storage, telemetry, model call, or district-system write is operating in this public walkthrough.

No-extra-job operating model

What educators should never have to maintain.

The success criterion is no net added burden—not merely a feature checklist.

No duplicate users

Accounts, rosters, assignments, and role changes flow from approved sources.

No parallel updating

Known district data is pre-populated; staff correct exceptions once.

No alert avalanche

Role-relevant items arrive in a prioritized digest with quiet hours and escalation.

No mystery data

Each field shows source, reporting period, evidence type, owner, retention, and use.

No lingering access

Transfer, removal, or offboarding revokes permissions and reminders automatically.

No silent automation

Every consequential action requires the authorized human at the point of decision.

JIT

account creation

Exception-only

manual work

30/60/90

burden review cadence