Classroom · Registrars, facilities directors, department chairs · Early access · 2026

The room-and-period grid — no double-booked room, no over-cap roster, no lab course in a room without the equipment it needs

Classroom is the room-and-period allocation engine for a school building. A period grid maps every room to every period with a database-enforced uniqueness constraint: no two sections can ever be assigned to the same room at the same period. An equipment-match layer refuses to seat a chemistry section in a room without a fume hood, or a computer-lab elective in a room without wired stations. An occupancy-cap layer enforces each room’s fire-marshal-posted maximum as a hard constraint against roster size. This is a registrar and facilities tool — where a class physically happens, never who is enrolled in it. Early access — no pricing commitment, no signup, no live booking flow today.

Book a conversation How it works

DB-enforced uniquenessno room can hold two sections at the same period, ever

Equipment matcha fume-hood course cannot be seated in a room without one

Fire-code occupancy capa hard constraint against roster size, not a warning

Room, not rollclassroom.software never decides who is enrolled — only where

The period grid — a room, a period, a hard constraint

Every cell in the grid answers one question: which section, this room, this period

The period grid is rooms down one axis, periods across the other. Each cell holds exactly one section, and a partial-unique index on room, period, and day enforces that at the database — not as a UI validation a registrar could bypass with a bulk import, but as a write the database itself refuses to commit. Two assignments racing for the same room at the same period both get a clean, specific, retryable conflict. Bell-schedule and block-schedule fit is native: a period is a slot in the school’s own calendar shape, whether that’s seven fixed periods a day or a rotating A/B block.

Before an assignment is allowed into a cell, two more checks run: does this room carry the equipment tags this section requires, and does this room’s fire-marshal-posted occupancy cap cover this section’s roster size. Both are hard rejections, not soft warnings. A room posted for twenty-eight cannot take a roster of thirty-four. A course tagged for a kiln cannot land in a room that doesn’t have one.

The period grid, the equipment-match layer, and the occupancy-cap layer are built and production-ready. Shared-space rotation for the gym, the art room, and the auditorium runs on the same assignment engine; its calendar editing surface is in active development.

Book a conversation Full platform

How it works

The facilities year in four stages

Classroom runs on the school year: the period grid is built before the first bell, add/drop rechecks room feasibility as rosters shift, the daily bell schedule answers which section is in which room right now, and room-change requests accumulate a running audit trail. Every stage is described as it is built today.

Step 1 · Before the first bell — the registrar builds the period grid

The registrar lays the room-to-period grid against the bell or block schedule for the year: every room, every period, one section per cell. Rooms are tagged with their equipment (fume hood, gas lines, computer stations, kiln, dark room) and their fire-marshal-posted occupancy cap. Shared spaces — the gym, the art room, the cafeteria, the auditorium — are set up as rotations across the sections that will use them within a block. The uniqueness constraint and the equipment-match and occupancy-cap checks are live from the first cell filled in, not turned on later as an afterthought.

Step 2 · Add/drop season — a roster shift can make a room infeasible

When enrollment changes shift a section’s roster size, the occupancy-cap check re-evaluates the existing room assignment against the room’s fire-marshal maximum, and flags the assignment if the new roster no longer fits. This is a room-feasibility recheck, not an enrollment-eligibility decision — classroom.software never decides who may take a course; it only confirms whether the room that section is currently in can physically hold the roster it now has.

Step 3 · Daily operation — the bell schedule, period by period

Each period, the grid answers which section is in which room, which equipment that room carries, and whether the room is a fixed assignment or part of a shared-space rotation for that block. A substitute checks the coverage view for the room and its attached safety notes. A teacher who needs to move files a room-change request against the live grid rather than a note left in the front office.

Step 4 · Ongoing — room-change requests and the facilities record

Room-change requests accumulate a full audit trail: who asked, why, what the registrar decided, and when the grid changed as a result. The facilities director can pull the room-and-period record for any date to see exactly what was assigned, which equipment-match and occupancy-cap checks passed, and which rotations were active. The record belongs to the school or district and can be exported at any time.

The full platform

Six capabilities — honest about what is built and what is coming

Every capability is labelled honestly: Built means the underlying engine is production-ready. In development means the surface or wire-up is in active build. We do not claim otherwise.

The period grid — one room, one section, every period, enforced at the database

The period grid is the registrar’s working surface: rooms down one axis, periods across the other, a section dropped into each cell. Bell-schedule and block-schedule fit is native — a seven-period bell day and a four-block A/B rotation both resolve against the same grid, because a period here is a slot in the school’s own calendar shape, not a fixed integer. A partial-unique index on room, period, and day enforces the invariant at the database: two sections cannot land in the same room at the same period, ever. It is not a warning a registrar can dismiss and move on from — the write is rejected before it commits, with a clean, specific conflict naming the room and period already taken. The period grid is built and production-ready.

Built · production-ready

Equipment match — a course tagged for a fume hood cannot be seated in a room without one

Rooms are tagged with what they physically hold: fume hood, gas lines, twenty-four wired computer stations, a kiln, a dark room, a piano, a mat floor. A course section carries its own required-equipment tags — chemistry needs the fume hood and gas lines, the computer-science elective needs the wired stations, ceramics needs the kiln. When the assignment engine considers a room for a section, it checks the section’s required tags against the room’s equipment record and hard-rejects any room missing a required tag. This runs at assignment time, not as a post-hoc facilities audit that finds the mismatch after the semester has started. The equipment-match layer is built and production-ready.

Built · production-ready

Occupancy cap — the fire marshal’s posted maximum is a hard constraint, not a suggestion

Every room in the grid carries a maximum-occupancy figure taken from the fire marshal’s posted capacity for that space. When a section is assigned to a room, the engine checks the section’s roster size against that room’s cap and refuses the assignment if the roster would exceed it — the same hard-rejection posture as the period-grid uniqueness constraint, not a soft warning banner a registrar can click past on a busy August afternoon. A room posted for twenty-eight cannot be handed a roster of thirty-four. The occupancy-cap layer is built and production-ready.

Built · production-ready

Shared-space rotation — the gym, the art room, the cafeteria, and the auditorium across one block

Some rooms are not one section’s home for the period — they rotate across several sections within the same block: the gym across four PE sections, the art room across two studio sections, the cafeteria used as an overflow art-history lecture space third period, the auditorium shared between band rehearsal and drama blocking. The assignment engine models this as a rotation schedule inside the same room-period cell rather than forcing a shared space into a single fixed occupant, and the same equipment-match and occupancy-cap constraints apply to every section in the rotation. The rotation-assignment engine is built and production-ready. The calendar view where a facilities director edits a rotation by dragging a section into an open slot is in active development.

Assignment engine built · rotation calendar UI in development

Substitute-teacher room coverage — which room, what equipment, what safety notes, today

When a substitute is covering for a teacher, the coverage view answers one question plainly: which room, this period, today. It carries the room’s equipment and safety notes along with it — a substitute stepping into a chemistry lab sees the fume-hood and gas-line notes attached to that room, not a bare room number with no context. Substitute-teacher room coverage is in active development.

In active development

Room-change requests — a teacher asks, the registrar approves or declines, every request logged

A teacher who needs a different room — a noisy HVAC unit, a broken projector, a schedule conflict discovered after the grid was set — files a room-change request naming the section and the reason. The registrar sees the request against the live period grid, including whether a candidate room passes the equipment-match and occupancy-cap checks before approving it, and every request and decision is logged with who acted and when. Teacher-initiated room-change requests are in active development.

In active development

Who uses it

Built for the registrar, the facilities director, and the department chair — three views, one grid

Registrars

The registrar builds and edits the period grid: assigning sections to rooms, resolving equipment-match and occupancy-cap conflicts before they become a first-day surprise, and reviewing teacher-initiated room-change requests against the live grid. The uniqueness constraint means a registrar never has to manually check whether a room is already taken — the database refuses the conflict outright.

Facilities directors

The facilities director owns the room record: equipment tags, fire-marshal occupancy caps, and shared-space rotations across the gym, the art room, the cafeteria, and the auditorium. When a room’s posted capacity changes after an inspection, updating it here means every future assignment respects the new cap immediately.

Department chairs

A department chair scheduling lab sections sees, at assignment time, exactly which rooms in the building carry the equipment a course needs — fume hood, gas lines, wired computer stations, kiln — instead of learning a room falls short after students are already enrolled.

What this is not

This is not a master schedule. It never decides who is enrolled — only where a class happens.

A master schedule decides which students take which course: enrollment, prerequisite gating, grade-eligibility, conflict-minimized advisory placement. That is a different surface, built and sold under a different product, and classroom.software does not re-describe it or claim it. classroom.software starts one step later: given a section that already exists and meets at a given period, which physical room does it occupy, does that room have the equipment the section needs, and does the room’s occupancy cap cover the roster.

Prerequisite and grade-eligibility gating is out of scope here on purpose — classroom.software never decides who may enroll in a course. classroom.software can optionally read the periods a section meets from a school’s master schedule so the room grid lines up with the calendar already defined there, but that integration is optional, and classroom.software works from its own period and room data on its own.

What is built and what is coming — plainly

The core constraint engine is built. The editing and workflow surfaces are still being wired.

Built and production-ready today: the period grid (room-to-period assignment, DB-enforced uniqueness constraint across room/period/day), the equipment-match layer (hard-reject on a missing required equipment tag), the occupancy-cap layer (fire-marshal maximum enforced as a hard constraint against roster size), and the shared-space rotation assignment engine for the gym, art room, cafeteria, and auditorium.

In active development: the rotation calendar UI for editing a shared-space rotation, substitute-teacher room coverage (the day view with attached safety and equipment notes), and teacher-initiated room-change requests with registrar approval and an audit trail. There is no live paid booking flow on this page, no pricing commitment, and no signup. Registrars and facilities directors deserve to know what is production-ready and what is still being wired.

Works with the rest of the building

Optional companions — never required to use classroom.software

classroom.software works entirely on its own room and period data. Where a school also runs schedule.software, classroom.software can optionally read the period definitions from that master schedule so the room grid lines up with the calendar already defined there — the integration is optional, and schedule.software’s enrollment and eligibility decisions stay entirely on that side of the line. homeroom.software is the school publishing platform, unrelated to room assignment. Neither is required to use classroom.software.

schedule.software homeroom.software

Early access · Registrars, facilities directors, department chairs

Book a conversation to see the current state honestly

Classroom is in active development. We do conversations that show the current state honestly: how the period-grid uniqueness constraint refuses a double-booked room at the database, how the equipment-match layer hard-rejects a room missing a required tag, how the occupancy-cap layer enforces the fire-marshal maximum against roster size, and what’s still in active development — the rotation calendar, substitute coverage, and room-change requests. There is no pricing commitment and no signup. If it looks right for your building, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions from registrars and facilities directors

Is classroom.software the same as our master schedule or student enrollment tool?

No. A master schedule (the kind that decides which students take which course, with prerequisite and grade-eligibility gating) is a different surface entirely, and classroom.software does not build or claim it. classroom.software answers a narrower, physical question: which room hosts which class each period. It reads the periods a course meets and finds the room; it never decides who is enrolled in that course. Who takes a class is out of scope here on purpose.

How does the period grid prevent two classes from being double-booked into the same room?

A partial-unique index on room, period, and day enforces the invariant at the database, not just in the registrar’s UI. If two assignments try to claim the same room at the same period on the same day, the second write is rejected with a specific, retryable conflict naming the room and period already taken. This holds even under concurrent edits by two registrar accounts at once.

What happens if a course needs a fume hood and the room doesn’t have one?

The equipment-match layer hard-rejects the assignment. Rooms carry equipment tags (fume hood, gas lines, wired computer stations, kiln, dark room, and more); a course section carries the tags it requires. The assignment engine checks the section’s required tags against the candidate room’s tags before the assignment is allowed, at assignment time — not discovered by a teacher on the first day of class.

Is the occupancy cap just a warning, or does it actually block an over-cap assignment?

It blocks the assignment. Every room carries a maximum-occupancy figure from the fire marshal’s posted capacity for that space. The engine checks a section’s roster size against that cap before allowing the assignment and refuses it if the roster would exceed the cap. It is a hard constraint the code enforces, not a soft warning a registrar can dismiss.

How does shared-space rotation work for the gym, the art room, or the auditorium?

A shared space is modeled as a rotation across the sections that use it within the same block — four PE sections through the gym, two studio sections through the art room, band and drama through the auditorium. Every section in the rotation still passes the same equipment-match and occupancy-cap checks as a fixed assignment. The rotation-assignment engine is built; the drag-to-edit calendar view for a facilities director is in active development.

Can a substitute teacher see which room they’re covering and what’s in it?

That’s the substitute-coverage view: a day view naming the room for each period a substitute is covering, with the room’s equipment and safety notes attached — so a substitute stepping into a chemistry lab sees the fume-hood and gas-line notes, not a bare room number. This surface is in active development.

How do teacher-initiated room-change requests work?

A teacher files a request naming the section and the reason — a broken projector, an HVAC issue, a conflict found after the grid was set. The registrar reviews it against the live period grid, including whether a candidate room passes equipment-match and occupancy-cap, before approving or declining. Every request and decision is logged with who acted and when. This workflow is in active development.

Does a roster change during add/drop automatically move a class to a different room?

No, it does not move anything automatically. When a section’s roster size changes, the occupancy-cap check re-evaluates the existing room assignment against that room’s fire-marshal maximum and flags it if the roster no longer fits — a feasibility recheck a registrar reviews and acts on, not a silent reassignment.

Who owns the room-and-period data, and is it shared outside the school?

The room grid, the equipment tags, the occupancy caps, the rotation calendar, the substitute-coverage record, and the room-change audit trail all belong to the school or district. None of it is sold to or shared with outside companies.

Does classroom.software require schedule.software or homeroom.software to work?

No. classroom.software is its own product and functions on its own room and period data. It can optionally read period definitions from schedule.software’s master schedule when a school runs both, so the room grid lines up with the bell or block calendar already defined there — but that integration is optional, not a requirement, and classroom.software is never sold, marketed, or gated as a feature of another product.

Is there a live paid booking or checkout flow on this site?

No. There is no live paid booking flow, no pricing commitment, and no signup on this page. The honest next step is a conversation: email [email protected] to book one, and we’ll walk through the period grid, the equipment-match and occupancy-cap constraints, and what’s built today versus in active development.