Rights as a bounded context

Why rights deserve their own bounded context — and the lifecycle: basis → right → offer → counter → challenge → withdrawal / expiry / suspension / revocation.

The full architectural decision record is published as ADR-0005. This page summarises it for developers integrating with the rights plane.

The lifecycle

Basis (civic / property / trademark / contractual)
   ↓
Right (issued from a basis, scoped, time-bound)
   ↓
Offer (one party proposes to share / cede / sublet a right)
   ↓ ↓ ↓
 Accept   Reject   Counter
   ↓
Derived right (new right, scoped under the parent)

   At any point, a right can be:
   - Challenged (a third party disputes it)
   - Suspended (paused without revoking)
   - Revoked (terminated)
   - Withdrawn (the holder gives it back)
   - Expired (TTL ran out)

Why bounded

Rights are a bounded context because:

• They have their own invariants — a derived right cannot exceed the scope of its parent; a suspended right cannot be exercised; an expired right is non-recoverable.
• They have their own language — basis, offer, counter, challenge — that doesn’t appear elsewhere in the platform.
• They have their own lifecycle — most other entities are CRUD; rights are state machines.

Mixing rights logic into the runtime or settlement layers would produce the kind of tangle that’s expensive to unwind under regulatory scrutiny.

Where this surfaces in the API

Endpoint group	Purpose
/v1/basis	Register the basis a right will be issued from.
/v1/right	Issue, read, suspend, resume, revoke.
/v1/offer	Propose, accept, reject, counter, withdraw.
/v1/challenge	Open, resolve, withdraw.
/v1/provenance	Walk the derivation chain of a right.

The full surface is in the API reference.