K-12 and education, FERPA / COPPA / CIPA posture

source: citrate-docs/public-goods/learning-center/PRIVACY_SECURITY_AND_COMPLIANCE.md

How Citrate Schools is built for K-12: the district keeps control of student records, student data stays on the district's own hardware, and contracts plus technical controls hold use to the school's educational purpose. This is the public summary for district counsel, IT, and procurement teams. It is a design-and-operations description, not legal advice, and not a claim of certification.

What it is

Citrate Schools is the school-facing track of Citrate Ground, the private, on-premise half of the network. A district runs the software on infrastructure it selects: on-premise, a restricted network, or a private Citrate deployment. Student records stay under the local education agency's control on that hardware. The public Citrate Network never sees a student. Nothing about a student is published to the public ledger or to a vendor-operated service.

The compliance floor for this deployment context is FERPA, COPPA, and CIPA. The design holds to four promises that follow from that floor:

No student data on the public network. Student records stay under school or LEA control on district-selected infrastructure. Publishing to the public ledger is never part of a student workflow.
Role-gated, least-privilege by default. The education stack enforces role checks at the contract level. Key institutional actions are recorded as auditable on-chain events; student personal data is not.
Educational purpose only. Data use is tied to the school's delegated educational purpose. There is no targeted advertising, no unrelated profiling, and no hidden secondary use of student information.
AI features stay optional. They are an addition on top of the privacy baseline, and they must not weaken it.

How to use it

A district counsel or procurement team can read this page top to bottom; an evaluator can follow it as a checklist.

Confirm the deployment shape. Decide whether Citrate Schools will run on-premise, on a restricted network, or as a private Citrate deployment. In all three, the data stays on the district's hardware.
Read the compliance mapping below against your own obligations. It states the design pattern for each law and the gaps that are still open, so you can plan around them rather than discover them.
Verify the access path for parents and eligible students. FERPA inspect-and-review is part of the baseline, not an optional feature; confirm the path fits your timelines.
Move the deployment-specific terms to the commercial track. District onboarding, the data-processing agreement, and staff and guardian identity checks live behind contract and identity verification. See district registration and education contracts.
Use the Learning Center for the classroom-facing surface the privacy posture protects.

Reference

The compliance floor for the K-12 deployment context, stated as the source document states it.

Law	Design pattern	Honest caveat
FERPA	The district remains the decision-maker; the vendor acts only within the school's delegated educational purpose, on the familiar "school official" path, under a written agreement. Parent and eligible-student inspect-and-review access is part of the baseline.	An attorney-reviewed data-processing agreement template is not yet complete. The guardian portal is planned and security-scoped, not yet the finished public baseline.
COPPA	In the educational context and for the school's benefit, a school may act as the parent's agent for consent. That holds only because the product posture forbids unrelated commercial use of student information.	It depends on schools operating within that educational-context boundary.
CIPA	App-level content controls can help, but they do not replace a district's internet-safety policy, filtering, monitoring, and records obligations. We do not imply CIPA compliance from "AI safety" alone.	A district relying on E-Rate-supported access keeps real operational obligations that the software does not discharge.
State student-privacy contracts (for example California AB 1584)	Pupil records remain LEA property and under LEA control; the contract describes review, correction, breach notice, retention, and deletion; targeted advertising against pupil records is prohibited. We treat this as the right contract posture even outside California.	State-specific filings are not yet complete for every state.

The security building blocks the posture rests on, from public-goods/learning-center/PRIVACY_SECURITY_AND_COMPLIANCE.md:

Local account and keystore encryption with Argon2 and AES-256-GCM.
Org-local encryption and key rotation in the Learning Center app.
Contract-level role checks in the education stack.
Auditable on-chain events for key institutional actions, not for student personal data.
The ability to run against a district-selected RPC or a private Citrate deployment.
No targeted-advertising model in the school product posture.

Design rationale

A school district cannot move student records to wherever the compute happens to be, and it should not have to. Citrate inverts the usual arrangement: the work is verified and recorded, but the data stays on the district's hardware. That is why Citrate Ground is the default for schools and the public ledger is never in the student path. The cost is that a district must run and operate the software, with onboarding and a verification step before staff and guardians get access. For the institutions this serves, that is the right trade.

Failure modes and honest gaps

The source document names gaps plainly, and we keep them named here rather than imply they are closed:

The attorney-reviewed data-processing agreement template is not yet complete.
State-specific filings are incomplete for some states.
The guardian portal is planned and security-scoped, but not yet the finished public baseline; until it ships, the parent and eligible-student access path is not fully built out.
The end-to-end integration and live smoke gates are still under construction.
Federal or defense-context packages would require additional controls beyond school compliance. This page does not cover them; see federal.

The honest rule on language: we describe the posture as on-prem capable, air-gap friendly, role-gated, auditable, district-controlled, and private-network deployable, with encryption in transit and at rest. We do not claim "fully compliant everywhere," "impossible to hack," or "zero risk." Procurement teams want evidence, baselines, and contract language, not slogans.

Access and canon

This summary is public so a district can evaluate Citrate Schools without an agreement in place. The deeper onboarding track, the data-processing agreement, and staff and guardian identity verification are on the commercial track, gated behind contract and identity verification through CLEAR. US K-12 public schools have free access to Citrate Schools in perpetuity. No student data, district names, deployment endpoints, or credentials appear on this page.

For the broader framework status across deployment contexts, see compliance posture.

Source and verification

Source: citrate-docs/public-goods/learning-center/PRIVACY_SECURITY_AND_COMPLIANCE.md, with the rest of public-goods/learning-center/. Audited against citrate-docs SHA 8757357. The compliance floor and the named gaps are reproduced from that document. Status: Specified. The privacy posture and the FERPA / COPPA / CIPA mapping are designed and written down; several of the controls that complete it, the data-processing agreement template, the guardian portal, and the end-to-end gates, are still being built and are marked as gaps above.