Pilot-readiness checklist

Use this checklist after your local and sandbox evaluation works and before proposing a design-partner pilot.

This is not a production-network or certification checklist. Phosra does not claim a public production OCSS federation, current accreditation, current certification, or a generally available production receipt rail. Hosted routing, broader production adapters, and certification pathways remain roadmap.

1. Define the pilot boundary

  • Name one child-safety workflow and one accountable owner.
  • Identify the policy input, local decision point, expected result, and rollback path.
  • Separate synthetic test data from any proposed real-data handling.
  • Document which decisions stay local and which future hosted capabilities the design assumes.
  • Agree on measurable pilot success and stop criteria.

2. Reproduce the available evidence

  • Run local SDK or gatekeeper evaluation.
  • Run the documented no-signup sandbox flow.
  • Inspect the public rule and compliance registries.
  • Inspect sample signed artifacts and record exactly which test key and payload were verified.
  • Do not describe signature presence as independent verification or downstream enforcement.

3. Lock down test credentials

  • Keep phosra_test_… credentials out of source control.
  • Store sandbox signing seeds in a secret manager or local ignored file.
  • Never copy a sandbox root, synthetic DID, demo child, or reference provider into a production trust decision.
  • Rotate any credential that was printed, committed, or shared outside the pilot team.

4. Review data handling

  • Minimize child and family data before it reaches the integration.
  • Define retention and deletion behavior.
  • Record each processor and data region used by the pilot.
  • Confirm authorization, age-assurance, parental-consent, and incident-response responsibilities with your legal and security teams.
  • Treat Phosra documentation as implementation guidance, not legal advice or a compliance determination.

5. Exercise failure modes

  • Invalid or expired credentials fail closed.
  • Unknown rule categories are rejected.
  • Network timeouts have bounded retries and do not silently allow a restricted action.
  • Revocation and disconnect paths are idempotent.
  • Logs exclude secrets and unnecessary child data.
  • A rollback returns the product to its pre-pilot behavior.

6. Record roadmap dependencies

Explicitly mark any dependency on:

  • hosted decision routing between verified participants;
  • broader production receipt-rail availability;
  • an adapter not included in the current SDK evaluation;
  • an independent accreditation or certification pathway; or
  • an independent governance decision.

Those capabilities are not converted into current availability by joining the beta.

7. Apply for the design-partner beta

Share:

  1. the bounded workflow;
  2. your architecture and data-flow diagram;
  3. the local and sandbox evidence you reproduced;
  4. pilot success and stop criteria; and
  5. the roadmap dependencies you identified.

Apply through the design-partner beta or email [email protected].

Before any later production launch

A later production launch would require a separately documented, dated release boundary: published production endpoints where applicable, an explicit trust-root distribution process, security and privacy review, operational support terms, and any independent governance or certification decisions the design relies on. None of those should be inferred from sandbox fixtures, sample artifacts, or design-partner participation.