Rights Layer Specification

Conceptual Model

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

Rights Layer defines a common conceptual layer for expressing rights across domains. It does not replace any domain’s system of record. It defines how the same underlying structure — a right, grounded in a source, exercised through actions whose eligibility requirements are answered by verifiable Boolean responses — can be expressed uniformly.

The governing design rule: the layer preserves extensibility while eliminating interpretive ambiguity in its core concepts. Every concept below has a single responsibility; nothing in the core is a catch-all.

1. The Central Chain

Every right, in every domain, follows the same conceptual chain:

flowchart TD
    S[Source<br/>根拠] --> R[Right<br/>権利]
    R --> A[Action<br/>行使事項]
    A --> EL["Eligibility 0..n<br/>適格要件"]
    EL --> ER["Eligibility Response 1:1<br/>適格要件応答"]
    ER --> D[Decision<br/>判定]
    D --> EX[Exercise<br/>行使]
    EX --> EE[Exercise Event<br/>行使イベント]
  1. A Source (statute, contract, registration, judgment, administrative act, inheritance, qualification, ordinance) grounds the existence of a Right.
  2. A Right exists or does not exist. It is held by a Subject, optionally in relation to an Object.
  3. A Right is exercised through one or more Actions. Domain variety lives here — kinds exist at the level of Actions, not Rights.
  4. Each Action carries zero or more Eligibilities. Each Eligibility is exactly one requirement — never a set, group, state, or evaluation process.
  5. Each Eligibility receives at most one Eligibility Response from outside Rights Layer: a Boolean, verifiable in authenticity and integrity. true means satisfied; false means not satisfied; no Response means unanswered. There is no third value.
  6. A Decision for the Action is established only when every Eligibility of that Action has exactly one verifiable Response and all Responses are true. One false, or one unanswered Eligibility, and the Decision is not established.
  7. An Exercise is the fact that the Action was actually performed after the Decision was established.
  8. Facts are recorded as Exercise Events, part of the append-only Event history that explains the present.

2. Eligibility, Response, Decision

The core evaluation structure, in detail:

flowchart TD
    R[Right] --> A[Action]
    A --> EA[Eligibility A]
    A --> EB[Eligibility B]
    A --> EC[Eligibility C]
    EA --> RA["Response A: true / false"]
    EB --> RB["Response B: true / false"]
    EC --> RC["Response C: true / false"]
    RA --> ANDall Responses = true
    RB --> AND
    RC --> AND
    AND --> D[Decision]
    D --> EX[Exercise]

3. Full Entity Relationships

flowchart LR
    subgraph existence [Existence]
        SRC[Source]
        AUTH[Authority]
        SUB[Subject]
        OBJ[Object]
        R[Right]
    end
    subgraph exercise_g [Exercise]
        ACT[Action]
        EL["Eligibility 0..n"]
        ER["Eligibility Response 1:1"]
        EV[Evidence]
        ES[Evidence Source]
        DEC[Decision]
        EX[Exercise]
    end
    subgraph history [History]
        EVT[Event]
        EE[Exercise Event]
    end

    SRC -->|grounds| R
    AUTH -->|grants / attests| R
    SUB -->|holds| R
    R -->|relates to| OBJ
    R -->|has 1..*| ACT
    ACT -->|has 0..*| EL
    EL -->|answered by, 1:1| ER
    ER -.->|optionally references| EV
    ES -->|provides| EV
    ER -->|all true| DEC
    DEC -->|precedes| EX
    EX --> EE
    EE -->|is a| EVT
    R -.->|granted / revoked| EVT
    SRC -.->|changed| EVT
    ER -.->|issued| EVT
    DEC -.->|established| EVT

4. Design Positions

4.1 Extensibility without interpretive ambiguity

The layer MUST leave room for extension — profiles, extension properties, domain vocabularies. It MUST NOT leave room for interpretation of its core concepts: no two implementers may legitimately read the same core term differently. Each core concept has a single, explicit responsibility.

4.2 Rights are binary in existence

Rights Layer treats a Right as existing or not existing. Nuance — conditions, scopes, limits — is expressed through Actions and their Eligibilities, not through graded or partial rights.

4.3 Kinds live 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. Action vocabulary and granularity are profile responsibilities; the core fixes only the meaning “an act performed on the basis of a Right”.

4.4 One Eligibility, one requirement

Requirements attach to what is being exercised. An Action needing ten requirements has ten Eligibilities. An Eligibility never contains multiple requirements, and never contains evaluation logic.

4.5 No Context in the core

A catch-all container for time, place, purpose, session, environment, or “judgment material” invites divergent interpretation and blurs authenticity boundaries. The core model has none. Whatever material an issuer uses to evaluate a requirement is gathered and assessed outside the layer; only the Boolean Response, verifiably issued, enters the model.

4.6 Sources are referenced, never restated

Rights Layer never claims to be the origin of a right. Every Right points to the Source(s) that ground it, in the system of record where they live. If the Source changes, an Event records the change.

4.7 The present is explained by history

Facts are recorded as append-only Events. The current state of a Right is derived from its Events. Events themselves carry no institution-specific state-transition logic; how state is derived is the consumer’s or institution’s responsibility.

4.8 Descriptive, not enforcing

Rights Layer expresses rights; it does not enforce them. It does not authenticate subjects, evaluate requirements, issue responses, or give legal effect to decisions. A Decision is not an administrative disposition, a contract formation, or an access grant; an Exercise is the recorded fact of performance, not its institutional validity.

5. Lifecycle View

stateDiagram-v2
    [*] --> Active : RightGranted
    Active --> Active : SourceChanged
    Active --> Suspended : RightSuspended
    Suspended --> Active : RightReinstated
    Active --> Revoked : RightRevoked
    Suspended --> Revoked : RightRevoked
    Active --> Expired : term of Source ends
    Revoked --> [*]
    Expired --> [*]

State names are informative convenience labels; normatively, state is derived from the Event history, and how it is derived is not fixed by the core.

6. Exercise Sequence

sequenceDiagram
    participant Sub as Subject
    participant RL as Rights Layer expression
    participant Iss as Response issuers (external)

    Sub->>RL: Exercise request (Action)
    Note over RL: ExerciseRequested Event
    Iss-->>RL: Eligibility Response per Eligibility<br/>(Boolean, verifiable; evaluation is external)
    Note over RL: EligibilityResponseIssued Events
    Note over RL: all Responses true → Decision established<br/>DecisionEstablished Event
    Sub->>RL: Action actually performed
    Note over RL: ExerciseStarted / ExerciseEnded Events

This sequence is conceptual. Who issues Responses, how they evaluate, and how an institution acts on an established Decision are all outside the layer.