Rights Layer Specification

Architecture

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

This document describes the architecture of the layer, not of any system. Rights Layer is a conceptual expression layer; it has no components, no runtime, and no deployment of its own. Every element named below is a role that some existing or future system may play — none is a product, and no specific vendor, product, cloud, database, authentication method, ledger, or security technology is assumed or required (Principle P1 in Core Principles).

1. Position of the Layer

Rights Layer sits, conceptually, between two things that already exist:

• Below: domain systems of record. Registries, licence databases, policy administration systems, share registers, permit systems. These are authoritative. They remain authoritative. Rights Layer never claims their authority (Principle P2).
• Above: consuming applications and services. Anything that needs to understand a right expressed by another domain: a permit application workflow, a claims process, a compliance check, a directory, a viewer.
• Beside: Response issuers. External entities that evaluate an Eligibility’s requirement — outside the layer, by whatever method they use — and present a verifiable Boolean Eligibility Response. An issuer may be a person, a legal person, a public body, an industry body, a system, an AI, a certification service, or any other identifiable entity.

Between them, Rights Layer defines only one thing: the expression — a document, conforming to the Data Model, that describes Rights, Actions, Eligibilities and their Responses, Decisions, Exercises, and Events, and that points back into the systems of record via references.

flowchart TD
    subgraph consumers [Consuming applications and services — role, not product]
        APP1[Permit workflow]
        APP2[Claims process]
        APP3[Compliance check / directory / viewer]
    end

    subgraph layer [Rights Layer]
        EXPR["Rights Layer expressions<br/>(Right, Action, Eligibility,<br/>Eligibility Response, Decision,<br/>Exercise, Event)"]
    end

    subgraph records [Domain systems of record — role, not product]
        REG[Registries]
        LIC[Licence databases]
        POL[Policy administration systems]
    end

    AUTH[Authority] -->|grants / attests| EXPR
    ISS["Response issuers — external role<br/>(evaluate requirements outside the layer)"] -->|present verifiable Boolean<br/>Eligibility Responses| EXPR

    REG -->|produce and ground| EXPR
    LIC -->|produce and ground| EXPR
    POL -->|produce and ground| EXPR

    EXPR -->|consumed by| APP1
    EXPR -->|consumed by| APP2
    EXPR -->|consumed by| APP3

    EXPR -.->|Source references, Evidence Sources,<br/>Proof References point back into| records

The dotted arrow is the heart of the architecture: expressions flow upward, but authority stays below, and every expression carries the references needed to walk back down.

The decision flow follows the same division of responsibility. For each Eligibility of an Action, a Response issuer evaluates the requirement outside the layer and presents a Boolean Eligibility Response, verifiable in authenticity and integrity. The expression records these Responses (and EligibilityResponseIssued Events); when every Eligibility of the Action has exactly one verifiable Response and all are true, a Decision is established and recorded (DecisionEstablished Event). Nothing in the layer evaluates anything: the layer records verifiable Responses and the establishment they add up to.

2. Deployment Topologies (all valid, none required)

Rights Layer is neutral about where expressions live and how they move. The following topologies are all valid; none is required, and none is privileged:

1. Embedded. A single system of record produces and consumes its own expressions internally — for example, to give its own records a uniform rights vocabulary. No exchange occurs at all.
2. Point-to-point exchange. Two parties exchange expressions directly — a licensing register answering a permit system, an insurer answering a claims processor — over any transport of their choosing.
3. Aggregated directory. An operator collects expressions from many producers into a directory or catalogue that consumers query. The directory holds expressions; it does not become a system of record, and the references inside each expression still point to the original authoritative systems.
4. Fully decentralized. Expressions are held by Subjects themselves, or distributed across many holders, with no central collection point. Verification still works, because each expression carries its own references back to the systems of record.

A deployment may combine topologies, migrate between them, or invent others. Conformance is defined only over expressions (Data Model, section 5); topology is invisible to conformance. In every topology, Response issuers remain external: wherever the expressions live, the evaluation of requirements happens outside them.

3. The Reference Chain

An expression is useful precisely because it does not stand alone. It points into systems of record at three levels:

• Source references. Every Right carries sourceRefs naming the Source(s) that ground it — the statute, contract, registration, judgment, administrative act, inheritance, qualification, or ordinance — with a reference locator into the system of record where the Source lives.
• Evidence Sources. Every piece of Evidence names, via evidenceSourceRef, the Evidence Source it came from — the registry, register, or record system that remains the system of record for that evidence.
• Proof References. Eligibility Responses carry — and Evidence and Events may carry — a Proof Reference describing how a party can verify them, in whatever manner the governing system provides — a registry lookup, a signed document, a paper record locator, or any other mechanism. No specific proof technology is assumed.

Together these form a chain that any consumer can follow from an expression back to the authoritative ground:

expression → Right → sourceRefs → Source → reference → system of record
expression → Evidence → evidenceSourceRef → Evidence Source
expression → Eligibility Response / Event / Evidence → Proof Reference → verification mechanism

Dereferencing behavior is out of scope (Data Model, section 1.4): how a reference is resolved — online lookup, offline record, manual inspection — is a deployment matter.

4. Verification Boundaries

An expression is a claim. Possessing a well-formed expression proves nothing by itself. The verification boundary of Rights Layer lies exactly at the reference chain:

• Inside the boundary (defined by this specification): the structure and vocabulary of the claim — what is being asserted, about whom, grounded in what, exercisable how, answered by which Responses.
• Outside the boundary (defined by deployments): whether the claim is true. Verification goes through Proof References to the authoritative Evidence Sources and systems of record, and through each Eligibility Response’s proof to its issuer: a Response must be verifiably attributable to its legitimate issuer and verifiably unaltered after issuance (authenticity and integrity), by whatever mechanism the deployment provides. Which issuers, Authorities, and Evidence Sources a consumer relies on, and how it authenticates its counterparties, are matters for the deployment’s own arrangements and are out of scope.

Rights Layer does not authenticate Subjects, authorize requests, or enforce Decisions (Principle P7). A deployment that needs those functions supplies them with mechanisms of its own choice — an authentication mechanism, an authorization mechanism, transport security — and can use Rights Layer vocabulary to describe what those mechanisms decided. See Security Considerations.

5. Roles, Not Products

For clarity, the roles used in this document:

Role	What it does	Examples of who might play it
System of record	Holds the authoritative facts of a domain	A land registry, a licence database, a policy administration system, a share register
Producer	Emits Rights Layer expressions grounded in a system of record	Often the system of record itself, or an adapter in front of it
Consumer	Reads expressions and follows references to verify	An application, a service, another domain’s system
Authority	Grants, attests, suspends, or revokes Rights, or participates in Sources, Eligibilities, Responses, Decisions, or Evidence (Terminology)	A legislature, court, agency, registrar, contracting party
Response issuer	Evaluates an Eligibility’s requirement outside the layer and presents a verifiable Boolean Eligibility Response	An authority, a certification service, a system, an AI, any identifiable entity
Evidence Source	Provides Evidence and remains its system of record	A register, an administration system
Directory (optional)	Aggregates expressions for discovery	Any operator, in topologies that want one

Any real system may play several roles at once. Nothing in this table names, requires, or excludes any product.

This site is open source. Improve this page.