Artificial Intelligence Use Disclosure
M-Powered Education Suite — Closed Beta
Summary
This document is a complete accounting of where artificial intelligence is, and is not, involved in the M-Powered Education suite. It is written for review by district administration and does not assume a technical background.
Not in a limited way, not behind the scenes — not at all. The language it produces comes from the goal matrix: a structured analysis of the district's own goal assets, developed by reviewing anonymized IEP goals written across the past five years. Those goals were compared and analyzed down to 68 recurring variants spanning 11 skill areas. When a teacher writes a goal, the tool draws on that matrix and assembles the result inside their own web browser. No outside service is contacted, and no goal information is sent anywhere.
Other tools in the suite do use AI, for purposes unrelated to writing IEP goals. Every one of those uses is listed in Section 4, including what information each request contains and whether that information identifies a student.
How the Goal Builder Works
Where the language comes from. The goal matrix was established by reviewing the district's collected goal assets — anonymized IEP goals written over the past five years. Those goals were compared and analyzed to identify the patterns that recur across them, and organized into a matrix of 68 variants across 11 skill areas:
- Reading — comprehension; fluency and decoding
- Writing — written expression
- Mathematics — mathematical reasoning; algebra and pre-calculus
- Executive function and behavior — executive functioning and self-regulation; social communication; study skills
- Transition — transition and independent living; vocational and career readiness; self-determination
Each variant is also classified by strand — academic, functional, behavioral, or transition — so the matrix reflects how the district's goals are actually distributed, rather than a generic external bank. The matrix is fixed within the application. It does not change on its own, and it does not learn from use.
How a goal is composed. Selecting a skill area and a variant brings its language into the editor with the measurable elements shown as blanks in brackets, such as [number] or [percentage]. The teacher supplies those values from their own professional judgment and their own student data. The tool then synthesizes the parts into the standard condition–behavior–criterion structure:
Given [condition], [student] will [behavior],
with [criterion], as measured by [method].
The synthesis step applies fixed editorial rules — it removes redundant lead-ins such as “the student will be able to,” corrects capitalization, and suppresses a duplicate criterion clause when the selected variant already carries its own measurable standard. These are stated rules, not judgments. There is no model, no prediction, and no invented language: given the same entries, the tool produces the same statement every time, which is what makes the output reviewable.
What AI Does Not Do
Each statement below describes the software as currently deployed.
- × AI does not write IEP goals. Goal language comes from the goal matrix and the teacher's own entries.
- × AI does not decide eligibility, placement, or services. No tool in the suite produces a recommendation on any of these.
- × AI does not select which goals a student receives. The teacher chooses the skill area and the matrix variant.
- × AI does not generate or estimate student data. Where AI drafts narrative text, it is instructed to use only the figures the teacher supplied, and never to invent, round, convert, or extrapolate a score.
- × AI does not write to any student record. Every AI-assisted output is a draft on screen. Nothing is saved until the teacher reviews it and chooses to save.
- × AI does not finalize any IEP. Completed text is entered into the district's IEP system through the district's normal process and remains subject to full ARC review.
- × Student data is not used to train any AI model. Requests are processed and returned. M-Powered stores none of the text sent to the AI service.
- × No AI service is contacted unless a teacher clicks a button that says so. Nothing runs automatically or in the background.
What AI Does Do
The suite uses one AI service: Google Gemini, called from within the district's own Google Workspace environment. Below is every feature that uses it. The label on each entry states whether the request includes anything that identifies a student.
- Purpose
- Synthesizes IEP goal statements from the district goal matrix and the teacher's entries.
- Sent
- Nothing. No outside service is contacted.
- Purpose
- Writes an original short reading passage for progress monitoring, at a requested reading level.
- Sent
- Grade level, target reading level, topic, and vocabulary words. Nothing else.
- Note
- The request contains no reference to any student.
- Purpose
- Drafts a PLAAFP narrative from data the teacher has already entered.
- Sent
- The teacher's typed strengths, area of need, assessment citation, baseline, and data trend.
- Note
- The student's name and identifier are excluded from the request, and the AI is instructed to write about “the student” throughout so no identifier can appear in the result.
- Purpose
- Drafts a progress-reporting narrative from entered data.
- Sent
- Prior goal text, baseline, target, result, instruction used, and next focus area.
- Note
- Same protection as the Present Levels Architect: identifiers are excluded from the request.
- Purpose
- Turns curriculum material the teacher supplies into a scaffolded student handout.
- Sent
- The curriculum text, grade and instructional level, the relevant goal, and any interest context the teacher provides.
- Note
- The handout's name field is left blank unless the teacher types a name into it, and a blank field sends a generic placeholder. Selecting a student does not fill it in. A teacher who wants the student's name printed on the handout can enter it, which does include it in the request — but that is a deliberate action, not the default.
- Purpose
- Reformats an already-generated handout into a Google Form or slide deck.
- Sent
- The handout produced by the SDI Engine. It contains a student name only if the teacher entered one there.
- Purpose
- Reads an existing IEP the district already holds and pre-fills the caseload record, so the teacher does not retype it.
- Sent
- Text extracted from the IEP, including the student's name, disability category, IEP dates, annual goals, and accommodations.
- Note
- This is the one feature that transmits identifying student information, and it does so by design: reading the student's name out of the document is the purpose of the feature. The PDF file itself is never uploaded — it is read inside the teacher's browser, and only the extracted text is sent. That text is processed and returned, not stored, and nothing is written to the student record until the teacher reviews every field and saves.
How Student Information Is Handled
The suite treats these three situations differently, and the distinction is deliberate.
The Probe Generator creates practice reading passages from curriculum parameters alone. The SDI Engine builds handouts from curriculum material and does not include a student's name unless the teacher chooses to type one in.
The Present Levels and Progress Report Architects send the teacher's own written observations and data, with the student's name and identifier excluded from the request. The AI is additionally instructed never to insert a name, initials, or identifier into what it writes back.
The IEP import necessarily handles identifying information, because its job is to read a document that contains it and copy the fields into a record the district already maintains. This is the one place in the suite where student-identifiable text is transmitted to the AI service. It is not retained by M-Powered, and nothing reaches the student record without the teacher's review and save.
Every teacher's access is verified against a district-controlled account list on each request. A teacher can only ever load their own caseload.
Where the Teacher Stays in Control
No AI-assisted feature in the suite produces a finished document. Each one produces a draft in a review pane that the teacher can edit or discard. Nothing is saved to a student record without an explicit save. Nothing reaches an IEP without the teacher entering it through the district's own system, where it remains subject to the full ARC process.
The design assumption throughout is that the certified professional is the decision-maker and the software is a drafting aid. The tools deliberately do not block, override, or auto-approve a teacher's judgment.
Terms Used in This Document
The structured set of goal language underlying the Goal Builder, derived from analysis of the district's own anonymized goals across the past five years and organized into 68 variants across 11 skill areas. It is fixed reference material, not a system that generates or learns.
Composing a statement by applying fixed, stated rules to supplied values. No judgment is exercised and nothing is predicted; the same inputs always produce the same output. This is how the Goal Builder composes a goal.
Software that produces text in response to a written request. Unlike a fixed rule, it composes new wording each time and can produce different results from the same request. Google Gemini is the model used here.
The written instruction sent to the AI, including both the rules it must follow and the data it may use. The prompt determines what information the AI receives — anything not placed in the prompt is not available to it.
The request is answered and discarded. No copy is kept by M-Powered, and the content is not added to any database or used to train the AI.
The work happens on the teacher's own computer, inside the web page itself. Nothing is transmitted over the network.
Technical Description of the Goal Builder
The paragraph below is written for inclusion in correspondence or committee materials.
The Goal Builder does not use artificial intelligence. Its goal language is drawn from the goal matrix — a structured analysis of the district's collected goal assets, established by reviewing anonymized IEP goals written over the past five years, comparing them, and organizing the recurring patterns into 68 variants across 11 skill areas: reading comprehension, reading fluency and decoding, written expression, mathematical reasoning, algebra and pre-calculus, executive functioning, social communication, study skills, transition and independent living, vocational and career readiness, and self-determination. The matrix is stored as fixed reference material within the application; it does not change on its own and does not learn from use. When a teacher selects a skill area and a variant, its language appears in the editor with the measurable elements shown as bracketed blanks, such as [number] or [percentage], which the teacher fills in using their own professional judgment and their own student data. The tool then synthesizes the completed elements into a single statement in the standard condition–behavior–criterion structure: “Given [condition], [student] will [behavior], with [criterion], as measured by [method].” The synthesis applies fixed editorial rules — removing redundant lead-in phrasing, correcting capitalization, and suppressing a duplicate criterion clause where the selected variant already carries a measurable standard — and runs entirely within the teacher's web browser. No language model, no external service, and no third party is involved in producing goal text, and no goal information is transmitted anywhere during this process. Because the rules are fixed, the same entries always produce the same statement. The tool produces a draft only; it does not write to any student record. The teacher reviews the result, edits it as needed, and enters the final goal into the district's IEP system through the district's normal process, where it remains subject to full ARC review.
Other tools in the M-Powered suite do use Google's Gemini AI, but for different purposes: generating practice reading passages from curriculum parameters, drafting instructional handouts, and reading an existing IEP document to pre-fill data-entry fields. Where the suite drafts IEP narrative text, student identifiers are excluded from the request by design and the model is instructed to refer only to “the student.”
How These Statements Were Verified
Every statement about what the software does — which features contact an AI service, what each request contains, and what is excluded from it — was checked against the application source code and the deployed backend script as of August 30, 2026, rather than from recollection or documentation. Each corresponds to an identifiable function in that code and can be demonstrated on request.
The account of how the goal matrix was developed describes the analysis of district goal assets behind it, and is offered as methodology rather than as a claim about software behavior.
Questions about any statement here are welcome, and corrections will be issued if the software changes.