Glossary

The vocabulary you will meet reading these docs, in one place. Phosra's product terms (family, child, policy, rule) describe the parental-controls layer Phosra built; the OCSS terms (gatekeeper, standing, receipt, Trust List, DID) are defined by the open Open Child Safety Specification that Phosra implements. Every entry links to the page that defines it normatively — start there when you need the full contract.

---

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 proposed governance decision represented on an OCSS Trust List. The draft describes signed designations and accreditation tiers, but a tier value in a schema or sandbox fixture is not an independent accreditation decision. Phosra does not claim current accreditation. See Trust Framework.

Accreditation tier

A draft Trust List field representing proposed standing, such as provisional or accredited. Sandbox fixtures exercise tier-dependent code paths, but their values are not independent accreditation decisions. See Trust Framework.

Advisor agent

An evaluation/control-plane record carrying a synthetic party's DID, declared public keys, and proposed tier field. Sandbox advisor records do not establish production federation or accreditation. 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

The relay defined by the OCSS draft. Phosra exposes a hosted sandbox census for synthetic evaluation. A production hosted routing service and receipt rail remain roadmap. 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 (a consent: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 draft's stable name for a party. Sandbox registry records associate DIDs with test public keys so evaluators can exercise signing, lookup, and standing-failure behavior. See Trust Framework.

Enclave

A provider enclave is the draft architecture's isolated environment for decrypting and classifying content sealed directly to a provider. Public examples and harnesses demonstrate the model; Phosra does not claim a production enclave-routing network. See Server-Side Enclave Routing.

Enforcement job

The product/sandbox unit of work created when an enforcement simulation starts. POST /children/{childID}/enforce returns 202 Accepted with a job_id; sandbox results model per-platform outcomes but do not prove third-party delivery. There is no completion webhook — poll GET /enforcement/jobs/{jobId}/results for the per-platform outcome. See Enforcement.

Enforcement mode

A capability field on each sandbox platform fixture: dns, device, api_write, manual_attested, or coming_soon. It lets clients exercise mode-aware UI and state handling; it is not proof of a live adapter. 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 as idempotency_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.3 harm_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 for a draft action such as a rule write, consent attestation, or enforcement confirmation (§8.3.8). Sandbox receipts demonstrate offline verification mechanics; they are not production compliance evidence. 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 at https://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 rejected 403 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 draft's eIDAS-style model for a registry of parties and their public keys, represented in the sandbox as a signed test document. Sandbox tier values are not independent accreditation. The sandbox document uses an Ed25519 test-root signature. Signing keys and EC P-256 payload keys are published there so a developer can exercise sender authentication and payload sealing. See Trust Framework.

Verdict

The gatekeeper's per-category enforcement decision, read from the signed profile via the @phosra/gatekeeper SDK (gk.isAllowed({ category, signal })). 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.