OpenReason Protocol Specification
ORP v0.3
The OpenReason Protocol (ORP) is a standardized schema for documenting, sharing, and challenging the reasoning behind consequential decisions in policy, AI, and democratic governance — and, since v0.3, for describing a verifiable data product a machine can check and enforce.
Current Version: v0.3 (implemented in orp-validator ≥ 0.5.0)
Previous Versions: v0.2 (2026-04-08), v0.1
An ORP-compliant document is not a static report. It is a simulatable object: a structured representation of reasoning that any party can inspect, fork, and re-run with different assumptions to produce comparable outputs.
v0.3 is implemented in
orp-validator≥ 0.5.0. It keeps everything on this page and adds a machine-verifiable layer — cryptographic attestation, profiles, trust tiers, an enforceable usage policy, derivation lineage, and usage records — so an ORP document can also be a verifiable data product on agent-to-agent rails. The full normative text is in the repo (docs/specs/ORP_V0.3_SPEC.md); the reader’s guide is under Data Products.
Migrating from v0.2
v0.3 is additive and backward-compatible. A v0.2 document becomes a valid v0.3 ORP-Policy document by one change:
orp_version: "0.3" # was "0.2"
profile: ORP-Policy # recommended: keeps the L2 + L3 requirement explicitNothing was removed or made stricter; compliance_level still validates (v0.3 additionally reports a trust_tier). Everything v0.3 adds is optional in ORP-Core. See Data Products → Overview.
What’s New in v0.2
- Post-hoc reconstruction support — Retrospectively document decisions without original decision-making records
- Domain-specific extensions — ai-training, governance, policy extensions for specialized fields
- Flexible schema validation — Accepts real-world structural variation while maintaining required field rigor
- Enhanced confidence levels — 7-point scale for nuanced uncertainty communication
- JSON-LD support — Semantic web integration for cross-document querying (see JSON-LD Format)
Backward Compatibility: All v0.1 documents remain valid in v0.2
Design Principles
- Layered — Each layer is independently useful and auditable
- Machine-readable — Structured for both human reading and automated processing
- Forkable — Any compliant document can be forked, modified, and published as a derivative
- Diff-able — Differences between original and fork are explicit and locatable
- Extensible — Core schema + domain-specific extensions for specialized needs
Document Structure
An ORP-compliant document consists of a header block plus layers. The five core layers below are the v0.1/v0.2 shape; v0.3 adds an optional attestation block and Layers 4–6 extensions, all additive.
ORP Document
├── Header (Required metadata; v0.3 adds `profile`)
├── attestation (v0.3, optional — cryptographic signature; see Data Products)
├── L1: Data Provenance (Required; v0.3 adds legal / access / freshness / reach fields)
├── L2: Consequence Simulation (required in ORP-Policy)
├── L3: Empathy Mapping (required in ORP-Policy)
├── L4: Accountability Ledger (v0.3 adds signed usage_records)
├── L5: Lineage (fork registry + v0.3 derivation graph)
└── L6: usage_policy (v0.3, optional — enforceable usage terms)v0.3 additions
v0.3 keeps every layer above and layers a machine-verifiable envelope on top. Each is documented in full under Data Products:
- Attestation — a detached Ed25519 signature a reader verifies offline (AdCP #4441-aligned)
- Profiles — ORP-Core / ORP-Policy / ORP-Ads / ORP-AI (validate with
--profile) - Trust tiers —
self_declared→attested→verified→full, replacing compliance levels as the v0.3 vocabulary - Usage policy (L6) — an enforceable ODRL profile with a reference evaluator
- Lineage (L5) — a derivation graph so derivatives carry ancestors’ constraints
- Usage records (L4) — a rail’s signed receipt as proof-of-use
The complete normative v0.3 text is in the repo (docs/specs/ORP_V0.3_SPEC.md).
Header Block
Every ORP document begins with structured metadata:
orp_version: "0.2"
document_id: "unique-identifier-001"
title: "Human-Readable Policy Title"
domain: "policy" # or: ai-training, governance, research, other
authors:
- name: "Author Name"
role: "author" # or: contributor, reviewer, analyst, reconstructor
affiliation: "Organization Name" # optional
created: "2026-01-01"
last_modified: "2026-01-01"
status: "draft" # or: open-for-comment, ratified, superseded
compliance_level: "ORP-Full" # or: ORP-Standard, ORP-Basic, ORP-PostHoc
summary: |
Plain language description of what this document proposes,
in 3-5 sentences. Written for a general audience.Optional Header Fields (v0.2)
post_hoc: true # v0.2: Flags retrospective reconstruction
profile: ORP-Policy # v0.3: ORP-Core | ORP-Policy | ORP-Ads | ORP-AI (default ORP-Core)
extensions: # v0.2: Domain-specific extensions
- "orp-ai-training-v1"
- "orp-safety-v1"
forked_from: "parent-document-id" # If this is a fork
license: "CC-BY-4.0" # Licensing terms
contact: "[email protected]" # Contact informationpost_hoc flag: Set to true when reconstructing decisions from published sources where original decision-making records are unavailable.
extensions: Declares domain-specific extensions used (e.g., orp-ai-training-v1 for AI training dataset documentation).
Layer 1: Data Provenance
Purpose: Document every dataset used in the reasoning, including how it was collected, cleaned, and what was excluded. Bias lives in data, not algorithms.
Required Fields Per Dataset
l1_data_provenance:
- dataset_id: "enrollment-2024"
name: "School Enrollment Data 2024"
description: "What this dataset contains and why it was used"
source: "government | academic | commercial | synthetic"
collection_method: "How data was gathered"
date_range: "2024-01-01 to 2024-12-31"
geographic_scope: "Countries, regions, municipalities"
inclusion_criteria:
description: "What was included and why"
exclusion_criteria:
- "What was excluded and explicit justification"
cleaning_decisions:
- "What was done, why, and what alternatives were considered"
synthetic_elements:
present: false
# If true: what was synthesized, how, and with what assumptions
known_limitations:
- "Explicit statement of what this dataset does not capture well"
access:
public: true
url: "https://data.gov/dataset-id" # if public
attested_by:
- name: "Data Steward Name"
role: "data_manager"
date: "2026-01-15"
statement: "I attest this description is accurate"Key Principle: Every exclusion must be justified. Every cleaning decision must explain alternatives considered. Every limitation must be explicit.
Layer 2: Consequence Simulation
Purpose: Model policy outcomes with explicit assumptions, scenarios, and sensitivity analysis. Make the reasoning simulatable by others.
Structure
l2_consequence_simulation:
affected_population:
description: "Who is affected by this proposal"
size_estimate: "Approximate number"
variables:
independent:
- variable: "funding_increase_percent"
description: "What this variable represents"
range: "0% to 30%"
default_value: "15%"
dependent:
- variable: "class_size"
description: "What we're measuring"
unit: "students per classroom"
model:
type: "Linear regression | Agent-based | System dynamics"
assumptions:
- assumption: "Teacher hiring follows funding linearly"
basis: "Historical data 2010-2024"
sensitivity: "High - main driver of outcomes"
scenarios:
- scenario_id: "baseline"
name: "Current Funding"
description: "No change from 2024 levels"
variable_values:
funding_increase_percent: "0%"
outcomes:
class_size: "24.5"
- scenario_id: "moderate"
name: "15% Increase"
description: "Proposed funding increase"
variable_values:
funding_increase_percent: "15%"
outcomes:
class_size: "21.2"
primary_scenario: "moderate"Key Principle: All assumptions must be explicit and testable. Scenarios should span the range of plausible outcomes.
Layer 3: Empathy Mapping
Purpose: Map all stakeholders, test impacts on minorities, assess net welfare with confidence levels. Make invisible groups visible.
Structure
l3_empathy_mapping:
stakeholder_map:
- stakeholder: "Students"
description: "How they're affected"
estimated_population: "5.2 million"
relationship_to_proposal: "Primary beneficiaries"
impacts_by_scenario:
- scenario_id: "moderate"
direction: "positive | negative | mixed | neutral"
magnitude: "Description of impact"
minority_stress_test:
description: "Testing impacts on underrepresented groups"
groups_tested:
- group: "Rural school districts"
scenario_tested: "Moderate increase with uniform distribution"
outcome: "Receives proportionally less benefit"
mitigation: "Consider rural weighting factor"
unresolved_impacts:
- "Long-term effects we haven't modeled"
- "Second-order consequences we're uncertain about"
net_welfare_assessment:
methodology: "How we assessed overall welfare"
conclusion: "Net positive across all scenarios"
confidence: "medium | high | low"
confidence_basis: "Why we have this confidence level"Key Principle: No affected party is invisible. Minorities must be explicitly tested, not averaged away.
Layer 4: Accountability Ledger
Purpose: Track every methodological decision. Who decided what, when, why, and what sections were affected.
Structure
l4_accountability_ledger:
entries:
- timestamp: "2026-02-15T10:30:00Z"
decision: "Switched from linear to log model for income effects"
decision_maker: "Lead Analyst Name"
role: "senior_analyst"
basis: "Log model better fits historical data (R² = 0.89 vs 0.72)"
affected_sections: ["l2_consequence_simulation"]
- timestamp: "2026-02-20T14:00:00Z"
decision: "Excluded private schools from dataset"
decision_maker: "Data Manager Name"
role: "data_steward"
basis: "Data not available from private institutions"
affected_sections: ["l1_data_provenance"]Key Principle: Anonymous decisions are unaccountable decisions. Every choice that affects outcomes must have a name attached.
Layer 5: Fork Registry
Purpose: Track document lineage, enable systematic comparison of alternatives, invite forking.
Structure
l5_fork_registry:
this_document:
allows_forking: true
license: "CC-BY-4.0"
fork_invitation: "We encourage forking to test alternative assumptions"
known_forks:
- fork_id: "alt-funding-model-001"
title: "Alternative Funding Model (Progressive)"
authors: ["Contributor Name"]
created: "2026-03-01"
key_differences:
- "Uses progressive rather than flat funding increase"
- "Models teacher retention effects"
url: "https://example.org/fork-001.yaml"
responses_to_forks:
- fork_id: "alt-funding-model-001"
response_type: "acknowledged | adopted | rejected"
reasoning: "Interesting approach but requires data we don't have"
date: "2026-03-05"Key Principle: Forking is not criticism—it’s collaboration. The best proposals emerge from systematic comparison of alternatives.
Compliance Levels
ORP-Basic (Layer 1 only)
Minimum viable transparency. Requires only data provenance. Useful for:
- Initial documentation
- Low-stakes decisions
- Resource-constrained contexts
ORP-Standard (Layers 1-3)
Adds consequence simulation and empathy mapping. Required for:
- Policy proposals affecting >1000 people
- Decisions with distributional impacts
ORP-Full (All 5 layers)
Complete protocol with accountability and forking. Recommended for:
- High-stakes policy decisions
- Contested proposals with multiple alternatives
- Long-term decisions affecting future generations
ORP-PostHoc (v0.2)
Retrospective reconstruction when original records unavailable. Requires:
post_hoc: trueflag in header- Author role
analystorreconstructor - L1 with accountability gaps documented
- L4 entries marked as reconstructed
Use for: AI training datasets, historical policy analysis, published research reconstruction
See AI Training Examples for ORP-PostHoc demonstrations.
Validation
All ORP documents must validate against the JSON Schema:
- v0.3 documents:
schemas/orp-v0.3-core.schema.json+ a profile overlay (orp-v0.3-policy|ads|ai) - v0.2 documents:
schemas/orp-v0.2.schema.json - v0.1 documents:
schemas/orp-v0.1.schema.json(still supported)
Validate using CLI:
orp validate your-document.yaml
orp validate segment.yaml --profile ORP-Ads # v0.3: pick a profile; reports tier
orp conform # v0.3: run the conformance suiteOr via REST API:
curl -X POST https://api.publicreasonproject.org/api/v1/validate \
-H "Content-Type: application/json" \
-d '{"document": "orp_version: 0.2\n..."}'The validator automatically detects version from orp_version field.
Next Steps
- See examples - Real-world ORP documents
- Read the philosophy - REE framework
- Choose compliance level - Which level is right for you?
- Get started - Install the validator
Full Specifications
The complete, authoritative specifications are maintained at: