Rights as a bounded context - EnfinitOS

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/rights/bases`	Register the basis a right will be issued from.
`/v1/rights` · `/v1/rights/issue`	Issue, read, suspend, resume, revoke.
`/v1/offers`	Propose, accept, reject, counter, withdraw.
`/v1/challenges`	Open, resolve, withdraw.
`/v1/events`	The append-only audit stream every lifecycle transition lands in.

Lifecycle transitions also fan out as signed webhooks — see Webhooks. The full surface is in the API reference.