The standard
POSS defines privacy as an architectural property, not a contractual one. Compliant software does not merely promise to protect data — it is structurally incapable of surveilling, exfiltrating, or monetizing it.
Design philosophy
not the promise of secrecy. The software should have no mechanism to observe the user in the first place.
not the location of storage. Storing data domestically while depending on foreign proprietary software is relocated dependency, not sovereignty.
The ten principles
The software must not rely on privacy policies or legal terms to protect data. Unauthorized access must be technically impossible: data is processed locally by default, and any sync is encrypted with keys only the user holds.
How to verify Inspect network traffic and source for vendor access paths; confirm keys are generated and stored locally, never transmitted.
The software must run self-hosted with no vendor accounts or API keys. Any managed version may exist but must offer no functional advantage over self-hosting.
How to verify Deploy on a clean machine from the published docs alone; confirm full feature parity with no vendor accounts.
Storing data in the right country is not sovereignty. Users must be able to inspect, export, migrate, and operate the full stack in open formats without vendor permission.
How to verify Export all data in open formats and re-import on different infrastructure with no vendor assistance.
No core function may depend on a single vendor. Models, databases, and providers must be swappable through open interfaces — including open-weight AI models, never API-only proprietary ones.
How to verify Swap the AI model, database, and host for alternatives and confirm core features still work.
No data leaves the software without explicit, per-category opt-in consent, and declining must not degrade it. No remote configuration, A/B testing, or deceptive design.
How to verify Monitor traffic for unauthorized connections; decline all telemetry and confirm no functionality is lost.
All code needed to build and run the software must be public under an OSI-approved license. Usage-restricting licenses (SSPL, BSL, Hippocratic) do not qualify.
How to verify Confirm the license is OSI-approved and build the software from the published source.
Every feature — including admin, security, and compliance features — ships under the same open license. Commercial offerings around the software are encouraged; proprietary features are not.
How to verify Compare community and enterprise feature lists for parity; confirm no license check gates functionality.
Builds must be bit-for-bit reproducible, dependencies pinned with cryptographic checksums, a Software Bill of Materials published, and release artifacts signed.
How to verify Build twice from the same commit and compare checksums; verify signatures and the published SBOM.
All external interfaces must use open, documented formats and standards — open data formats, OpenAPI, and standard authentication (OAuth 2.0, OpenID Connect, SAML). No proprietary lock-in.
How to verify Export data and open it with standard tools; test APIs against their OpenAPI specification.
The architecture must not be built to enable mass surveillance, behavioral manipulation, or automated discrimination. AI components publish Model Cards; a Responsible Use Policy ships with the software.
How to verify Review features against known surveillance and manipulation capabilities; confirm Model Card and Responsible Use Policy exist.
Compliance
| Level | Verification | What it means |
|---|---|---|
| POSS-Core | Self-assessed | The publisher self-attests against all ten principles and publishes the completed checklist. No independent verification — not for procurement that requires audited compliance. |
| POSS-Certified | Foundation-audited | An independent audit against all ten principles: source review, build verification, network analysis, and functional testing. Annual re-audit. |
| POSS-Auditor-Authorized | Third-party verified | Certified by an independent firm the foundation has licensed, trained, and samples annually — for certifications within a given jurisdiction or at portfolio scale. |
A foundation audit (POSS-Certified) takes four to eight weeks and costs $2,500–$10,000 depending on codebase size. Individual certifications — Developer, Architect, and Auditor — are defined in the specification; a dedicated certification page follows.
Contributing
Anyone can propose a change using the RFC template on GitHub. Proposals get a 30-day public comment period, a Technical Steering Committee review, and — for normative changes — a community vote, before the Board ratifies. Changes ship with 90 days' notice. Community calls are held on the first Tuesday of each month at 14:00 UTC.