AI is optional
Every project is designed with an equal-status AI-off or provider-unavailable route to completion.
Trust architecture · School control · Fail-closed live use
Trust is not a badge. It is a boundary the product must keep.
Responsible AI in schools cannot rest on a student remembering a policy or a teacher watching every chat. Own Mind is designed to make permissions, cognitive custody, evidence limits, safeguarding routes and shutdown conditions part of the product architecture.
Project contract · before student AI is enabledSchool-controlled
- HHuman-only decisions named
- AIPermitted AI role and stopping point named
- OFFEquivalent AI-off route planned
- DSLRestricted safeguarding path separated
The non-negotiables
The educational promise needs enforceable safeguards.
Own Mind is designed around a simple rule: the system must be able to say no to itself before the school has to recover from a bad decision.
The machine gets a job, not the whole problem
AI gets one declared job—a role, a source boundary and a stopping point—or it stays off. It does not make the decision, draw the conclusion or choose what matters.
No automated student judgment
The design excludes system grades, authorship accusations, capability scores, ranks, personality profiles and inferred trajectories.
The work is transparent
The shared record is designed to let assigned teachers and students inspect the same ordinary-work evidence in appropriate views.
Safeguarding is separate
Safeguarding concerns are designed to follow the school’s separate, restricted handoff process. Student AI stays off until that route is built, tested and signed.
Access is first-class
Each task is designed so required home connectivity, public exposure or AI use does not determine whether a student can complete it.
Need-to-know by design
The right adult sees the right thing for the right reason.
This is the intended access model. Student use stays off until the shared student view and restricted safeguarding handoff are built, tested and signed.
| Layer | What it is designed to contain | Who it is designed for | What it excludes by design |
|---|---|---|---|
| Shared work record | Work, decisions, revisions, AI jobs and what they returned | Assigned student and teacher | Duration, engagement, behavioral trend |
| Safeguarding route | A concern flag and its handoff status | Designated Safeguarding Lead or approved deputy | Routine teacher access to transcripts |
| School administration | Identity, roles, AI providers, permissions, retention and incidents | Named school administrators, the Data Protection Officer and relevant IT staff | Automatic access to student work |
| Teacher-written development record | Development notes linked to the work and reviewed by another adult | Student and school-approved staff | Automatically generated traits, scores, ranks or comparisons |
Mapped, inspectable
Every trust statement should point to a control, an owner and a gate.
Do not take the promise on trust. For each safeguard, ask what enforces it, who is responsible and what stops student use if a check expires.
What the system is designed to permit.
The product must enforce who can use AI, what data it keeps, what content it can reach and how the school switches it off.
What the institution must choose.
Providers, roles, project permissions, retention and live-use scope remain explicit school-controlled decisions.
Every required check must be current.
Legal, safeguarding, data, provider and operating checks must be current for the specific AI use and student group.
Governance over generation
Keep the thinking with the student—and the authority with the school.
Inspect the planned safeguards, the evidence ceiling and the school-controlled checks required before students can use AI.