Charter
The open child-safety specification (OCSS v1.0).
The canonical document the standard is written against.
The Open Child Safety Specification (OCSS) — Draft 4 · pre-release, filed as the individual IETF Internet-Draft draft-phosra-ocstf-00. The canonical document: nine layers, 115 rule categories (67 anchored / 48 provisional), every law cross-referenced, every rule traceable back to a statute or recognized standard.
The Charter is the contract. Every adopter implements against it. Every regulator can audit against it. Every parent’s policy compiles against it. It’s the only place where what OCSS means is defined, not implied.
Versioned. Governed. Open. OCSS is the open protocol; Phosra implements it. Ratification is the goal, not a claim — the draft is in its pre-release stage; v2 governance opens to Tier 1+ adopters under a constitution-style amendment process. The Charter is not Phosra’s product — it’s the thing the coalition exists to steward.
Semver, with a constitutional deprecation window.
- Semantic versioning— minor (1.x) for clarifications and additive rules, major (2.x) for breaking changes that require adopter migration.
- 18-month deprecation window— no rule is removed or breaking-changed without 18 months of overlap with the prior version.
- Guaranteed v(N) / v(N+1) overlap— every adopter has a guaranteed read of two consecutive major versions running in parallel during the migration window.
- Governance committee for major versions— v2.0 and beyond require a two-thirds vote of the Adopter Council before ratification.
- Public changelog— every rule change carries the citing statute, the proposing working group, and the ratification record.
The Charter, then eight runtime capabilities.
The Charter defines the spec. The other eight implement it — each one mapping to a specific class of child-safety rule.
Phosra stewards v1. The Adopter Council governs everything after.
Phosra stewards v1. v2 and beyond are governed by an Adopter Council elected from Tier 1+ adopters. Working groups exist for AI Safety, Privacy, Algorithmic Transparency, and Hard Blocks. Public quarterly reviews publish proposed amendments, voting records, and the ratified diff against the live spec.
Three ways in.
- File an RFC on GitHub — CONTRIBUTING.md. Anyone can propose a clarification, a new rule, or a deprecation.
- Join a Working Group— Tier 2+ adopters get a seat in the AI Safety, Privacy, Algorithmic Transparency, or Hard Blocks working groups.
- Submit conformance test cases— new rules require new tests; submitters get authorship credit in the conformance suite.
Three adopter tiers.
Tier 1— self-attested implementation passing the conformance suite. Tier 2— working group member, votes on the spec. Tier 3— Steering Committee seat (invite-only). Full conformance suite test count is [draft] coming Q3 2026. Each capability page lists its own suite scope.
We are co-authoring the suites with our design partners. If you want a seat at the table while the bar is being set, reach out.