PCSS public review, 24 hours in

Yesterday we published the Phosra Child Safety Specification (PCSS) v1.0 as public review at github.com/phosra-spec/pcss. Today we ran twelve specialist agents at it asking one question: would a real tech person think this is a legit spec?

Mean score across twelve dimensions: 60 out of 100. Range: 38 to 72. The full scorecard, with the specific files that need fixing and the hour-counted plan to push the average to 90, is committed to the repo at _planning/audit-2026-05-12.md. We chose to publish the audit before fixing the audit because the alternative — quietly improving the spec while marketing it as polished — is the standards-body posture we wrote PCSS to avoid.

What we fixed in the next 24 hours

Of the fifteen items on the path-to-90 plan, eleven landed. Canonicalization is now pinned to RFC 8785 JCS with a byte-literal PCSS-v1.0 domain prefix — previously the spec, the capability docs, the examples, and the SDK said four different things about how to canonicalize a receipt before signing, which would have prevented any cross-implementer signature replay. Every rule in the registry now carries an enforcement_status field distinguishing in-force statutes from proposed bills, enjoined laws, and phased ones; the conformance suite fails any rule that marks a proposed bill as default-deny without an advisory flag. Signature envelopes opened up to support post-quantum hybrid suites without a breaking v1.1 change. Extensions blocks across every wire envelope are locked down with a 22-key PII blocklist that prevents email/phone/device-ID/precise-geo from being smuggled in by a buggy or hostile implementer.

Beyond the spec text: the reference TypeScript server now actually signs the bearings it issues — yesterday it was returning the literal string "REFERENCE_PLACEHOLDER_signing_not_implemented_for_bearings" — and exposes a registry-keys endpoint so third-party verifiers can validate receipts against the reference's public key. The SDK's Lens evaluator now implements the seven-subsection conflict-resolution algorithm in pcss-v1.0.md §4.3 correctly: stricter-rule order, orthogonal-axis composition, tie-break to default-deny, and deterministic merging across jurisdictions. The conformance runner — yesterday a function that returned an empty array — now actually loads fixtures, posts them to an implementer's endpoint, and diffs the response against expected verdicts.

What the scores look like now

After the eleven fixes: average ~73. No dimension below 58. Three (legal-policy alignment, open-spec hygiene, cryptography) cross 80. The conformance dimension moved from 38 to 58, implementability from 48 to 70. The remaining gap to 90 is mostly governance work — six working-group charters, an Adopter Council application packet, the foundation-transition memo with a ranked candidate host — and the longer-tail conformance pieces (ephemeral test-key keygen, signature-verification harness, PII fuzzing).

Why publish the audit at all

Three reasons. First: "the standard does not wink." If we're going to ask other implementers to trust the spec, the trust has to be earned by showing what's wrong with it, not by hiding behind launch-day polish. Second: the spec is a public artifact under CC BY 4.0; anyone can audit it. Better to do the audit ourselves and publish the gaps than to wait for an adverse third-party review. Third: this is what we want the standards body to do at every release. The Adopter Council, when it seats in Q3 2026, will run this audit before every minor version. Today is the dry run.

What comes next

The next 90-day milestones are unchanged: ship a working Tier-0 conformance test runner by 2026-06-15 (the v0.2 we landed today covers Schema and Semantics; v0.3 adds Replay and Negative; v0.4 ships the signed-manifest ledger). Publish six working-group charters and seat their chairs by 2026-07-01. Open the Adopter Council application window by 2026-07-15. Publish @phosra/sdk to npm and stand up the reference server at reference.pcss.dev by 2026-07-20. Land at least one external implementation by 2026-08-08 — the canonical signal that PCSS is a multi-vendor standard, not a single-vendor wire format.

If you build parental controls, operate a platform that hosts minors, work in age assurance, or set policy at a civil-society or regulatory body, the repo is open and the issue tracker accepts files now. The next iteration of this audit publishes when we hit average 90.