> ## Documentation Index > Fetch the complete documentation index at: https://docs.phosra.com/llms.txt > Use this file to discover all available pages before exploring further. # Glossary > Plain-language definitions of the Phosra and OCSS terms a new developer hits — family, policy, rule, enforcement job, verdict, standing, consent attestation, sandbox, idempotency key, signed envelope, routing manifest, abuse signal, minimization receipt, lane, band, accreditation tier, advisor agent, enclave, gatekeeper, DID, receipt, and more. Each links to its authoritative reference. 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](/ocss/overview) that Phosra implements. Every entry links to the page that defines it normatively — start there when you need the full contract. OCSS terms are defined by the specification at [openchildsafety.com](https://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](#platform) attaches to the outer [routing manifest](#routing-manifest) of a [signed envelope](#signed-envelope) — for example "possible grooming, severe" — so the [census](#census) can route the sealed payload to the correct [provider](#provider) [enclave](#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](/integration/server-side-enclave-routing). ### Accreditation A party's standing on the OCSS [Trust List](#trust-list): an accredited provider holds a verifiable, signed designation (and an [accreditation tier](#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](/ocss/trust-framework). ### Accreditation tier The graded level of a party's [accreditation](#accreditation), carried as `accreditation_tier` on its [Trust List](#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](#band) writes. (The hosted [sandbox](#sandbox) Trust List also uses a `standin` tier for its demo parties.) See [Trust Framework](/ocss/trust-framework). ### Advisor agent Phosra's [control-plane](#control-plane) record for a party Phosra federates with on the OCSS network — the row that carries the party's [DID](#did), declared signing and payload keys, and [accreditation tier](#accreditation-tier), and that backs its [Trust List](#trust-list) entry. You register and consult advisor agents through the management API. See [Trust Framework](/ocss/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](#consent-attestation) write; **Restricted-band** categories — the §12.3-gated ones such as the `harm_context` [lane](#lane) — require additional gating before the [census](#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](/ocss/trust-framework). ### Census Phosra's **hosted OCSS census** — a Trust-Framework-conformant relay that persists, distributes, and confirms signed child-safety signals between [providers](#provider) and [platforms](#platform). The census routes signed envelopes but is structurally blind to sealed payloads; it never sees plaintext content. See [Partner Integration Overview](/integration/overview). ### Child profile A **child** is a profile inside a [family](#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](/concepts/children-and-age). ### Consent attestation A signed record that a guardian granted **verifiable parental consent** for a specific rule write (OCSS §8.3.2). The [census](#census) verifies the attestation against the [Trust List](#trust-list) and derives the write's [standing](#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](#band) writes. See [Intent API](/ocss/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](#data-plane) so that account management never touches the enforcement path. See [Architecture](/concepts/architecture). ### Data plane The enforcement path — a [policy](#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](#census) is unreachable. See [Architecture](/concepts/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](#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](/ocss/trust-framework). ### Enclave A **provider enclave** is the isolated environment where a provider decrypts and classifies content that a [platform](#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](/integration/server-side-enclave-routing). ### Enforcement job The unit of work created when you push a child's active [rules](#rule) 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](/concepts/enforcement). ### Enforcement mode The honest capability signal on each platform from `GET /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](/concepts/platforms). ### 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](/concepts/families). ### Gatekeeper An OCSS [role](#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](/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](/idempotency). ### Lane A typed channel through the [census](#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](#role): one party can drive several lanes. See [Trust Framework](/ocss/trust-framework). ### Minimization receipt A signed, recomputable [receipt](#receipt) proving a [platform](#platform) reduced a sealed payload to the **minimum content** needed for classification before routing it — the data-minimization proof the [census](#census) carries alongside the [abuse signal](#abuse-signal) and [routing manifest](#routing-manifest), without ever seeing the payload itself. See [Server-Side Enclave Routing](/integration/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](/ocss/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](/ocss/overview). ### Platform A content or service app where children consume content — Phosra's [enforcement](#enforcement-job) target. In OCSS terms a platform integrates as a [gatekeeper](#gatekeeper). Each platform advertises an honest [enforcement mode](#enforcement-mode) describing what Phosra can actually do on it. See [Platforms & Enforcement Modes](/concepts/platforms). ### Policy A named collection of [rules](#rule) assigned to a [child](#child-profile). 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](/concepts/policies-and-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](#role) and Verifier. See [Partner Integration Overview](/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](#trust-list) **without calling back to Phosra**. See [Trust Framework](/ocss/trust-framework). ### Role One of the four OCSS parties (§3.2): **Issuer** (originates an attribute), **Verifier** (validates a presented attribute), **[Gatekeeper](#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](/ocss/roles). ### Routing manifest The outer, **content-free** addressing block of a [signed envelope](#signed-envelope): who signed it, which [provider](#provider) [enclave](#enclave) the sealed inner payload is bound to, and the [abuse signal](#abuse-signal) that justifies routing. The [census](#census) reads the routing manifest to relay the envelope; the sealed inner payload stays opaque to it. See [Server-Side Enclave Routing](/integration/server-side-enclave-routing). ### Rule A single entry in a [policy](#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](/concepts/policies-and-rules). ### Sandbox Phosra's **hosted, isolated test environment** — a full OCSS [census](#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](/tools/postman) 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](/quickstart). ### Signed envelope The wire format OCSS parties exchange under the [Trust Framework](/ocss/trust-framework): a **two-layer** structure. The outer layer is a signed routing envelope — a manifest plus a content-free signal — that the [census](#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](#trust-list). See [Server-Side Enclave Routing](/integration/server-side-enclave-routing). ### Standing The OCSS class under which a rule write is authorized. A parent's [consent attestation](#consent-attestation) maps to a correctly-standing, [band](#band)-eligible rule write that the census signs; a caller with no valid standing (e.g. an unrostered [DID](#did) with no consent row) is rejected `403 standing_failure`. See [Intent API](/ocss/intent-api) and [Platform integration](/integration/platform). ### 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](/concepts/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](/ocss/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](#receipt). See [Fetch profile](/api-reference/data-plane/fetch-profile) and [Submit confirmation](/api-reference/data-plane/submit-confirmation).