Classroom teacher software · K-12
The classroom software a teacher actually lives in, on one source of truth.
Most teachers run their day across three tools that do not know about each other: a roster in one place, a gradebook in another, and family communications somewhere else entirely. When a student’s name changes, it changes in one. When an assignment posts, it does not automatically appear in the record. When a guardian needs to hear from you, someone has to figure out who is consented. Teach is built the other way: the shared roster, the gradebook, the assignment workflow, and the guardian communication channel all read from the same record — so the class list is never stale, the grade is always attached to the right student, and a message goes only to the right family members. Here is exactly what is built and what is honest-off.
The roster, gradebook, and assignment workflow are built. Family communication dispatch is honest-off: the notify chokepoint is built fail-closed, but the comms provider that delivers messages is not wired. We say so rather than presenting early work as finished.
What is built
The modules below are code that exists and runs today. The ones marked “honest-off” describe where the engine is built but a dependency (a comms provider, an interop API) is not yet wired.
The shared class roster
The class roster is the single source of truth for who is in a teacher’s class. It is the same record the platform’s gradebook, assignment engine, and communication channel all read from — a teacher does not maintain a separate list for each tool. The roster includes the student’s name, enrollment status, section and term, and the consented-guardian relationships that gate every family communication. A student added to the class appears in the gradebook and the communication list automatically. No copy-paste, no import. Shipped
The gradebook
Academic record surfaces run on the same shared roster. A teacher records a score or a mark for an assignment; it attaches to the student’s record on the same spine that backs the class list, the communication channel, and the FERPA privacy wall. The gradebook enforces the single-school boundary: a grade for a student at one school is never visible to another school’s teachers, by any path. Grade history is an append-only audit trail, not an overwrite. Shipped
Assignment and coursework workflow
A teacher builds an assignment with scope, content blocks, and a due date. The assignment attaches to the section and is visible to the students and co-teachers who belong to it. Co-editing is supported: two teachers can work on the same assignment structure. A content workflow step lets an adviser or department lead review draft assignments before they post. When an assignment is scored, the mark flows directly to the gradebook record — no second entry. Shipped
The single-school FERPA privacy wall
A student’s class record, gradebook history, and assignment scores are scoped to exactly one school. A teacher at one school cannot read, query, or enumerate a student record that belongs to another school — not by permission choice, but by a database-layer boundary that the platform enforces on every read path. The wall is not a role-check that an admin can waive; it is a structural constraint. Shipped
The consented-guardian communication channel
The platform records which adults are consented guardians for which students, and which communication channels each guardian has consented to receive. A teacher’s outbound message goes only to the guardians on record for the student, only on the channels they have consented to, and minors in the guardian-contact role are default-denied. The channel is fail-closed: a message to an unconsented contact does not silently succeed, it is refused. The chokepoint is built. The comms provider that delivers the message is honest-off; see below. Shipped — dispatch provider honest-off
Native-first Classroom-parity direction
The roster, gradebook, assignment workflow, and guardian communication channel are built as a native-first integrated set — not bolted together from separate vendor APIs. The platform’s goal is parity with what the major classroom productivity suites offer, then beyond: native persistence, native role model, native consent enforcement, no vendor account required for a student or guardian. Deeper interop APIs (the ability to sync with an external classroom platform) are the secondary layer in the build plan, named honestly below. Shipped set — interop APIs planned
How the pieces fit together
The design principle is one source of truth for the class, not four. The roster is written once — when a student enrolls in a section — and every other surface reads from it. The gradebook reads the roster to know which students belong to which teacher and section. The assignment engine reads the roster to know which sections to post to. The communication channel reads the roster’s guardian-consent relationships to know who may receive a message about which student. A teacher who looks at the gradebook, the assignment list, and the last message thread sees the same class, the same names, and the same enrollment state — because they all read the same record.
The FERPA privacy wall is enforced at the same layer as the roster. The platform’s database schema ensures that a query for “students in my class” returns only the students in the requesting teacher’s school. There is no opt-in to this isolation; it cannot be disabled by configuration. A teacher who is a member of two schools can read records for both — but only through the assignment relationship that ties them to each school individually. Cross-school enumeration is refused at the data layer.
The assignment workflow feeds the gradebook directly. When a teacher scores a submission, the mark is recorded as a gradebook entry against the student and the assignment in a single operation — not as a separate grade import step. A student who submits late, a teacher who scores early, a co-teacher who marks on behalf of the lead — all of these are supported without a workaround. The audit trail records who scored what, when, and what the previous value was, so a grade dispute has a real history to examine.
The guardian communication channel is designed around consent, not convenience. The platform does not assume that every adult associated with a student is a safe recipient. It checks the consent record per-student, per-channel, per-guardian before a message is dispatched. A teacher who sends a message to a class gets confirmation of which guardians received it and which were not sent to (because they lacked consent on that channel) — a real, auditable record, not a best-effort blast. When the comms provider is wired, this is the model it will deliver against.
What is in progress and what is planned
These are not presented as available. They are named so a teacher or administrator considering this platform can see where it is going and what the honest timeline looks like.
Family communication dispatch (comms provider)
The notify chokepoint — the logic that enforces consent, determines the right recipients, refuses unconsented contacts, and default-denies minors — is built and fail-closed. The comms provider that actually delivers the message (email delivery, SMS, or in-app notification) is not wired. When a provider is connected, the dispatch will run against the consent rules already in place. We do not present message delivery as live today. In progress
Guardian communication history and threading
A persistent thread view — a teacher sees the full conversation history with a guardian, not just the last sent message — is in the build plan. The consent and dispatch architecture supports it; the thread surface is being built now. In progress
Section and term management
Full section lifecycle management in the teacher surface: creating a new section for a term, archiving a completed term’s roster, and carrying forward assignment templates to the next term. The data model supports this; the teacher-facing management surface is planned. Planned
Classroom interop APIs (external platform sync)
The native-first set is the primary build. Interop APIs — the ability to pull a class roster from or push assignments to an external classroom platform — are the secondary layer and are planned, not built. The platform is designed to accept this layer; it is not a design debt, it is a deliberate sequencing choice. Planned
Student-facing assignment submission
The assignment engine is built for the teacher side (create, scope, co-edit, post, score). The student-facing submission surface — where a student sees their assignments, submits work, and sees their mark — is planned. The data model accommodates it; the surface is not yet built. Planned
Gradebook export and transcript handoff
A formal gradebook export or a transcript handoff to a student information system is a planned seam. The academic record exists in the platform and is auditable; the structured export format for external consumption is designed but not built. Planned
Who this is for and who it is not for
Teach is scoped to the K-12 classroom teacher: the person who owns a section roster, records grades, posts assignments, and communicates with the families of the students in their care. That is the full audience this platform is built for on this surface.
It is not for non-classroom instructors. A CTE instructor running a shop class, a coach managing an athletic program, a music director running an ensemble, a club adviser running an after-school program, an arts teacher whose work is performance-based rather than assignment-based — those roles have distinct workflows that the classroom model does not cover well. The platform serves those instructors, but at instructor.software, not here.
It is not a staff HR or professional development surface. Credential tracking, observation records, evaluation cycles, and PD hours belong to educator.management. A classroom teacher’s own credential file is an HR concern, not a classroom concern; this surface does not surface it.
It is not a teacher operations surface. Scheduling (which classes you teach), coverage (who covers your class when you are absent), substitute management, and duty/workload assignment are operations-layer concerns. Those belong to teacher.management.
Student data is handled with the same care on this surface as everywhere else. The FERPA privacy wall means a teacher sees only the students in their school. The consent model means a guardian receives only what they have consented to. Minors in the guardian role are default-denied on every communication channel. No student data is used for advertising, shared with data brokers, or exposed outside the school boundary.
Honest answers to common questions
Does the roster update automatically when a student enrolls or transfers?
Yes. The roster is the live enrollment record, not a snapshot a teacher imports. When a student is added to a section, they appear in the gradebook and the communication list. When a student transfers out, they leave the section and are no longer a recipient of class communications. The teacher does not manage this manually.
Does this replace our existing student information system?
No, and we do not claim it does. The platform holds the class roster, gradebook, and assignment record for the tools that run here. A district’s canonical student information system — which may hold transcript history, enrollment history, state reporting data, and state-required fields — is a separate system. The interop seam that would sync enrollment data from a student information system is planned, not built.
Can a teacher send a message to the whole class at once?
The platform is built to dispatch a message to all consented guardians for all students in a section in one step. What it does not do is bypass the consent check to do it: a guardian without consent on the requested channel is not sent to, and the teacher sees which recipients were reached and which were not. The comms provider that delivers the message is not yet wired; message dispatch is honest-off.
Can a co-teacher access the gradebook and assignments for a shared section?
Yes. The assignment and gradebook model supports co-teacher access: a teacher assigned to a section as a co-teacher can read grades, post assignments, and score submissions for that section. The lead teacher retains the section assignment; co-teacher access is granted through the same roster assignment model.
Is student data visible to parents or guardians through this surface?
A parent or guardian portal is not the scope of this surface. The platform holds the consent relationships and the communication channel; a guardian-facing portal where a parent sees their child’s grades or assignments is a planned surface, not a current one. A guardian receives what the teacher sends; they do not have a self-serve login here today.
How does the privacy wall work across schools in the same district?
The single-school boundary is enforced at the database layer. A teacher who is employed at one school and also assigned to a second school as a co-teacher sees each school’s data only through their assignment at that school. Cross-school enumeration — a query that would return students from two schools in one result set — is refused. A district administrator with explicit cross-school access sees both schools through a district-administrator role, not through a teacher’s session.
Related tools and surfaces
Educator Systems
The integrated systems view: roster, gradebook, and communication on one source of truth, not three tools that do not talk.
Instructor Software
For instructors beyond the K-12 classroom: CTE, coaches, arts and theatre directors, and club advisers with their own distinct workflows.
Student Records
The official student record the whole platform reads from: roster, guardians, terms, and the single-school FERPA privacy wall.
Educator Resource Center
A shared shelf of lessons, templates, and classroom tools teachers can pick up and use.
Educator Tips
Short, practical teaching tips from educators who are still in the classroom.
Educator Management Tools
Staff and professional-development management: certification tracking, PD hours, observation records, and evaluation cycles.
What is built and what is honest-off
The shared class roster, the gradebook, the assignment and coursework workflow, the single-school FERPA privacy wall, the consented-guardian communication model (the chokepoint logic, the consent checks, the fail-closed design), and the native-first integrated architecture are built today. The comms provider that delivers messages is not wired: family communication dispatch is honest-off. Guardian communication history and threading are in progress. Section and term management, classroom interop APIs, the student-facing submission surface, and gradebook export are planned. We name these plainly. A school that considers this platform knows what it gets now and what is coming.