Skip to main content
This is the implementation path for a technology platform that owns native family controls—such as a social, gaming, or streaming platform—and wants to accept parent-authorized policy through Phosra without exposing a new public Family Center API.

​
The short answer

The platform builds one private, source-scoped adapter into the same command and read model its own Family Center uses. Phosra and Cloudflare provide the policy protocol, security shell, translation runtime, delivery lifecycle, and conformance harness around it.
Cloudflare does not change application settings simply because it fronts the platform’s traffic. Only the platform can write and truthfully read its own account state.
The included Discord Family Center pack is a candidate, unverified handoff derived from a visible UI review. It is not evidence that Discord supports OCSS, exposes the proposed private resource, approved the mappings, or authorized Phosra or Cloudflare to change an account.

​
What the platform actually has to do

The irreducible platform code is intentionally small but deep. It is the only component allowed to answer, “What is this account’s effective setting now?”

​
The private adapter

A portable starting interface is one resource with three operations:
The platform can use different internal names. The semantics are the contract:
  • PATCH idempotently upserts only the named controls in the phosra-family-policy source slice. Omitted controls stay unchanged.
  • GET independently reads effective values from the platform’s native read model. It is not an echo of the write or a connector cache.
  • DELETE removes only the Phosra source slice. It does not remove the account, native family relationship, user settings, or another managed source.
  • A second GET after release observes that the source is no longer managed.
Every operation correlates the opaque binding, source, idempotency key, link/lease generation, state revision, desired-state digest, and operation ID. The platform fences stale generations and makes an exact replay safe even when a prior write succeeded but its response or read-back was lost. For a request containing several controls, the platform must choose either an atomic source-slice transaction or explicit per-action transactions with stable per-control outcomes and deterministic reconciliation. A mixed result must never become an all-applied receipt. The platform also versions the control schema and native normalizer, declares compatibility behavior, and defines what happens to queued work created under an older version. Ordinary business decisions—relationship inactive, guardian authority missing, age assurance required, region restricted, a safety floor, or a source conflict—should be returned as bounded native refusals. They should not be encoded as retryable infrastructure failures.

​
Example: controls visible in a Discord-like Family Center

The current candidate pack preserves five action groups and nine visible leaf settings: The platform must approve or revise each meaning. “Mature Sexual Media” is not automatically equivalent to “Graphic Media,” and “only known people may contact the child” is not automatically equivalent to any one DM or friend-request toggle. Similar UI labels are not a semantic contract. The candidate identifiers are not registered OCSS categories and must not be emitted as production-compatible until governance and the platform approve the mapping.

​
Bot-assisted implementation workbench

Phosra includes a local connector workbench that starts with one control and generates a tightly bounded adapter task:
The workbench separates a privacy-reviewed public manifest from a native map that stays inside the platform repository. It can produce a TypeScript/Vitest adapter scaffold with exactly three native methods:
  • resolveAuthorizedTarget
  • putSourcePolicy
  • readEffectivePolicy
From a Phosra checkout:
This is currently a private 0.0.1 architecture prototype, not a published SDK or enforced agent sandbox. Its preflight checks references, not their truth. Its approval record is local and self-asserted unless a protected platform runner authenticates it. Its bundle is always an untrusted_local_candidate, never independent conformance or production certification. That makes it useful for reducing coding work without allowing a bot to approve its own semantics, credentials, or production promotion.

​
The opaque binding

After the platform’s own guardian/teen relationship and approval ceremony, the platform mints a random binding. The platform alone resolves it to an account or profile. The Policy Inbox, Queue, Durable Object key, connector request, logs, and receipts must not contain:
  • a platform user ID, username, email, or profile ID;
  • a parent, teen, or household identity;
  • date of birth, age band, or region; or
  • messages, contacts, servers, social graph, or child content.
The platform evaluates relationship, authority, age, region, eligibility, and safety floors internally. Cloudflare receives only the opaque binding, generations, desired actions, expiry, and cryptographic correlation. Use a separate Durable Object namespace per platform and environment, or derive the partition from a domain-separated digest of the environment, platform tenant, and opaque binding. Bindings must be random, non-derivable from native IDs, collision-resistant, expiring and revocable, and replaced with a new unlinkable value after relinking. The same raw value must never correlate work across tenants or environments.

​
What the platform configures in Cloudflare

The current executable path uses these primitives:
  • Worker: runs the shared declarative connector.
  • Durable Objects: isolate authority and per-binding lifecycle state.
  • Cloudflare Access: authenticates connector-to-native HTTPS with a least-privilege service token.
  • Cloudflare Tunnel, optional: reaches a private origin through outbound cloudflared connections.
  • Worker secrets: contain secret values referenced—but never embedded—by the signed manifest.
  • Policy Inbox Worker, Queue, and DLQ: validate and deliver the Phosra envelope with bounded retry and transport status.
There are four last-hop choices: Workers for Platforms is not required for the current per-platform connector. The present evaluation account does not prove a turnkey multi-tenant Cloudflare product or a one-click dashboard switch.
Do not create an Access client secret in Terraform. Cloudflare returns the secret at creation, which would put it in Terraform state. The supplied Terraform template takes existing service-token IDs and manages the Access application and Service Auth policy; the platform’s approved credential system creates and rotates the secret.

​
Two connector ownership models

The private adapter always belongs to the platform. Connector operations can be assigned in either of two ways:
  1. Platform-operated connector: the platform deploys the supplied Worker and Durable Object migrations in its approved Cloudflare account and owns its operational lifecycle.
  2. Managed connector: Phosra or Cloudflare operates the per-platform connector under an agreed service boundary, while the platform issues least-privilege Access credentials and retains native authority.
The second model reduces platform deployment work, but it does not remove the platform’s semantic review, native adapter, consent, binding, delegation, credential rotation, native read-back, product UI, or operations approval. Neither model should be presented as commercially or operationally available until the parties approve it. Before provisioning any key or token, the platform records its issuer, custodian, environment and audience, approved secret store, exportability, exact consumer, rotation/revocation owner, and change evidence. The ceremony must also confirm that the value is absent from source, shell history, Terraform state, tickets, logs, and receipts.

​
The platform delegation

The executable manifest contains the exact native target, authentication references, action mappings, assertions, refusal allowlist, release semantics, connector generation, and receipt-key reference. The authorization ceremony is:
  1. Phosra and the platform finalize the executable manifest.
  2. The platform reviews its canonical bytes and digest.
  3. The platform issues a delegation binding that digest, target, scope, generation, and delegated receipt public key.
  4. The platform signs the delegation with a key published through the agreed trust process.
  5. The signed delegation digest is bound back into the manifest.
  6. Secret values are provisioned through protected Cloudflare or CI paths.
  7. The route is registered paused in staging before it is enabled.
Changing executable behavior requires a new digest, platform review, delegation, signature, and generation. A connector operator cannot expand its own authority by editing the manifest.

​
Credential-free evaluation

The Discord-like candidate can be validated locally without Cloudflare or platform credentials:
These commands validate bundle integrity, translation and read-back logic, strict conformance vectors, and Worker bundling. They do not authenticate to Cloudflare, create a route, contact Discord, validate Access/Tunnel, or prove native platform behavior.

​
Staging conformance

Before production, prove each leg separately:
  1. The private adapter passes direct platform-owned apply, read, and release tests.
  2. Unauthorized Access requests fail before origin execution.
  3. The connector Worker and Durable Object migrations exist in the intended staging environment.
  4. A signed Policy Inbox delivery reaches the exact registered route.
  5. Native GET returns effective state for the same binding, generations, and desired-state digest.
  6. Exact replay creates no second side effect.
  7. Stale generations and cross-binding requests fail closed.
  8. Approved refusals remain bounded results rather than retries.
  9. Two sequential partial updates preserve controls omitted from the second update.
  10. Release removes only the Phosra source and independent read-back observes it.
  11. Delegation revocation, Access rotation, origin outage, retry, DLQ/manual recovery, and emergency pause work.
  12. Receipts verify under only the delegated public key and declared evidence ceiling.
Passing local vectors is necessary but does not prove these live staging legs.

​
Evidence: two receipts, multiple states

Keep transport and native evidence separate: As of September 1, 2026, the production Policy Inbox health surface is live, and the Notflix and Bloxby declarative connectors are staging evaluations. The current declarative connector build itself supports staging authority only. The connector and Link execution packages are private reference implementations, not a public self-serve production service, and the current FamilyPlan bridge prepares apply work only. The current Policy Inbox retains a platform-delegated native observation, but the current Link handoff does not yet convert that wrapper into the complete Link-format receipt required for independent platform_verified evidence. The current synchronous path also does not issue a separately versioned, Cloudflare-signed delivery receipt. Those are remaining protocol and productionization tasks. They cannot be fixed by relabeling delivery as enforcement. The candidate and staging artifacts are not production bundles with placeholders. Before credentials or deployment, a production-capable artifact audit must prove trust bootstrap, environment isolation, protected checkpoints, dispatcher/reconciler operations, managed key lifecycles, canonical observe and release wiring, schema migrations, direct native and Access-rejection tests, signed digests, canary, monitoring, emergency pause, and rollback. Under the current platform_delegated_observed evidence ceiling, do not use the unqualified word “enforced.” Report delivery and native read-back separately for each control, including any refused, unsupported, degraded, or pending action.

​
Disconnect and release

Disconnect has two clocks:
  1. Phosra can revoke the grant immediately, making the link locally terminal and preventing new authorized writes.
  2. Platform cleanup completes only when a signed, generation-fenced release is delivered, the platform removes only the Phosra source, and native read-back observes the result.
The platform must choose what effective value follows release: restore a saved pre-link value, leave the last value, apply a platform default, or recompute from remaining sources. Blindly restoring a snapshot can overwrite later teen, guardian, platform, regulatory, or other-manager changes. Retain enough tombstone and idempotency state to reject stale queued deliveries before destroying the binding. If the native service is unavailable, the user may see “disconnected” immediately while platform cleanup remains release_pending; do not report native release as complete before read-back.

​
Definition of done

A production platform integration is complete only when all of these are true:
  • product semantics and every control mapping are approved;
  • native guardian/teen consent and opaque binding are live;
  • the private adapter calls the real command service and independent read model;
  • idempotency, replay, generations, source precedence, refusals, and release are tested;
  • the control schema, native normalizer, compatibility policy, and multi-action transaction model are versioned and migration-tested;
  • Cloudflare Access/Tunnel or another approved last hop is configured with isolated environments and protected secrets;
  • the platform signed the exact executable delegation;
  • Policy Inbox and connector registration are activated through approved operations;
  • native read-back and receipt verification pass in staging and production;
  • the platform UI shows managed status, refusal, review, and disconnect; and
  • security, privacy, legal, abuse, support, incident, rotation, retention, and rollback owners have approved activation.
A repository commit, dry-run, Worker upload, health check, 202, Queue delivery, or passing mock is not this definition of done.

​
Bot-oriented handoff

The installable agent playbook lives at docs/skills/phosra-cloudflare-platform-onboarding/SKILL.md in the Phosra repository. It requires an agent to maintain an evidence ledger, distinguish evaluation from production, stop before unauthorized credentials or external changes, and report the exact platform-owned next step.