Handbook · the policy handbook system for schools · handbook.software

Nobody disputes what the handbook says today. They dispute which version was in force in March.

Name: Handbook
Brand: Handbook

A school runs four handbooks: staff, student and family, athletics, volunteer. Each one is a policy document that is rewritten every summer, published as a PDF, acknowledged on a paper page in September, and then replaced next August — taking last year’s wording with it. Nothing in that arrangement can answer the only question that ever gets asked: what did the handbook say on the day this happened, and had this family been given it?

Handbook treats a handbook as what it is: a versioned document with sections, effective dates, a provenance for every policy adopted from model language, an adoption state that is a governance decision rather than an upload, and an acknowledgement bound to a specific version so that reissuing the document does not quietly invalidate the record of who read it. Where something is written but has nothing calling it, this page marks it that way in the same typeface as everything else.

Book a conversation Read what is not switched on →

Authoring, versioning, publish gating, policy adoption, and version-bound acknowledgement are live behind a module flag. Annual rollover, distribution, translation, accessibility, and print export are built and have no production caller. Both statements are itemised below.

One handbook, as actually stored

title: Student and Family Handbook
status: published · CHECK draft|published|archived
current_version_no: 4 · CHECK >= 1
version_no 4: published_at set · in force now
version_no 3: published_at set · the row is still here
version_no 2: published_at set
version_no 1: published_at NULL · never published
UNIQUE: (handbook_id, version_no) · no second version 4
section_ref: opaque · no name, no student data
as-of read: not built — the read returns the current version

These are the real column names on the handbook tables, not a mock-up of a nicer product. Version 1 shows the honest part of the model: a version that never passed the publish gate has no publish instant, and there is nothing to display rather than a plausible date. The last line is the honest gap — the history is stored, but resolving which version was in force on a chosen date is not built yet.

Four handbooks, four audiences, four sets of effective dates

These are not four chapters of one document. They bind different people at different times.

Treating them as one file is where the trouble starts. A staff handbook and a volunteer handbook are reviewed on different cycles by different people, and an athletics handbook takes effect when a season starts rather than when the school year does. Each one here is its own versioned document with its own sections, its own publish state, and its own acknowledgement roster.

Staff handbookEvery employeeConduct, leave, mandated reporting, technology use, evaluation timelines. The one an employment dispute reaches for, which is why the version and the acknowledgement date matter more than the wording.
Student and family handbookEvery householdAttendance, discipline, dress, devices, transportation. Reissued every August, acknowledged by every family in the first two weeks of September, and the highest-volume acknowledgement event in the school year.
Athletics handbookAthletes and their guardiansEligibility, participation rules, travel, concussion protocol. Different audience, different effective dates, its own acknowledgement roster — not an appendix to the family handbook.
Volunteer handbookVolunteers and chaperonesBackground-check expectations, supervision rules, boundaries with students. The handbook most often missing entirely, and the one an incident review asks for first.

The audience-scoping policy that decides which handbook reaches which group is written and tested, and it has no production caller yet — see the school-year section below, where it is marked plainly rather than folded into this list.

Every card names the file its claim was read out of

Authoring a handbook, and keeping every version you published.

This is the spine of the product and the part that is running. A handbook is a versioned document; a version is an immutable row; a blank section blocks the publish; an adopted policy keeps the provenance of the model text it came from. The path printed at the bottom of each card is where the claim was read from, so a reader who wants to check us has somewhere to start rather than a sentence to take on faith.

The document model

Live · registered route

A handbook is a versioned document, and every edit makes a new version

Sections carry a heading, a body reference, and an order index. Reordering is a stable sort, so two sections given the same position keep the order the editor put them in rather than shuffling between page loads. The table of contents is derived from the ordered sections every time, so it cannot drift from the handbook it describes. And an edit does not overwrite: it mints the next version number and leaves the previous one standing.

packages/shared/src/handbook-builder.ts

The version wall

Live · UNIQUE + nullable publish instant

One immutable row per version, enforced by a unique constraint

Each version snapshot is a row keyed on the handbook and the version number, with a database UNIQUE constraint across that pair. Version four cannot be written twice, and it cannot be quietly replaced by a different version four. The publish instant is a separate nullable column that stays NULL until the handbook actually passes the publish gate — a draft is never displayed as though it were published, because there is no value there to display.

packages/db/prisma/migrations/0567_handbook_suite/migration.sql

The publish gate

Live · fail-closed, refusal named

A handbook with one blank section cannot be published at all

The gate is fail-closed and names its refusal: an empty handbook is blocked as empty, and a handbook carrying any section without both a heading and a body is blocked as incomplete, with the offending sections listed in order. There is no override and no partial publish. The reason this is a gate and not a warning is that a blank section in a published handbook is indistinguishable, later, from a policy that was deliberately removed.

packages/shared/src/handbook-builder.ts

Provenance

Live · source version captured at adoption

An adopted policy remembers which version of the model text it came from

A school starts from a shelf of pre-written policy sections and adopts the ones it wants. The adoption records the source version at the moment of adoption, so the school always knows which edition of the official text it started from. Adopting something that is not on the shelf is refused outright rather than recorded with an invented provenance — a fabricated lineage is worse than no lineage, because it reads as verified.

packages/shared/src/handbook-templates-policy-library.ts

Customisation

Live · divergence marked, staleness flagged

The moment a school edits an adopted policy, it stops being the model text

The adoption row keeps two body references: the model text it came from and the text the school currently shows. When those diverge the policy is marked customised, and the product says so plainly instead of continuing to present the school’s edit as the official template. A stale-adoption check separately flags policies whose model text has since moved on. Both matter because a handbook is quasi-legal, and presenting an edited policy as unmodified model language misrepresents what a family agreed to.

packages/shared/src/handbook-templates-policy-library.ts

Tenancy and PII

Live · RLS forced, opaque refs only

Handbook rows are policy configuration, not student records

Sections hold an opaque section reference and an opaque body reference. No name, no photograph, and no free text about a person lives in a handbook row, which is what makes the authoring surface census-neutral. Row-level security is ENABLEd and FORCEd on every table in the suite with a tenant isolation policy, so one district cannot read another’s policy manual even if the application layer asks it to.

packages/db/prisma/migrations/0567_handbook_suite/migration.sql

Who may edit

Live · closed allowlist, module-dark

Authoring is the governance-officer tier; a photography rep is hard-denied

Creating a handbook, cutting a version, publishing, and adopting a policy are restricted to the school and district administrator tier. Teachers reach the read and self-acknowledgement lane and no further. A photography rep is denied by a closed allowlist behind a throwing refusal, not by a hidden menu item. The whole surface is dark until a school turns the module on, so a school that has not adopted it is byte-identical to one that never heard of it.

apps/api/src/routes/handbook.ts

All of it sits behind a module flag, so a school that has not turned the handbook module on is byte-identical to a school that never heard of it. That is deliberate: a governance surface that appears half-configured is worse than one that is absent.

The honest section — five engines nobody can reach yet

The school year: written, tested, and not wired to anything.

Each of the five below is a real engine with real tests and no production caller. Not a roadmap item and not a mock-up: the law is written and the shape is decided, and there is no route that invokes it, which means no school can use it today. They are on this page because leaving them off would misrepresent what the product is, and describing them as available would misrepresent what it does. A route away is a real difference from a rewrite away. It is still not working.

August

Built, not wired · zero callers

Rolling a handbook into a new year cannot silently carry a stale policy forward

The rollover clones last year’s handbook into the new school year, starts it unpublished, and keeps every annual-review section flagged. The publish gate then refuses until each flagged section has actually been reviewed in the new year. The failure this prevents is the common one: a handbook reissued in August with a policy nobody reread, now carrying this year’s date and last year’s rule. This engine is written and tested. No route calls it yet, so no school can use it today.

packages/shared/src/handbook-annual-rollover.ts

Distribution

Built, not wired · zero callers, send honest-off

Audience-scoped distribution that refuses an address not on the roster

The audience policy separates families, staff, and students, and a recipient is deliverable only when the school’s own roster confirms membership. An unpublished handbook is never sent, an empty audience sends nothing, and an absent channel sends nothing; off-roster attempts are reported rather than dropped. The delivery channel itself is an injected seam and is honest-off. This engine has no production caller: the audience law exists, the sending does not, and there is no stored record of who received which version.

packages/shared/src/handbook-digital-distribute.ts

Languages

Built, not wired · zero callers, no engine attached

A language is offered only when every required section is translated

A partially translated handbook is worse than an untranslated one, because the missing part is invisible: a family reads to the end and never learns a section was withheld. So a language appears on the menu only when the translation is complete, and the untranslated sections are listed deterministically so the gap is a work queue rather than a mystery. The translation engine is injected and reports honestly that no engine is attached — there is no machine translation here and no model of any kind. No route calls this yet.

packages/shared/src/handbook-translation-accessible.ts

Accessibility

Built, not wired · zero callers

Three accessibility checks, and any one failing blocks the handbook

Alternative text complete, reading order set, contrast passing. The gate is fail-closed and every failing check is named, so an inaccessible handbook does not reach a family with the problem hidden in a validation summary nobody read. This is a genuinely modest surface — three checks, not an audit — and no conformance level is claimed anywhere. It has no production caller either.

packages/shared/src/handbook-translation-accessible.ts

Built, not wired · zero callers, renderer honest-off

Print-readiness includes the detail everybody discovers on page 41

Page size set, fonts embedded, margins inside the safe area, and an even page count so a double-sided run does not end on a stray blank. Every check must pass; a file that fails one is refused rather than handed over labelled print-ready. The export fails closed twice over, once on readiness and again when no renderer is wired. No renderer is wired, and no route calls it either, so no school can export a handbook from this today.

packages/shared/src/handbook-print-ready-free.ts

When one of these is wired, its card changes from built-not-wired to live and names the route. Until then the useful thing we can tell you is which of the five you would need first, because that is the conversation that decides the order.

Not a percentage — a defensible record

Acknowledgement is tied to a version. Reissue the handbook and the record knows.

Every school already collects acknowledgements. Almost none of them can say, two years later, which version a particular person acknowledged, because the paper page said only that they had read the handbook. Binding the acknowledgement to a version number is a small change that turns a compliance ritual into a record. And it is where the electronic signature belongs — one mechanism inside one step, which is exactly what the last card says.

The record

Live · bound to a version number

An acknowledgement is bound to one version, and version four does not inherit version three

Reading v3 is not reading v4. The check is fail-closed on the current version, so reissuing a handbook makes every prior acknowledgement stale by construction rather than by an administrator remembering to reset something. That is the whole point: not a percentage, but a defensible statement that this person acknowledged this exact version on this date.

packages/shared/src/handbook-acknowledgement-sign.ts

September

Live · computed from persisted rows

The chase list: who still owes the current version, as a list rather than a percentage

The pending list is computed from the persisted acknowledgements against the current version, so it shrinks as people acknowledge and repopulates the moment a new version is published. A completion rate is available too, but the list is the useful artefact — a front office can act on twelve outstanding staff members and cannot act on ninety-four per cent.

apps/api/src/routes/handbook.ts

Minors

Live · student self-ack refused

A student cannot acknowledge on their own behalf

A student self-acknowledgement is refused. A minor’s handbook acknowledgement runs the parent path, which is the only shape in which it means anything. The staff-facing surface is an adult-staff-only closed allowlist behind a throwing refusal, and the acknowledgement record sits behind row-level security with a restrictive wall that shows a photography rep zero rows. No handbook acknowledgement is ever public.

apps/api/src/routes/handbook.ts

One mechanism, not the product

Held · seal and consumer resolver unset

Electronic signature is how an acknowledgement is captured, and it is held off today

An acknowledgement can be captured through the platform’s existing evidence engine rather than a second one built here — the same engine and the same two ledgers the rest of the platform uses, with no duplicate evidence table anywhere. That engine records intent, consent, attribution, and the association to the exact bytes, and identity and timestamp are resolved by the server rather than accepted from the request. Two things are held off, and both matter here. No cryptographic seal provider is configured, so every capture is recorded honestly as unsealed and none can reach a sealed state; the dedicated finalisation endpoint answers with a refusal saying exactly that. And the consumer consent resolver is unset, so a parent or student capture is refused. Today the durable, usable acknowledgement is the clickwrap record: the person confirms, and the confirmation is stored against the version. That is a mechanism inside one step of this product. It is not what this product is.

apps/api/src/routes/handbook.ts

The acknowledgement record reuses the platform’s existing ledgers rather than adding a second evidence table, which is why the last card can be specific about what is held off instead of vague about what is on.

Already built. We checked before we wrote a line of it.

A policy is adopted, not merely published — and that engine was already in the platform.

Adoption is the difference between a document and a policy: a state, a date, a motion, a quorum, a roll call, and an immutable adopted text. It would have been reasonable to assume a handbook product needed to build that. It did not. The adoption lifecycle, the vote tally, the model-policy shelf with its immutable editions, and the public open-meeting read are existing registered surfaces with their own migrations, and the handbook product uses them rather than growing a second lineage beside them.

Adoption

Live · closed transition table

A policy is adopted, not merely published, and the transition table is closed

Draft, adopted, superseded, archived — and a closed table of which action may move which state. An unknown action is refused rather than defaulted, and the role permitted to act on the lifecycle is checked separately from the transition itself. Publishing is a website event. Adoption is a governance event, with a date, an actor, and an immutable adopted text, and the difference is the whole distinction between a document and a policy.

packages/shared/src/sch-board-governance.ts

The vote

Live · quorum, roll call, review cycle

The motion that adopted it, with a quorum check and a named roll call

A tally is validated before it is counted, and the result against quorum is passed, failed, or tabled — tabled being the one most systems lose, and the one that matters when somebody asks whether a policy was actually adopted at that meeting. Motions attach to the meeting record, and a review-due calculation surfaces the policies whose cycle has come round again.

packages/shared/src/sch-board-governance.ts

The shelf

Live · single adoption path

A maintained model-policy shelf with immutable editions, adopted through one path

Model policies carry a structured code number, unique per school, and each publication is an immutable edition in a sequence. Adopting an edition into a school’s own manual builds the draft version through the same routine the manual already uses, so there is exactly one code path that creates a policy version and no second lineage to reconcile. The source association is an opaque generic identifier, never a brand name.

apps/api/src/routes/model-policy-library.ts

The public record

Held · live route, empty until adoption flips

An unauthenticated public read that returns adopted records and nothing else

Open-meeting law makes adopted board records public, so this lane has no login at all — and default-deny is the wall: it returns only rows explicitly marked adopted. A draft, an unadopted, or a tabled record is never returned, internal identifiers are stripped from the response, and no student data appears. Read this part carefully: no route currently flips a record into the adopted state, so this portal honestly returns an empty record for every school today. The build ships; the flip is held.

apps/api/src/routes/public-board-portal.ts

The website copy

Live · internal by default, current only

Public documents default to internal, and a superseded version never serves

Each upload against a logical document is a new immutable version and the newest is current. Visibility defaults to internal; only an explicit public setting by an authorised administrator makes a document eligible for the public website, and the public resolver serves public and current only. A superseded handbook cannot be reached from the public lane by guessing a path.

apps/api/src/routes/document-repository.ts

One card in this group is held rather than live, and it is the public portal: no route currently moves a record into the adopted state, so the portal returns an empty record for every school today. The build ships and the flip is held, and those are different sentences.

Compete means beat, and the opponent is not who you would guess

The real incumbent is a PDF on the district website, and it is free.

Most districts are not choosing between handbook products. They are doing this in a word processor and posting the result, and that arrangement has genuine advantages: it costs nothing, everybody already knows how to use it, and it never breaks. Any honest comparison has to be against that, not against a vendor demo. So the left column below is the PDF. Every row is a question the PDF cannot answer, and the right column says plainly where our own answer stops.

How a handbook posted as a PDF and Handbook differ, by question asked
The question	A PDF on the district website	Handbook
Which version was in force in March	The file was replaced in August. The March file is gone, or it is on somebody’s desktop with a name ending in final-v3-use-this. The question cannot be answered from the system.	Every version is its own immutable row, keyed uniquely on the handbook and the version number, carrying the instant it was published. The record is kept rather than overwritten. Note the honest limit: that history is stored, but the read surface returns the current version, and a point-in-time lookup is not built yet.
Whether a section is blank	A heading with nothing under it publishes exactly as happily as a complete policy, and nobody notices until somebody needs that policy.	The publish gate refuses the whole handbook and lists the incomplete sections by reference. There is no override.
Where a policy came from	Somebody pasted it from a model policy years ago and edited it later. Which model, which edition, and what was changed are not recorded anywhere.	The adoption stores the model edition it came from, and a divergence between the school’s text and the model text marks the policy customised. Adopting something not on the shelf is refused rather than given an invented lineage.
Adopted or just uploaded	A PDF on a website has no state. There is nothing in the file that distinguishes board-adopted policy from a draft an administrator posted on a Tuesday.	Adoption is a lifecycle state with a closed transition table, a motion, a quorum check, and a named roll call. The public lane returns adopted records only.
Who acknowledged which version	A signature page, printed, returned by some families, filed in a drawer, and counted by hand. Reissue the handbook and the count silently means nothing.	The acknowledgement is bound to a version number and is fail-closed against the current one. Publishing a new version makes every prior acknowledgement stale by construction, and the outstanding list rebuilds itself.
Whether the record can be edited	It is a file on a server. Anyone with access can replace it, and nothing in the artefact would show that it happened.	The acknowledgement record lands in an append-only ledger whose triggers raise on UPDATE and on DELETE for every role, behind forced row-level security. A permission cannot be granted around a trigger.
Four handbooks, four audiences	Four PDFs, four link locations, four effective dates nobody tracks, and one of them is a year out of date. Usually the volunteer one.	Each handbook is its own versioned document with its own sections, its own publish state, and its own acknowledgement roster. The audience-scoping policy that decides who receives which one is written and tested but has no caller yet, and this page says so on its card.
Translation	One language, or a translated PDF from three versions ago that a family cannot tell is out of date.	A language is offered only when every required section is translated, and the missing sections are listed. Also unwired today, and marked as such. No machine translation and no model.
What it costs	Nothing, which is exactly why it is the incumbent, and why a comparison that ignores it is dishonest.	The core is free to the school as well. Not free-for-a-year: no per-seat licence and no per-student fee, and there is no checkout on this page.

One factual note on the category, named once and then not again. The established products here are BoardDocs, Simbli from eBOARDsolutions, PolicyQuest and the NEOLA model-policy service, and Frontline Central on the staff-acknowledgement side. They are named because a comparison that will not say what it is comparing against is not a comparison, and because most of them are genuinely good at the board-governance problem they were built for. Neither their code nor their copy is used anywhere in ours, and nothing here asserts anything about their current features or pricing. But the column on the left is not describing any of them. It is describing the actual incumbent in most buildings — a PDF on the district website, replaced each August — because that is what this product has to beat first, and it is a harder opponent than a vendor: it is free, it already works, and nobody has to be trained on it.

The section most product pages do not have

What is running, what has no caller, what is held, and what we do not do.

If you only read one section, read this one. Four states, kept separate on purpose: running means a registered route reaches it; built-not-wired means the engine exists and nothing calls it; held means something calls it and a deployment value withholds the enablement; and the last column is work we have decided against.

Running today

Handbook authoring: ordered sections, derived table of contents, opaque body references
Immutable version snapshots, unique per handbook and version number
The fail-closed publish gate, refusing an empty handbook or any blank section by name
Model-policy adoption with the source edition recorded, and customisation and staleness marked
Acknowledgement bound to a specific handbook version, plus the outstanding-list chase
The board adoption lifecycle, motion and quorum tally, and review-due calculation
The maintained model-policy shelf with immutable editions
Public document versioning with internal-by-default visibility
Forced row-level security and tenant isolation on every handbook table
The administrator-tier authoring wall, the teacher read lane, and the student self-acknowledgement refusal

Built, and nothing calls it

Annual rollover. Clones into the new year unpublished with every annual-review section flagged, and refuses to publish until each is reviewed. No route calls it.
Audience-scoped distribution. Roster-only recipients, published-only sends, off-roster attempts reported. No route calls it, the send channel is honest-off, and there is no stored record of who received which version.
Translation completeness. A language is offered only when every required section is translated. No route calls it, and no translation engine is attached.
The accessibility gate. Alternative text, reading order, contrast; any failure blocks. No route calls it.
Print export. Page size, embedded fonts, safe margins, even page count for duplex. No route calls it and no renderer is wired.

Built, called, and held off

Sealed acknowledgement capture. No seal provider is configured, so every capture is recorded honestly as unsealed and none can reach a sealed state. The finalisation endpoint refuses with that reason rather than pretending.
Parent and student acknowledgement capture. The consumer consent resolver is unset, so the capture is refused. Only institutional acknowledgement runs today.
The public adopted-record portal. The route is live and correct and returns an empty record for every school, because no route yet moves a record into the adopted state.

Not done here at all

A point-in-time version lookup. The immutable version rows and their publish instants are stored; the read that resolves an as-of date is not built. We would rather say that than imply the question is already answered.
Policy search with deep links. Not built. Not claimed.
Reading-level variants. There is a language axis and there is no reading-level axis. Not claimed.
Generative anything. No model drafts, summarises, or translates a policy. A plausible paraphrase of a discipline policy is a liability.
Money. Nothing here takes a payment and there is no checkout on this page.
Adoption claims. No customer count, no volume figure, no testimonial, because none would be real.
Certification and legal advice. No SOC 2, FERPA, COPPA, or VPAT claim, no accessibility conformance level, and nothing here is counsel.

What it costs

Free to the school, because the incumbent is free.

A handbook is not an optional purchase a school makes to be more efficient. It is a document a school is obliged to publish and obliged to be able to account for. Charging per handbook, per seat, or per acknowledgement turns a records-integrity decision into a budget decision, and the budget decision wins — which is exactly how a district ends up with four PDFs and a drawer of paper acknowledgement pages.

So the core is free to the school: no per-seat licence and no per-student fee. We earn elsewhere in the platform, on things a school chooses to sell rather than on things it is obliged to record. If you want the full commercial picture in writing before a board meeting, ask and we will send it.

There is no checkout here and no card is charged on this site.

Book a conversation Request the security paperwork →

The questions an administrator actually asks

Common questions

Can it tell me which version of the handbook was in force on a given date?

Not yet as a single lookup, and the honest answer matters more than a comfortable one. What is stored is the thing that makes the answer possible: every version is an immutable row with its own publish instant, kept rather than overwritten, and the database refuses to write a second version four. What is not built is the read that resolves an as-of date — the current read surface returns the version in force now. Asking a database that has the rows is a small piece of work; asking a folder of replaced PDFs is not possible at all. We would rather tell you which of those two situations you are buying into.

Is this a board-governance product or a handbook product?

A handbook product that sits on the governance engine already in the platform rather than duplicating it. The adoption lifecycle, the motion and quorum tally, the model-policy shelf with its immutable editions, and the public open-meeting read are all existing, registered surfaces backed by their own migrations. We did not rebuild any of them for this page. If your problem is board packets and agendas first, say so — that is the governance surface, and it is a different conversation from handbook authoring.

So where does the electronic signature fit?

Inside one step: capturing an acknowledgement. It is a mechanism this product uses, not what this product is, and an earlier version of this page had that backwards. Today the durable acknowledgement is a clickwrap confirmation stored against a specific version. The cryptographic seal is not configured, so no capture can reach a sealed state and the finalisation endpoint refuses with that reason; the consumer consent resolver is unset, so a parent or student capture is refused. Both are single deployment values, and neither is something we will describe as working before it is.

What can a school actually do with this today?

Author handbooks as versioned documents with ordered sections and a derived table of contents; cut immutable versions; publish only when no section is blank; adopt model policy sections with their provenance recorded and their customisation marked; record acknowledgements bound to a specific version and work the outstanding list. All of it behind a module flag, with authoring restricted to the administrator tier. What a school cannot do today: roll a handbook into a new year, distribute it to a scoped audience, offer it in another language, or export a print-ready file. Those engines are written and tested and have no route calling them.

Why is so much of this marked built but not wired?

Because it is, and the alternative is a page that reads better and tells you less. Five of the capabilities described here are pure, tested engines with no production caller: nobody can reach them, and calling them available would be the exact failure this page is trying not to commit. They are a route away rather than a rewrite away, which is a real difference, but a route away is still not working. When one is wired its card changes.

Does any of this involve AI?

No. Nothing on this product drafts, summarises, or translates a policy with a model. The translation seam is deliberately injected and reports that no engine is attached, which is why a language stays off the menu until a person has translated every required section. A handbook is a document a school is accountable for; a plausible-sounding paraphrase of a discipline policy is a liability, not a feature.

Is student data involved?

Handbook content carries none. Sections hold an opaque section reference and an opaque body reference, and no name, photograph, or free text about a person, which is what keeps the authoring surface census-neutral. Acknowledgement rows do reference a person, and those sit behind forced row-level security with a restrictive wall that shows a photography rep zero rows. A student cannot self-acknowledge; a minor’s acknowledgement runs the parent path. Nothing about an acknowledgement is public.

What does it cost?

The core is free to the school: no per-seat licence, no per-student fee. There is no checkout on this site and no card is charged here. We earn elsewhere in the platform, on things a school chooses to sell rather than on things it is obliged to keep a record of. If you need the full commercial picture in writing before a board meeting, ask and we will send it.

Is any of this a compliance certification or legal advice?

Neither. No SOC 2, FERPA, COPPA, or VPAT certification is claimed anywhere on this page. The accessibility surface is three checks, not an audit, and no conformance level is asserted. Descriptions of records-keeping behaviour describe what the code does; your counsel decides what that means for your district.

Where to start

Bring us the policy somebody argued about.

Not the whole handbook. One policy: the attendance rule a family disputed, the conduct clause an investigation asked about, the eligibility requirement a parent said was different last season. Then ask your current arrangement which version of that policy was in force on the day, and who had been given it. The answer, or the silence, is the entire argument for this product.

The honest next step is a conversation rather than a trial signup, because which part you need first changes the shape of the answer: authoring and acknowledgement are running, and rollover, distribution, translation, accessibility, and print are written and waiting for a route.

Book a conversation Security review →