Privacy & Data Governance Policy
M-Powered Education Suite — Closed Beta
Our Data Philosophy
M-Powered Education exists for one purpose: to give special education teachers better tools without compromising student privacy. Every design decision in this suite starts from a single principle — student data belongs to the student, the family, and the school district, never to us.
We don't collect student data to build a product. We don't sell it. We don't analyze it for our own purposes. We operate no student database: the records a teacher works with live in their own district Google Workspace account, and we hold no copy of them.
We believe the safest data is the data that never travels. Our architecture is built around three commitments: process locally wherever a feature allows it, never place a student's identity into a request that does not require it, and retain nothing on our own systems. Where a feature does require identifying information, we say so plainly rather than describe a protection that does not apply to it.
Scope & Definitions
This policy governs all modules in the M-Powered Education suite, including current and future tools deployed across the mpowerededucation.com domain and its subdomains. It applies to all authenticated users participating in the closed beta program.
The IEP Goal Architect, Present Levels Architect, Progress Report Architect, SDI Scaffold Engine, Probe Generator, Click-Track Data Utility, Caseload Management Portal, and any additional modules deployed under the mpowerededucation.com domain.
Personally Identifiable Information — any data element that can directly or indirectly identify a student, including names, Database IDs, addresses, birth dates, and disability classifications.
Records directly related to a student and maintained by the school or a party acting for the school, as defined by FERPA (34 CFR § 99.3).
Our practice of assembling AI requests so that a student's name and identifier are never placed into them. Enforced at the point the request is built, for every feature that drafts narrative text about a student. See Section 4 for which features this covers and the one that it does not.
How We Protect Your Data
Our protection model isn't an add-on; it's the architecture itself. The M-Powered suite operates on three interlocking safeguards that work together to keep student data under district control at every stage.
How Student Information Is Handled at the AI Boundary
Some features in the suite send content to an AI processing endpoint — Google's Gemini API, called from within the Apps Script backend that runs in Google Workspace. What each of those features sends is determined by how its request is constructed, and the rules differ by feature. This section states those rules exactly, including the one case where student-identifiable text is transmitted on purpose.
An AI model can only use what a request actually contains. Our protection is therefore built at the point the request is assembled: for every feature that drafts narrative text about a student, the student's name and identifier are never placed into the request at all. There is nothing for the model to see, and nothing to remove afterward.
Features that send no student information
The Probe Generator composes practice reading passages from curriculum parameters only — grade level, target reading level, topic, and vocabulary. The SDI Scaffold Engine builds instructional handouts from curriculum material the teacher supplies; its student-name field is left blank unless the teacher deliberately types a name for printing on the handout, and a blank field sends a generic {{student}} placeholder instead. Neither feature references a student otherwise.
Features that draft narrative about a student
The Present Levels Architect and the Progress Report Architect draft IEP narrative from data the teacher has already entered. For both, the request is assembled from the teacher's own typed content — strengths, area of need, assessment citation, baseline, data trend, prior goal, result — and the student's name and identifier are excluded from it. The instruction sent to the model additionally requires it to write about “the student” throughout and never to insert a name, initials, or identifier, so no identifier can re-enter through the output either.
This applies to the Present Levels Architect and the Progress Report Architect. It is enforced in how those requests are built, not left to the teacher to remember, and it is not a setting either the teacher or we can switch off.
The IEP document import — the one exception
The IEP import exists so a teacher does not have to retype a document the district already holds. It reads an existing IEP and pre-fills the caseload record, which means the student's name is not incidental to the request — extracting it is the function. We state this plainly rather than describe a protection that does not apply here.
What is sent: text extracted from the IEP, including the student's name, disability category, IEP dates, annual goals, and accommodations. The extraction is limited to the sections needed for the record; narrative sections such as Present Levels are dropped before transmission.
What is not sent: the PDF file itself. The document is read inside the teacher's browser and never uploaded — only the extracted text is transmitted.
What happens to it: the text is processed and the extracted fields returned. It is not stored by M-Powered, and nothing is written to the student record until the teacher reviews every field and saves.
Features that use no AI at all
The IEP Goal Architect contacts no external service. Goal language is drawn from a fixed goal matrix and assembled inside the teacher's browser; no goal content is transmitted anywhere. This is described in full in our AI Use Disclosure.
Our AI Use Disclosure lists every feature in the suite that contacts an AI service, what each request contains, and whether it includes anything identifying. It is maintained alongside this policy and updated when the software changes.
Zero-Training Commitment
We understand that even de-identified educational content carries sensitivity. A goal statement describes a child's challenges. A curriculum passage was selected for a specific learner. We treat this content with the gravity it deserves.
M-Powered Education uses a single AI processor: Google's Gemini API. Our access is provisioned on a paid service tier, not the free tier. This distinction is the substance of this commitment rather than a billing detail: under Google's paid-tier terms for the Gemini API, prompts and responses submitted through a paid account are not used to improve Google's models. The free tier carries no equivalent commitment. We pay for this tier specifically so that this guarantee applies to every request the suite makes, and we maintain that billing status as a condition of operating the suite.
What this means in practice:
- No training. Goal statements, curriculum passages, SDI scaffolds, IEP text, and any other educational content transmitted through the suite are not used to train, retrain, or fine-tune any AI model.
- No retention by M-Powered. We keep no copy of anything sent to or returned from the AI endpoint. Content is passed through, the response is delivered to your browser, and nothing is written to any system we control. Retention on Google's side is governed by their published terms for the paid tier, which we do not modify and cannot waive on your behalf.
- No aggregation. Your content is not pooled, aggregated, or combined with data from other users or sources for any analytical or commercial purpose.
- No secondary use. Content transmitted through the suite is used for exactly one purpose — generating the educational material you requested — and for nothing else.
If your district's data governance office wishes to review the processor terms directly, they are published by Google as the Gemini API Additional Terms of Service. We will provide our billing tier and project configuration for verification on request.
FERPA & Regulatory Alignment
The Family Educational Rights and Privacy Act (FERPA), 20 U.S.C. § 1232g, is the federal framework governing access to and disclosure of student education records. M-Powered Education is designed to operate within this framework at every level.
Our FERPA alignment rests on three structural facts:
- We are not a "School Official" by default. M-Powered Education does not require or request access to student education records beyond what a teacher chooses to input into the suite during their own session. We do not maintain standing access to any student information system.
- AI requests are built without student identity. For every feature that drafts IEP narrative text, the student's name and identifier are excluded from the request, so the content reaching the AI endpoint carries nothing that identifies a specific student. One feature is a deliberate exception: importing an existing IEP document transmits identifying text, because reading that text is the function of the feature. That import operates on a record the district already holds, is processed and returned rather than retained, and writes nothing until the teacher reviews and saves. Section 4 describes both cases in full.
- No centralized student database. M-Powered Education does not operate a student records database, and does not pool or aggregate records across educators, schools, or districts. Caseload data is held in Google Sheets within Google Workspace, in a separate spreadsheet provisioned for each individual educator, and is used only to operate the suite for that educator. We hold no integration with, and no standing access to, any student information system: the only student data in the suite is what an educator enters or imports during their own session.
If your district requires a formal Data Privacy Agreement (DPA), School Official designation, or FERPA addendum, we welcome and support that process. Please contact us at the address below, and we will work directly with your district's data governance office.
Additional regulatory considerations: Where applicable, M-Powered Education is also designed to be consistent with COPPA (Children's Online Privacy Protection Act) protections and state-level student data privacy statutes. Our approach of holding only the data a feature requires, keeping each educator's records separate rather than pooled, and keeping student identity out of AI requests wherever a feature does not require it, is aligned with the protective intent of these regulations.
What We Collect & Why
Transparency matters. Here is a complete inventory of the information M-Powered Education collects, categorized by purpose.
Educator Authentication Data
- Google account email address — used exclusively for session authentication and access control to the closed beta. Displayed in the UI as your session identifier.
- Session credentials — a short-lived session token is held in your browser and in a session cookie that is cleared when your browser closes. To validate that token between requests, our backend also holds it briefly in Google Apps Script's temporary cache, keyed by a one-way hash and expiring on its own. It is not written to any spreadsheet or database, and signing out clears your session.
Educator-Entered Content (Session-Scoped)
- IEP goal statements — entered or selected by the teacher within a session. Goals composed in the IEP Goal Architect are assembled in your browser and are not transmitted at all. Goals used elsewhere in the suite are processed within the session and never stored on M-Powered servers.
- Curriculum source text — pasted by the teacher for SDI scaffold generation. Processed and discarded within the session.
- Accommodation selections and instructional parameters — configuration choices made within the UI. These are functional inputs, not data collection.
Google Workspace Permissions (Automation Features)
- Automated data-request emails — with the case manager's explicit configuration, M-Powered Education sends scheduled email reminders requesting progress monitoring data from designated recipients, using Gmail's send-only API scope. This scope permits sending mail on the authenticated user's behalf only; it does not allow M-Powered Education to read, search, or otherwise access any content already in the user's Gmail inbox.
- Progress monitoring forms — M-Powered Education creates Google Forms for structured data collection and reads response data back from the forms it created, in order to populate progress monitoring records in that educator's caseload spreadsheet. The suite creates and reads only its own monitoring forms; it does not read, modify, or collect responses from any other form.
What We Do Not Store
The suite necessarily handles student information — a caseload manager that could not show you a student's name would not be usable. That information lives in your own district Google Workspace account. M-Powered Education operates no student data store of its own, and none of the following is ever written to, copied to, or retained on any system we control:
- Student names, addresses, birth dates, or government-issued identifiers
- Disability classifications, medical records, or diagnostic information
- Parent or guardian contact information
- Behavioral records, disciplinary history, or attendance data
- Analytics, telemetry, or usage-tracking data tied to student identity
For performance, your caseload roster is held briefly in your own browser's session memory after you load it, so that moving between screens does not re-fetch it. That copy is cleared when you close the tab and never leaves your device.
Data Storage & Retention
Caseload data is held in Google Sheets within Google Workspace, in a separate spreadsheet for each educator. There is no separate M-Powered database, no data warehouse, and no pooling of records across educators or districts.
- Browser session storage — session state and your caseload roster are held in your browser and cleared on sign-out or tab close. We do not use persistent cookies, and we do not use long-term browser storage for student data.
- Per-educator caseload spreadsheets — Caseload rosters, goals, and progress monitoring data live in a Google Sheets file provisioned for each individual educator. Records are read and written only to operate the suite for that educator, and are not copied into any separate database, aggregated with other educators' records, or used for any other purpose. An educator or district may request deletion of a caseload spreadsheet at any time using the contact address in Section 13.
- AI processing endpoints — Content sent to the AI endpoint is processed in real time to generate the response you requested. M-Powered retains no copy of it. Retention by the AI provider is governed by the terms described in Section 5.
- Automated emails and monitoring forms — Data-request emails are sent through Gmail's send-only scope and are not retained by M-Powered Education. Progress monitoring forms are created by the suite within Google Workspace, and their responses are written into that educator's caseload spreadsheet; M-Powered Education does not maintain a separate copy of form content or responses.
- Server logs — Our backend (Google Apps Script) may generate standard execution logs as part of normal Google Workspace operations. These logs are held within your district's own Google Workspace environment and are subject to Google Workspace's own retention and deletion policies.
Your Data Stewardship Responsibilities
M-Powered Education provides the tools and the safeguards. As the educator, you remain the data steward — the person responsible for how student information is handled within your professional practice. This shared-responsibility model is core to how FERPA works.
We ask that you:
- Follow your district's data governance policies when entering student information into any digital tool, including this suite. If your district requires pre-approval for software that handles student data, please work with your data governance office before using M-Powered Education.
- Use the suite on secure, authorized devices. Because some student data is processed locally in your browser, the security of your endpoint device matters. Use your district-issued or district-approved device and a secure network connection.
- Sign out when you're done. The "Sign Out" button in the suite header revokes your OAuth2 token and clears your session. Use it when you step away from a shared or classroom device.
- Do not share your session. Your authenticated session is tied to your Google account. Do not allow others to use the suite under your credentials.
- Report concerns promptly. If you believe student data has been exposed or that the suite is behaving unexpectedly with respect to privacy, contact us immediately at the address below.
Your Rights
Because M-Powered Education does not maintain a centralized repository of student or educator data, many traditional "data subject rights" provisions (access, correction, deletion of stored data) are structurally satisfied — there is no stored data to access, correct, or delete.
You have the right to:
- Know what is collected — this policy provides a complete and transparent inventory. If you have further questions, we will answer them.
- Revoke access — you may sign out at any time, revoking your OAuth2 session. You may also revoke M-Powered Education's access to your Google account via your Google Account security settings.
- Request information — you may contact us at any time to ask how a specific feature processes data, what is transmitted, and what safeguards apply.
- Opt out — participation in the closed beta is voluntary. You may stop using the suite at any time. No student data will persist on M-Powered systems as a result of your past usage; caseload records you created remain in your own Google Workspace account, under your control, to keep or delete as you choose.
Breach Response Protocol
While our architecture is specifically designed to minimize the surface area for data exposure — primarily because we don't store student PII — we maintain a clear response protocol in the event of any suspected security incident.
- Identification & containment — upon learning of a suspected breach, we will immediately investigate the scope and take all necessary steps to contain exposure.
- Notification — affected educators and, where applicable, district data governance offices will be notified within 72 hours of confirmed incident identification, consistent with applicable state breach notification laws.
- Remediation — we will provide a detailed account of what occurred, what data (if any) was involved, and what steps have been taken to prevent recurrence.
- Regulatory cooperation — we will cooperate fully with any district, state, or federal investigation that may result from a data security incident.
Policy Updates
We may update this policy as the suite evolves, as new modules are added, or as regulatory guidance changes. When we do, the "Effective Date" at the top of this document will be updated, and all authenticated beta participants will be notified of material changes via the email address associated with their Google authentication.
Non-material formatting or clarification changes may be made without individual notification but will always be reflected in the version number and effective date.
Contact
For privacy-related questions, data governance partnership requests, or to report a concern:
M-Powered Education — Privacy & Data Governance
Email: privacy@mpowerededucation.com
Web: mpowerededucation.com
We commit to acknowledging all privacy inquiries within two (2) business days and providing a substantive response within ten (10) business days.