Rights Layer Specification

Introduction

Status: Draft v0.1.0 — This section is informative.

1. Motivation

Modern society manages rights everywhere, but nowhere in the same way. Government registries, healthcare licensing systems, construction permit systems, education credential records, real-estate registries, insurance policy administration systems, financial account systems, software licence managers, membership systems, subscription platforms, share registers, copyright and patent registers, national qualification registers, and driving licence registers each hold rights — yet each holds them in its own fragmented, domain-specific data model.

The consequences are familiar:

• The same underlying question — does this Subject hold this Right, and may they exercise this Action here and now? — must be re-modelled, re-asked, and re-answered differently in every domain.
• Rights that cross domains (a professional qualification used in a permit application; an insurance claim grounded in a property right) require ad hoc, pairwise translation between models.
• Verification paths back to the authoritative record are inconsistent or undocumented, so consumers either over-trust copies or rebuild verification from scratch per domain.
• History — how a right came to exist, was suspended, reinstated, exercised — is recorded unevenly, when it is recorded at all.

Rights Layer does not replace any of these systems. Each domain keeps its own system of record, its own law, its own processes. Rights Layer defines a common conceptual layer for expressing rights: a shared vocabulary and structure in which any right, in any domain, can be described, referenced, and exchanged, while authority remains where it already is.

2. The Central Insight

Across all of the domains above, the same structure recurs. Rights Layer makes it explicit:

1. Rights are binary in existence. A Right exists or does not exist. Rights Layer does not grade, weight, or subtype Rights by industry.
2. Variety lives in Actions. A land ownership right and a driving licence are both simply Rights; what differs is what can be done — use / sell / lease / build versus drive. Kinds exist at the level of Actions, not at the level of Rights.
3. Eligibility is per-Action and atomic. Requirements attach to the specific Action being exercised — not to the Right as a whole and not to the Subject as a permanent status. Each Eligibility is exactly one requirement; an Action needing several requirements has several Eligibilities. The same Right may impose different Eligibilities on examine and on operate.
4. Requirements are answered from outside. Each Eligibility receives at most one Eligibility Response — a Boolean, bound one-to-one to its Eligibility, verifiable in authenticity and integrity. Evaluation happens outside the layer, at the issuer of the Response. The core model has no Context or other container of evaluation material, and no intermediate value: an Eligibility with no Response is simply unanswered.
5. Decisions are established, never graded. A Decision for an Action is established only when every Eligibility of that Action has exactly one verifiable Response and all Responses are true. There is no permit/deny/indeterminate result and no negative Decision.
6. Everything is grounded in Sources. Every Right references at least one Source — statute, contract, registration, judgment, administrative act, inheritance, qualification, ordinance — in the system of record where it lives. Rights Layer references Sources; it never restates or replaces them.
7. Everything is explained by Events. Facts about a Right and its exercise are recorded as append-only Events. The current state of a Right is derived from its history; the present is explained, not asserted.

This chain — Source grounds Right, Right has Actions, Actions carry Eligibilities, Eligibilities are answered by verifiable Boolean Responses, all-true Responses establish Decisions, established Decisions precede Exercises, everything leaves Events — is developed formally in the Conceptual Model.

3. Scope

In scope

• A normative vocabulary for rights across domains (Terminology).
• A normative conceptual model relating Subject, Object, Right, Source, Action, Eligibility, Eligibility Response, Evidence, Evidence Source, Authority, Decision, Exercise, and Event (Conceptual Model).
• A normative abstract data model with a canonical JSON serialization and a machine-readable schema (Data Model).
• Reference structures that point into systems of record: Source references, Evidence Sources, Proof References, Agreement References.
• Design principles that keep the layer neutral and stable (Core Principles).
• Informative guidance: architecture of the layer, an illustrative API sketch, security and privacy considerations, and worked examples.

Out of scope

Rights Layer is descriptive, not enforcing. The following are deliberately out of scope; they belong to the systems and frameworks that adopt the layer:

• Enforcement. Rights Layer does not authorize requests or enforce decisions. An expression describes; it does not compel.
• Evaluation of requirements. How an Eligibility is judged — evaluation algorithms, evaluation data, and the collection of evaluation material — happens outside the layer, at the issuer of the Eligibility Response. The core model contains no Context or other container of evaluation material.
• Rule engines and workflows. Rights Layer defines no rule language, no evaluation engine, and no workflow or approval process.
• Transport, storage, and interface. API transports, database structures, and user interfaces are deployment choices; conformance is defined only over expressions.
• Identity proofing and authentication. Rights Layer identifies entities by URI but does not authenticate anyone or verify control over an identifier. Authentication products, cryptographic algorithms, and signature schemes are never mandated; verifiability of Responses is required, the mechanism is not.
• Reliance frameworks. Which issuers, Authorities, and Evidence Sources a deployment relies on, and on what basis, is a matter for deployments and their governing rules.
• Legal and institutional effect. A Rights Layer expression is a description of rights, not a legal instrument. It creates, transfers, and extinguishes nothing. An established Decision is not an administrative disposition, a contract formation, or a system access grant; how a Decision feeds institutional processes is outside the layer.
• Operation after the facts. How Exercises are actually performed, billing, and audit procedures belong to the adopting institutions and systems; the layer records facts about them as Events.
• Vendor, product, and technology choices. The specification is vendor-neutral, product-neutral, implementation-neutral, and technology-neutral (Principle P1 in Core Principles).

4. Intended Audiences

• System designers building or integrating systems that hold or consume rights, who need a common structure to express them.
• Registries and other operators of systems of record, who remain authoritative and can expose their records as Rights Layer expressions without ceding authority.
• Policy makers who need a domain-independent vocabulary for how rights, eligibility, decisions, and exercise histories relate.
• Standards implementers mapping Rights Layer to existing standards for identifiers, serialization, or policy expression, or defining domain profiles.

5. How to Read This Specification

Document	Status	What it gives you
Introduction (this document)	Informative	Motivation, scope, audiences
Core Principles	Normative	The principles P0 to P10 governing the design
Terminology	Normative	Definitions of every core term
Conceptual Model	Normative	How the terms relate; diagrams; design positions
Data Model	Normative	Entities, properties, JSON serialization, conformance
Architecture	Informative	The layer’s position between systems of record and consumers
Example API Draft	Informative (non-normative)	An illustrative interface sketch
Security Considerations	Informative except RFC 2119 keywords	Threat-model-style guidance for deployments
Privacy Considerations	Informative except RFC 2119 keywords	Personal-data guidance for deployments
Examples Guide	Informative	Map of the worked examples and how to validate them
Comparison with Existing Standards	Informative	Relationship to existing open standards
RFC Process	Process	How the specification changes
License Guide	Process	Terms of use of the specification

Suggested reading order. Read Core Principles and Terminology first; they are short and everything else depends on them. Then read the Conceptual Model for the structure, and the worked driving licence example alongside the Data Model to see the structure made concrete. The remaining documents can be read as needed.

Conformance is defined only in the Data Model, and only over expressions — never over products, APIs, or architectures.

This site is open source. Improve this page.