Join the coalition that governs the standard.

1 · A rule is typed JSON

Every child-safety obligation is one of ~100 typed categories (e.g. age_gate, os_age_signal_ingest, ai_chatbot_tier_gate, nfk_hard_block). You match on the category, not on the statute it came from. Build to the spec, not to the statute.

Why "~100" and not an exact number. The taxonomy is versioned, so three counts legitimately differ: the implementation tree currently ships 96 categories, the v1.0-DRAFT registry declares 104 (it reserves IDs ahead of code), and 106 appear in the statute-to-rule map (two are aliases that fold into a canonical ID). The declared registry in the spec is canonical: code and mappings converge to it at each ratified version. We say "~100" in prose precisely because the exact integer is a moving, versioned figure, not a marketing round-up.

// one rule, resolved for a given subject + jurisdiction
{
  "rule": "ai_chatbot_tier_gate",
  "capability": "Tier",        // 1 of 8 runtime caps
  "age_band": "13-17",           // derived band, never DOB
  "decision": "warn",            // allow | warn | block
  "jurisdiction": "US-NY",
  "cite": ["NY-S9051"]          // statute provenance
}

2 · It travels in a two-layer signed envelope

The outer layer carries routing metadata and the sender's Ed25519 signature, visible to the intermediary so it can route. The inner layer is JWE-sealed to the receiver's public key, so the intermediary forwards bytes it cannot read.

{
  "outer": {                  // readable by intermediary
    "to": "did:ocss:resolver-7",
    "alg": "EdDSA",          // RFC 9421, Ed25519
    "sig": "…sender signature…",
    "family_hash": "…"      // domain-sep per receiver
  },
  "inner": "eyJhbGciOiJF…"      // JWE, opaque to intermediary
}

You fetch the receiver's public key from the eIDAS-style signed Trust List (modeled on the EU Trusted List; cached ≤24h), not from a bilateral exchange. The inner JWE is sealed with that key: content-encrypted under A256GCM, key-wrapped to the recipient (ECDH-ES+A256KW against the receiver's published JWK), so the intermediary holds no decryption key by construction. The family_hash it carries is domain-separated per receiver (a keyed hash bound to the destination), so the same household resolves to a different value at every hop and cannot be correlated across intermediaries.

3 · Verify before you enforce

1. Resolve the sender in the signed Trust List. Reject anyone not listed or whose key is past its ≤180-day rotation window.
2. Verify the Ed25519 signature over the outer layer per RFC 9421. Bad signature → drop, do not enforce.
3. Decrypt the JWE inner with your own key. Only the addressed receiver can.
4. Apply the rule (allow, warn, or block) at your enforcement surface. Never downgrade to a weaker rule than the envelope carries.
5. Emit one immutable audit row per envelope: the OCSS Receipt carries rule ID, age band, jurisdiction, decision, statute cite, signed and timestamped.

4 · Conformance & the mark

The conformance suite tests your implementation against the rule list of each of the 9 capabilities you claim. Pass it and you may display the mark: Implementer (self-attested, free, public registry) or Certified (audited by an approved assessor, verified registry).

Routing intermediaries carry the binding obligations: MUST validate every sender signature, address to the receiver's public key, emit one immutable audit row per envelope, publish real-time status, rotate signing keys ≤180 days, and pass an annual independent audit (SOC 2 Type II minimum). MUST NEVER decrypt payloads, retain contents past delivery, or correlate routing metadata across families.

The suite is in active drafting. Test vectors, envelope schemas, and signing-protocol fixtures publish in RFC-draft form (targeted Q3 2026). See Conformance for the full MUST / MUST-NEVER contract.