OCSS terms are defined by the specification at openchildsafety.com,
not by Phosra. Where a definition below is normative to the standard, the linked page cites the
governing OCSS section. Snapshot spec version:
ocss-v4-draft-4.Abuse signal
A content-free flag a platform attaches to the outer routing manifest of a signed envelope — for example “possible grooming, severe” — so the census can route the sealed payload to the correct provider enclave without ever reading the underlying content. The census acts on the abuse signal; it never opens the sealed payload. See Server-Side Enclave Routing.Accreditation
A party’s standing on the OCSS Trust List: an accredited provider holds a verifiable, signed designation (and an accreditation tier) that any other party can fetch and check without calling back to Phosra. Phosra is an accredited OCSS provider; accreditation is earned from the standard, not issued by Phosra. See Trust Framework.Accreditation tier
The graded level of a party’s accreditation, carried asaccreditation_tier on
its Trust List entry — e.g. provisional vs accredited. The receiving party
checks the tier at decision time: a signal from a provisional sender is handled more
conservatively than one from an accredited sender, and a higher tier clears more
Restricted-band writes. (The hosted sandbox Trust List also uses a standin
tier for its demo parties.) See Trust Framework.
Advisor agent
Phosra’s control-plane record for a party Phosra federates with on the OCSS network — the row that carries the party’s DID, declared signing and payload keys, and accreditation tier, and that backs its Trust List entry. You register and consult advisor agents through the management API. See Trust Framework.Band
The sensitivity class of an OCSS rule category, which sets how much authorization a write to it must clear. Open-band categories (e.g.addictive_pattern_block) accept a correctly-standing
consent attestation write; Restricted-band categories — the
§12.3-gated ones such as the harm_context lane — require additional gating before the
census will route them. A write to a category whose band the caller is not eligible for
is rejected 403 standing_failure. See Trust Framework.
Census
Phosra’s hosted OCSS census — a Trust-Framework-conformant relay that persists, distributes, and confirms signed child-safety signals between providers and platforms. The census routes signed envelopes but is structurally blind to sealed payloads; it never sees plaintext content. See Partner Integration Overview.Child profile
A child is a profile inside a family, defined by a name and birth date. Children have no login of their own — they are represented as profiles a guardian manages. Phosra derives the child’s age group from the birth date to compute age-appropriate rule defaults. See Children & Age Groups.Consent attestation
A signed record that a guardian granted verifiable parental consent for a specific rule write (OCSS §8.3.2). The census verifies the attestation against the Trust List and derives the write’s standing class from it (aconsent:attestation:… standing
ref). A rule write whose consent attestation is missing, forged, or names the wrong app is rejected
403 standing_failure. Consent is the standing that authorizes Open-band writes. See
Intent API.
Control plane
The management surface of Phosra — orgs,phosra_ API keys, usage, advisor agents, and MCP
tokens. Phosra-specific, Bearer-authenticated, and kept deliberately separate from the
data plane so that account management never touches the enforcement path. See
Architecture.
Data plane
The enforcement path — a policy is compiled into a signed profile and enforced locally on the device or platform. Enforcement runs against a signed profile the platform already holds, so it keeps working even when the census is unreachable. See Architecture.DID
A Decentralized Identifier (e.g.did:ocss:your-org) is the stable, portable name for a party
on the OCSS network. A DID’s signing and payload keys are published on the Trust List,
so any party can look up who signed an envelope and seal a reply to the right recipient. A DID that
is absent, suspended, or expired is rejected with 403 standing_failure. See
Trust Framework.
Enclave
A provider enclave is the isolated environment where a provider decrypts and classifies content that a platform sealed directly to it. The census carries only the content-free abuse signal, a minimization receipt, and a routing manifest — never the plaintext or the ciphertext. See Server-Side Enclave Routing.Enforcement job
The unit of work created when you push a child’s active rules to connected platforms.POST /children/{childID}/enforce returns 202 Accepted with a job_id; Phosra fans the rules
out to each platform in parallel. There is no completion webhook — poll
GET /enforcement/jobs/{jobId}/results for the per-platform outcome. See
Enforcement.
Enforcement mode
The honest capability signal on each platform fromGET /platforms: dns, device,
api_write, manual_attested, or coming_soon. It tells you whether Phosra makes a live
programmatic write or emits guided setup steps for a parent to complete — never render
“Enforced” for a manual_attested platform. See Platforms & Enforcement Modes.
Family
The top-level organizational unit in Phosra. Every child, policy, platform connection, and webhook belongs to a family. A family has one or more adult members with roles — owner, parent, or guardian — and must have at least one owner. See Families.Gatekeeper
An OCSS role (§3.2): the party that enforces the access decision — a regulated platform deciding whether to gate a feature or transmit a signal. Platforms integrate as gatekeepers with the@phosra/gatekeeper SDK, which verifies signed rule profiles and confirms
enforcement locally. See OCSS Roles.
Idempotency key
A client-supplied token you place in a write’s request body asidempotency_key — Phosra does
not read an Idempotency-Key HTTP header. Replaying the same key with the same payload
returns the byte-identical original result (200 OK plus an OCSS-Replay: original header) instead
of writing twice; reusing a key with a changed payload is rejected 409 Conflict
(class: "replay") and nothing is applied. Use one per logical operation so a dropped connection
never double-writes. See Idempotency & replay.
Lane
A typed channel through the census for one kind of signed signal — e.g. the consent-attestation lane, the CSM-ratings lane, the enforcement-confirmation lane, or the §12.3harm_context lane. Each lane is independently activatable, and an active lane MUST
name its governing instrument (§5.2.6) — the census rejects a signal on an inactive lane. A lane
verb is distinct from an OCSS role: one party can drive several lanes. See
Trust Framework.
Minimization receipt
A signed, recomputable receipt proving a platform reduced a sealed payload to the minimum content needed for classification before routing it — the data-minimization proof the census carries alongside the abuse signal and routing manifest, without ever seeing the payload itself. See Server-Side Enclave Routing.OCSS
The Open Child Safety Specification — a vendor-neutral open standard for age-appropriate access control. It publishes the rule vocabulary, signing semantics, Trust Framework, and conformance suite. Phosra implements OCSS; the OCSS stewardship body owns it, the same way Yubico implements FIDO2 without owning it. See OCSS Overview.Platform
A content or service app where children consume content — Phosra’s enforcement target. In OCSS terms a platform integrates as a gatekeeper. Each platform advertises an honest enforcement mode describing what Phosra can actually do on it. See Platforms & Enforcement Modes.Policy
A named collection of rules assigned to a child. A policy has a status —draft, active, or paused — and a priority for ordering. Only active policies are enforced;
a child can have several (e.g. “School Day” and “Weekend”) and switch between them. See
Policies & Rules.
Provider
A parental-controls vendor that links families, ingests parent consent, and writes rules using the@phosra/link SDK. In OCSS terms a provider typically acts as both Issuer and
Verifier. See Partner Integration Overview.
Receipt
A signed, recomputable record proving an action happened as logged — a rule write, a consent attestation, or an enforcement confirmation (§8.3.8). Any accredited party can verify a receipt
against the Trust List without calling back to Phosra. See
Trust Framework.
Role
One of the four OCSS parties (§3.2): Issuer (originates an attribute), Verifier (validates a presented attribute), Gatekeeper (enforces the decision), and Infrastructure Intermediary (routes signed envelopes). A role is distinct from a lane verb — one party can hold several roles at once. See OCSS Roles.Routing manifest
The outer, content-free addressing block of a signed envelope: who signed it, which provider enclave the sealed inner payload is bound to, and the abuse signal that justifies routing. The census reads the routing manifest to relay the envelope; the sealed inner payload stays opaque to it. See Server-Side Enclave Routing.Rule
A single entry in a policy that controls one category from the closed OCSS rule vocabulary (e.g.time_daily_limit, content_rating). Each rule has a category, an enabled
flag, and category-specific config JSON. See Policies & Rules.
Sandbox
Phosra’s hosted, isolated test environment — a full OCSS census seeded with a demo family and rules, served athttps://phosra-api-sandbox-production.up.railway.app/api/v1. It accepts
phosra_test_… keys, is the default {{baseUrl}} in the Postman collection and
the inline Try it runner, and is wired end-to-end so real calls return real signed responses.
Nothing you send in the sandbox can touch a production family. See Quickstart.
Signed envelope
The wire format OCSS parties exchange under the Trust Framework: a two-layer structure. The outer layer is a signed routing envelope — a manifest plus a content-free signal — that the census reads and relays; the inner layer is a payload sealed to the recipient’s published key, which the census is structurally blind to and never opens. Any party can authenticate the signer and, for a sealed reply, encrypt to the right recipient using keys on the Trust List. See Server-Side Enclave Routing.Standing
The OCSS class under which a rule write is authorized. A parent’s consent attestation maps to a correctly-standing, band-eligible rule write that the census signs; a caller with no valid standing (e.g. an unrostered DID with no consent row) is rejected403 standing_failure. See
Intent API and Platform integration.
Strictness
A preset —strict, recommended, or relaxed — applied at rule-generation time (via quick setup
or generate-from-age) that shifts all rule defaults tighter or looser relative to the age-group
baseline. recommended is the default. See Strictness Levels.
Trust List
The OCSS eIDAS-style registry of accredited parties and their public keys, served as a signed document (Ed25519 root signature). Signing keys and EC P-256 payload keys are published here so any party can authenticate a sender and seal a payload to a recipient. See Trust Framework.Verdict
The gatekeeper’s per-category enforcement decision, read from the signed profile via the@phosra/gatekeeper SDK (gk.check(category)). Each category resolves to a decision of
allow, warn, or block; calling verdict.confirm("applied") signs the §8.3.8 confirmation
receipt. See Fetch profile and
Submit confirmation.