Rights Layer Specification

Core Principles

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

These principles govern the design of Rights Layer and all future changes to it. A proposed change that violates a principle MUST be rejected or the principle itself MUST first be amended through the RFC Process.

P0. Extensibility without interpretive ambiguity

A standard layer SHALL preserve extensibility while eliminating interpretive ambiguity in its core concepts.

The layer must leave room for extension: profiles, extension properties, and domain vocabularies are welcome and expected. The layer must not leave room for interpretation of its core concepts: the same core term MUST NOT mean different things to different implementers. Every core concept has a single, explicit responsibility.

Consequences of this principle in the current model:

• The core contains no Context and no other catch-all container for arbitrary evaluation material, environment data, or “judgment inputs”. Such containers are interpreted differently by every implementer and blur authenticity and safety boundaries. Gathering evaluation material and evaluating requirements are responsibilities outside the layer.
• An Eligibility is exactly one requirement — never a set, group, state, process, or rule engine.
• The only externally presented value is the Boolean Eligibility Response, bound one-to-one to its Eligibility, with no intermediate values in the core.
• A Decision has one meaning only: all Eligibility Responses for the Action exist, are verifiable, and are true.

P1. Neutrality

Rights Layer is vendor-neutral, product-neutral, implementation-neutral, and technology-neutral.

The specification MUST NOT depend on, assume, or privilege:

• any specific company or vendor;
• any specific product or service;
• any specific cloud platform;
• any specific database or storage technology;
• any specific authentication or identity technology;
• any specific blockchain or distributed-ledger technology;
• any specific cryptographic or security technology.

Implementations MAY use any of these. Reference implementations or product integrations, if they ever exist, are examples — the specification MUST never be rewritten around them.

P2. A layer, not a system of record

Rights Layer expresses rights; it does not manage them. Every domain keeps its own system of record (registries, licence databases, policy systems, share registers). Rights Layer defines references into those systems, never copies that claim authority over them.

P3. Rights are existence; kinds are Actions

A Right is treated as existing or not existing. Rights Layer does not build industry taxonomies of rights. Domain variety is expressed through Actions and their Eligibility.

P4. Eligibility is per-Action, atomic, and externally answered

Requirements attach to what is being exercised, not to the right as a whole and not to the holder as a permanent status. An Action has zero or more Eligibilities; each Eligibility is exactly one requirement. Each Eligibility is answered by at most one Boolean Eligibility Response, presented from outside the layer, verifiable in authenticity and integrity. A Decision for an Action is established only when every Eligibility has exactly one verifiable Response and all are true. How requirements are evaluated is outside the layer.

P5. Grounded in Sources

Every Right references at least one Source (statute, contract, registration, judgment, administrative act, inheritance, qualification, ordinance, …). Rights Layer defines the reference structure, not the content of sources.

P6. History explains the present

Facts are recorded as append-only Events. The current state of a Right is derived from its history. Corrections are new Events, not rewrites.

P7. Descriptive, not enforcing

Rights Layer does not authenticate subjects, authorize requests, or enforce decisions. It provides the common vocabulary in which such systems can describe what they do.

P8. Minimal invention, maximal reuse

Where an existing open standard already solves a problem (identifiers, serialization, vocabulary mapping, policy expression), Rights Layer reuses it and remains compatible with it. New constructs are introduced only where no suitable neutral standard exists. See Comparison with Existing Standards.

P9. Openness

The specification is developed in public, versioned openly, and licensed for free use by anyone (see License Guide). It is a public standard — not a product, a library, or a service.

P10. Extensibility without fragmentation

Domains MAY extend Rights Layer with domain-specific vocabulary (via extension points and profiles) but MUST NOT change the meaning of core terms. A conforming expression remains interpretable by any consumer that knows only the core specification.

This site is open source. Improve this page.