total
the resolved audience size -- the roster this requirement applies to.
The policy manual · a closed law, not a habit
The board-policy manual, in depth: lifecycle, versions, and the acknowledgment ledger
A policy binder anyone can quietly edit is not a real record. The manual here runs on a closed lifecycle law -- draft, active, retired -- with every published version numbered and never edited in place, organized into 9 real categories, and backed by a staff acknowledgment ledger that tracks exactly who has and has not read the CURRENT required version.
Staff-gated, module-gated -- an add-on your board turns on, not something already running everywhere. No public browse-the-manual read on this page.
The policy lifecycle law
Draft, active, retired -- and nothing else
A policy's status can only move where the closed law allows. Any other move is refused outright, and only a governance officer may move a policy at all:
draft→activeorretiredactive→retiredretired→ nothing (terminal)
A draft may only become active when it already points at a real published version -- there is no such thing as an empty "active" policy on this platform.
The immutable version sequence
Every published text is a new version, never a silent edit
Publishing new policy text creates the NEXT numbered version -- it does not overwrite the last one. A version number, once published, never changes, and the manual always resolves to the current version's exact text.
The published manual
Only active policies appear, sorted the way a board reads a printed manual
The published manual includes only ACTIVE policies, resolved to their current version, grouped into these 9 categories (manual order), then sorted by policy code inside each category:
governance students personnel finance facilities instruction community relations bylaws other
Staff acknowledgment compliance ledger
Who has read the CURRENT required version, who is outstanding, who is overdue
Assign a policy that requires staff sign-off and the ledger computes, per requirement:
acknowledgedCount
how many of that roster have acknowledged the CURRENT required version.
outstanding
opaque staff refs who have not acknowledged the current version -- an ack against an older, superseded version leaves a staffer outstanding until they re-acknowledge.
overdue
the subset of outstanding that is past the assignment's due date.
completionPct
0 to 100, the resolved completion rate for this requirement.
Two acknowledgment methods are ever stored by the governance engine itself
Clickwrap self-attestation
The staffer's own action -- must be their own staff_ref, never recorded on someone else's behalf.
Wet signature on file
Recorded by a governance officer from the paper signature they keep on file.
Every staff_ref in the acknowledgment ledger is an opaque identifier to an ADULT staff member -- never a student_id. The ledger is walled at the database by the restrictive staff-data access rule; no roster of students, parent contact, or any other student-shaped field lives in this manual or ledger.
E-signature -- captured and bound, not yet sealed
An e-signature acknowledgment is captured and bound to the exact adopted text -- honestly unsealed
When a staffer acknowledges by e-signature, the platform captures a signature over the EXACT stored, adopted policy-version bytes they are acknowledging -- not a separate copy that could drift from the record.
The cryptographic seal stays honest-off: sealState is "provider_not_provisioned". The acknowledgment is captured and bound, but not yet cryptographically sealed by a live signing provider -- this platform never fabricates a seal, and an e-signature acknowledgment is never presented here as a finalized, notarized instrument.
Get started
See the manual, the ledger, and the lifecycle law running on your own board's policies
There is no pricing commitment and no signup on this page -- pricing lives on the pricing page. A governance walkthrough shows the current, honest state of the manual and the acknowledgment ledger.
FAQ
Common questions
Is board governance automatically turned on for our school?
No. The policy manual and the board-meeting workspace are each an add-on module a district enables for its board -- neither is on by default. A district that has not turned a module on sees nothing different; the surfaces stay dark until a governance officer's school or district administrator switches them on.
How does a staff member acknowledge a board policy?
Two ways today: a staffer's own clickwrap 'I acknowledge,' or a wet signature a governance officer keeps on file and records on the staffer's behalf. A compliance ledger tracks who is outstanding against the CURRENT required version and who is overdue -- an acknowledgment against an older, superseded version does not count. A fully sealed cryptographic e-signature is captured and bound to the exact policy text but not yet cryptographically sealed by a live signing provider -- honest-off until that seal is provisioned.
Does any student appear on the public board page?
No. The public record is your board's agenda, minutes, motions, and named roll-call votes -- adult public officials answering on the record, not students. It carries no internal ids and no student reference of any kind. Anywhere else a student's data lives on the platform, it stays behind the platform's consent gate: a minor without recorded consent is never public, indexed, or searchable.
How does our board get its records into the system?
Sign in the same way your district already does -- single sign-on -- and a governance officer opens a meeting, defines a policy, or records a motion directly inside the workspace. There is no separate spreadsheet import for board records today; the workspace is where the record is made.
What does this cost?
Money is honest-off on this front door: no price, no checkout, no plan comparison lives here. Pricing lives on the pricing page, and a governance walkthrough is the way to talk through what your board specifically needs.