PolicyStack v2: help us design the open privacy stack

[jamiedavenport]

PolicyStack v1 brought privacy policies and consent together in one typed, developer-owned framework. We’re now starting to explore what PolicyStack v2 should become—and we want to design it in the open with the people who may use, contribute to, and support it.

This is an early design process, not a release announcement. There is no committed roadmap or release date yet.

The direction

Our ambition is to build the leading open privacy and data-protection platform: simple enough for a hobby project and capable enough for a large, regulated organisation.

The current goals are:

1. Open and sovereign
   All product capabilities should be open source and self-hostable. Teams should control their own configuration, privacy records, and operational data. We are not planning a separate, closed-source Cloud product. Any future managed service should run the same software available to everyone.

2. End-to-end
   PolicyStack should address the complete privacy lifecycle: discovery, inventory, applicable requirements, policies, consent and preferences, enforcement, data-subject requests, audit evidence, and drift detection.

3. Language-neutral
   V2 should work across TypeScript, Python, Go, and other languages, including distributed and microservice architectures. The underlying model should be based on open schemas and protocols rather than tied to one build tool or language.

4. Progressively adoptable
   A small project should be able to start simply. A regulated organisation should be able to add governance, integrations, review, audit, and operational controls without moving to a different product.

5. Verifiable and trustworthy
   PolicyStack should expose where information came from, what was inferred, which rules were applied, when they were reviewed, and where human or legal judgement is still required. It should never imply that generated output guarantees compliance.

6. Extensible
   Jurisdictions, integrations, discovery sources, storage systems, enforcement points, and workflows should be extensible without forcing everything into the core project.

You can follow the emerging design in the v2 working document.

What has not been decided

Important questions remain open, including:

• Whether Apache-2.0 is still the right licence for v2
• The canonical model connecting systems, processing activities, policies, consent, rights, and evidence
• How jurisdiction coverage should be created and reviewed
• Which capabilities belong in the first v2 release
• How compatibility and migration from v1 should work
• Whether PolicyStack should eventually offer managed hosting

V1 remains supported, and its existing licence and compatibility commitments are unchanged.

We want your input

We would particularly like to hear:

• How do you manage privacy policies, consent, data-subject requests, and compliance evidence today?
• Where do your current tools or processes break down?
• What languages, frameworks, services, and deployment environments do you use?
• Which jurisdictions do you need to support?
• What self-hosting, security, governance, or data-residency requirements do you have?
• What would PolicyStack need to do before you could rely on it?
• What should we avoid building?

Please don’t post confidential, personal, or security-sensitive information in this public discussion.

Design partners and sponsors

We’re looking for design partners ranging from individual developers and small teams to organisations operating complex or regulated systems.

Design partners can help by sharing workflows and requirements, reviewing proposals, testing prototypes, and validating whether the resulting system works in practice.

We’re also looking for sponsors who want to fund development of an open privacy ecosystem. Sponsorship will support public work; it will not purchase private features or exclusive control over the roadmap.

If you’re interested, reply here or contact me directly at x@jxd.dev.

Contributors, privacy practitioners, lawyers, maintainers of related projects, and constructive sceptics are all welcome. The aim is to understand the real problems before committing to solutions.