OpenReason Roadmap
The planned development of OpenReason — from the core reasoning protocol, through tooling, to the machine-verifiable data-product layer and the agents that build on top.
This is a living document subject to OpenReason principles. If you disagree with the sequencing or priorities, open a discussion or fork it.
Two tracks, one object
Since v0.3, OpenReason serves two readers — people and machines — and the roadmap runs on two tracks that share the same object:
- Public reasoning — making it easy for humans to write, read, fork and challenge the reasoning behind decisions (the original civic mission).
- Data products — making an ORP document a verifiable passport a machine can check and enforce on agent-to-agent rails.
Phase 0 — Foundation Complete
Specification and philosophical foundation: ORP v0.1, the REE foundation, the governance model, and the first worked example (Danish Property Tax Reform, ORP-Full).
Phase 1 — Core Tooling Complete
The toolkit that makes ORP documents easy to produce, validate and compare.
- ORP v0.2 — post-hoc reconstruction, domain extensions, flexible schema
- CLI (
orp new / validate / check / diff) and the Python validator (pip install orp-validator) - REST API — api.publicreasonproject.org
- Documentation site and four worked AI-training-dataset analyses (ImageNet, LAION-5B, Common Crawl, Copilot)
Phase 2 — Machine-verifiable data products (v0.3) Complete
The layer that lets an agent or rail that has never met the publisher verify an ORP document, enforce what
may be done with the data, and prove use — without inventing new crypto. Shipped in orp-validator 0.5.0.
- Attestation — offline Ed25519 verification, AdCP #4441-aligned
- Profiles — ORP-Core / Policy / Ads / AI
- Trust tiers —
self_declared→attested→verified→full, with an accredited-verifier gate - Usage policy — an enforceable ODRL profile + reference evaluator
- Lineage — a derivation graph that carries ancestors’ constraints
- Usage records — a rail’s signed receipt as proof-of-use
- Conformance suite —
orp conform, gated in CI - Relicensed to Apache-2.0 — patent grant for a protocol others implement
Phase 3 — Developer experience Planned
Make ORP native to existing workflows, on both tracks.
- GitLab/GitHub integration — templates + CI that validates ORP compliance (and
orp conform) on merge - VS Code extension — schema-aware autocomplete, inline validation, profile/tier indicator
- ORP Registry + Viewer — a public, searchable index of documents and their forks; a clean reader UI
- Reference rail binding — a worked example of a rail verifying an ORP passport and emitting a usage record, alongside the AdCP alignment
- Accredited-verifier process — how a
verifierkey gets on the list for theverifiedtier
Phase 4 — Agent layer Planned
AI assistance that lowers the cost of producing high-quality ORP documents.
Agents assist, they do not attest. Anything an agent drafts must be reviewed and signed off by a human before a document reaches
attestedor above.
Provenance (L1), simulation (L2) and empathy-mapping (L3) drafting assistants; a conversational ORP assistant for non-technical authors; and a fork analyser that makes disagreement locatable.
Phase 5 — Domain packs Planned
Domain-specific profiles and methodology standards, backward-compatible with core ORP: ORP-Env, ORP-Econ, ORP-Health, ORP-Edu — and a flagship civic data pack applying the protocol to a real legislative corpus, with provenance attested and an interface for people and agents to inspect and improve what governs society.
What we are explicitly NOT building
How to influence the roadmap
This roadmap is itself an ORP-style document — it has assumptions and priorities, and it will be wrong about some things. The right response to disagreement is not a comment, it’s a fork: show your reasoning.
See the Contributing Guide for how to propose changes.
Resources
- Repository: gitlab.com/publicreason/orp
- Issue Tracker: gitlab.com/publicreason/orp/-/issues
OpenReason Roadmap — October 2026. Subject to ORP principles. Fork it.