> ## 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.
# Implement Phosra through Cloudflare
> The destination-platform handoff: what a Discord-like technology platform builds, what Phosra and Cloudflare supply, and how native read-back proves the result.
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.
```text theme={null}
Parent in Bark, Custo, or another authorized provider
-> Phosra Link: consent, grant, signed desired state
-> Cloudflare Policy Inbox: verify, fence, order, retry, route
-> declarative connector: approved control translation
-> platform-private adapter: apply, read back, release
-> native Family Center setting store
```
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
| Work package | Platform-owned work | What Phosra and Cloudflare remove |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Product semantics | Approve each control's meaning, values, dependencies, age/region rules, teen approval, safety floors, conflicts, release behavior, schema version, and multi-action atomicity. | A shared envelope and declarative mapping format avoids a partner-specific public API. |
| Account linking | Use the platform's native family approval and mint an opaque binding that only the platform can resolve. | Phosra carries the parent-provider grant; Cloudflare never needs the teen or household identity. |
| Native adapter | Add a private apply/read/release seam to the same service used by the native Family Center UI. | The platform does not run Phosra's orchestration, evidence store, retry system, or provider integrations. |
| Cloudflare route | Choose Access-protected HTTPS, optionally with Tunnel; deploy or approve the connector runtime and isolated state. | The reusable Worker supplies signature checks, strict schema, replay fencing, ordering, retries, read-back evaluation, and bounded receipts. |
| Authorization | Sign a connector delegation and manage the platform's delegation and receipt keys. | Phosra resolves trust and sends audience- and environment-bound signed delivery. |
| Product and operations | Show managed-by status, refusals, review/disconnect, support, incidents, and source precedence. | Phosra supplies provider-facing lifecycle status without replacing native product authority. |
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:
```text theme={null}
PATCH /internal/phosra/family-control-bindings/{opaque_binding}
GET /internal/phosra/family-control-bindings/{opaque_binding}
DELETE /internal/phosra/family-control-bindings/{opaque_binding}
```
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:
| Candidate action | Visible settings | Candidate native shape |
| ---------------------------------- | --------------------------------------------------------- | -------------------------------------------------------- |
| Mature sexual media filter | Friend DMs; other DMs | Two independent `block`, `blur`, or `show` postures |
| Graphic media filter | Friend DMs; other DMs | Two independent `block`, `blur`, or `show` postures |
| Server-member DM block | Allow DMs from other server members | One inverted boolean |
| Non-contact message-request filter | Filter messages from server members the teen may not know | One boolean with a possible DM dependency |
| Friend-request source control | Everyone; friends of friends; server members | Three booleans with a platform-approved combination rule |
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:
```text theme={null}
phosra-connector init
-> preflight
-> discovery-brief
-> freeze-map
-> platform review
-> brief or scaffold
-> untrusted local-candidate bundle
```
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:
```bash theme={null}
npm run -w @phosra/platform-connector-kit build
```
```bash theme={null}
node packages/platform-connector-kit/dist/workbench/cli.js --help
```
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](https://developers.cloudflare.com/cloudflare-one/access-controls/service-credentials/service-tokens/).
* **Cloudflare Tunnel, optional:** reaches a private origin through outbound
[`cloudflared` connections](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/).
* **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:
| Last hop | Current status | Use when |
| ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Access-protected HTTPS | Executable with the current connector | The native service can be reached at a protected hostname. |
| Access + Tunnel | Executable with the current connector | The native service should have no inbound public origin. |
| Same-account [Worker Service Binding](https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/) | Requires the reviewed connector-to-native bound-fetch seam | Both Workers are in one Cloudflare account and the platform wants no public hostname. |
| [Workers VPC](https://developers.cloudflare.com/workers-vpc/configuration/vpc-services/) | Beta and requires the same transport seam plus network review | The platform has approved VPC Service and Tunnel topology. |
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:
```bash theme={null}
npm run -w @phosra/policy-inbox-contract build
```
```bash theme={null}
node apps/declarative-connector-cloudflare/deployment/discord/validate-candidate.mjs
```
```bash theme={null}
npm test -w @phosra/declarative-connector-cloudflare -- \
--run test/discord-conformance-vectors.test.ts
```
```bash theme={null}
PHOSRA_HANDOFF_DRY_DIR="$(mktemp -d)"
npx wrangler deploy --dry-run \
--config apps/declarative-connector-cloudflare/deployment/discord/wrangler.jsonc \
--outdir "$PHOSRA_HANDOFF_DRY_DIR"
```
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:
| Evidence leg | Establishes | Does not establish |
| ------------------------ | ------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Policy Inbox accepted | A scoped, signed request passed Cloudflare ingress validation. | Connector delivery or native state. |
| Connector delivered | The registered private adapter received correlated work. | The effective account setting. |
| Platform native observed | The platform's effective-state model returned a correlated result. | Independent Link-format verification or user-visible confirmation. |
| Link-verified receipt | Phosra Link verified the complete platform receipt and authority binding. | A separately signed Cloudflare delivery attestation. |
| Native product observed | The authoritative platform surface matches the desired state. | Controls outside the approved capability set. |
As of September 1, 2026, the
[production Policy Inbox health surface](https://phosra-family-policy-inbox.ocss.workers.dev/health)
is live, and the
[Notflix](https://phosra-notflix-declarative-connector-eval.ocss.workers.dev/health)
and
[Bloxby](https://phosra-bloxby-declarative-connector-eval.ocss.workers.dev/health)
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.