A district has its own authority. OCSS treats it that way.
Institutional consent runs parallel to the parental path — not derived from it.
An SSL-inspecting gateway box is not an OCSS receiver.
A box that decrypts and inspects your managed fleet's whole traffic stream inline is a different system under its own legal regime — and OCSS does not pretend otherwise. On a managed K-12 fleet, OCSS routes the signal rail — flag delivery, parent and counselor notification, receipted action — alongside your district's sighted inline filter, never in place of it. A conformant institutional deployment discloses, in a signed profile, which duties OCSS envelopes discharge and which the adjacent sighted system carries. The interop is real. It is also bounded, and the spec says where the boundary is (§8.4).
Your authority comes from statute— not a parent's signature.
An educational institution occupies two roles at once, on its own statutory basis: it originates an authoritative age and parent-child relationship from enrollment records, and it enforces across DNS, router, and MDM surfaces under a safeguarding duty (in the US: CIPA as an E-rate condition, FERPA, in loco parentis). A district that can attest age and relationship from its own records never needs to point a camera at a child to participate.
A district is not modeled as a parent.
The institutional context is its own consent path, held from statute — never a delegation chain that terminates in a parent's signature. Fudge that distinction and the model breaks in observable ways: wrong consent semantics, wrong fail-safe duty, wrong notification path. OCSS keeps the two paths separate by design so a district carries district-shaped obligations, not a simulated-parent imitation of them.
The family is never cut out.
The institution holds the lawful basis for detection and alerting — but the appeal path stays reachable by the family, not only the institution. Every institutional alert rides the same Alertlane as everyone else's, marked lawful_basis: institutional. There is no separate EDU back-channel.
District policy until the bell.
A managed device crosses authority twice a day — district policy until dismissal, parental policy after the bus ride home. That handoff is declared in the signed deployment profile, not improvised at the enforcement point (§8.4).
The trail follows the child, not the cart.
Every institutional binding attaches to the pupil-session identity — never the device serial. On a shared device cart, the audit trail follows the student who was signed in, not the hardware that happened to be in their hands. Receipts on a supervised fleet are bound to that pupil session and batched on reconnect, so offline enforcement still reconciles to the right person.
A false flag is correctable — everywhere it landed.
Every surface that delivers alerts implements one appeal rail. An upheld appeal produces a correction receipt propagated to every recipient that received the original — a false flag that reached a school counselor does not get corrected only in the parent's app. In the institutional deployment, that appeal endpoint is family-reachable and pupil-session-scoped by requirement (§11.2, §8.4) — it is not dilutable to an operator-only path.
What OCSS carries — and what your filter still does.
OCSS does not replace your CIPA-certified web filter. It runs the signal rail beside it and writes down, in a signed deployment profile, exactly which duties live where. A district IT buyer reads one artifact and knows what changed and what didn't.
Fail behavior is declared, not improvised: a supervised institutional fleet MAY select fail-closed on its designated CIPA Block categories while failing open elsewhere — so an outage neither takes a district offline nor silently suspends a statutory filtering duty (§8.2 / §8.4).
The institutional lane is named. We won't pretend it's finished.
OCSS is a pre-release individual IETF Internet-Draft (Draft 4) — not a ratified standard, and Phosra is its reference implementer and one accredited network on it, never the body that owns it. The institutional overlay is specified in the open text; the district-facing surfaces are being built. Here is the honest line between the two.
- Institutional authority as a parallel-not-derived consent path (§3.4).
- The parent-visibility floor and family-reachable appeal (§3.4 / §11.2).
- Pupil-session binding and the hours-based authority handoff (§8.4).
- Signed deployment profile with its fail-closed category list (§8.4 / §8.2).
- Aggregate, zero-identifier attestation CSV export (§8.4) — live today.
- The district admin console for managing deployment profiles and rosters.
- Turn-key enrollment-record (SIS) ingestion for institution-issued age attributes.
- The public /v1/check enforcement API (ships in P2/P3) — district sandbox pending.
- Pre-built MDM connectors for the major managed-fleet vendors.
- The 16–17 developing-autonomy sub-band, held as a named v1.1 item (Annex H).
The conformance code rates a single-vendor network as a failure — on purpose. A district should be able to leave.
Built so no one — including us — can capture it.
A school system commits for years, so the question isn't only “does it work” — it's “who controls it in five.” OCSS is an open standard with verifiable succession (the interim-steward designation is gated and pending, due 2026-07-09) and requires a federation of at least three independent routers. The standard is hosted by the coalition at openchildsafety.com, not by Phosra. We implement it; we don't own it — and we built the conformance suite to rate a Phosra-only network as a failure.
Walk your CIPA posture with an engineer.
Bring your managed-fleet setup and your filtering vendor. We'll map what the OCSS signal rail would carry beside it, what a signed deployment profile would declare, and — honestly — what isn't built for districts yet.