Identity, Rights, and Control
Legitimate Interaction Requires More Than Identity
A persistent digital World cannot treat every interaction as equally authoritative.
BitPangea must distinguish between recognizing an actor, recognizing that actor’s relationship to something in the World, and determining what the actor is actually permitted to do.
Those are different questions.
The governing distinctions are:
Identity → Who or what is this?
Rights → What recognized relationship exists?
Control / Authorization → What may be done?
These concepts are related, but they are not interchangeable.
A system that collapses them together risks confusing presence with authority, ownership with permission, or authentication with legitimacy.
BitPangea therefore treats identity, rights, and control as separate architectural responsibilities.
Identity
Identity answers the most basic actor question:
Who or what is this?
An identity may eventually represent:
- a person,
- an institution,
- a Builder,
- a service,
- an automated system,
- an authorized agent,
- or another recognized actor.
Identity allows BitPangea to determine that an action originates from a particular recognized entity.
But identity alone does not establish what that entity may do.
Authentication may prove that an actor controls a credential.
That does not automatically establish ownership, administrative authority, development rights, access rights, governance rights, or permission to alter World State.
The distinction is important:
Authentication proves access to an identity mechanism. Identity establishes the actor. Neither, by itself, establishes authority.
BitPangea should therefore avoid systems in which possession of a credential silently becomes equivalent to every form of recognized control.
Rights
Rights answer a different question:
What governed relationship exists between an actor and something within BitPangea?
A rights architecture may eventually recognize relationships such as:
- ownership,
- authorized use,
- access,
- development authority,
- delegation,
- tenancy,
- stewardship,
- operational responsibility,
- shared control,
- or another governed relationship.
The complete rights model has not yet been designed.
That is deliberate.
The Architecture should first preserve the distinction between the existence of a relationship and the specific economic or legal model through which that relationship is later expressed.
Ownership is therefore one possible rights relationship.
It is not the definition of rights itself.
This matters especially for Parcels.
The Parcel Cadastre establishes canonical Parcel identity and territory.
A rights system may later record who possesses a recognized relationship to that Parcel.
But it should not redefine which Parcel exists, where that Parcel is located, or what territory canonically belongs to it.
The principle is:
The Parcel Cadastre owns Parcel truth. Identity / Rights / Control may reference Parcel truth without redefining it.
And more generally:
Reference does not transfer authority.
Control and Authorization
Control concerns exercisable authority.
Authorization asks whether a particular action is permitted under the applicable relationships, rules, and current World condition.
The question becomes:
What may this actor do here, now, and under what authority?
That may eventually include operations such as:
- entering a restricted environment,
- modifying a structure,
- publishing content,
- operating a service,
- delegating authority,
- changing an access rule,
- initiating a transaction,
- or requesting a change to canonical World State.
Authorization should not be inferred merely because an actor is known.
Nor should it be inferred merely because the actor possesses some recognized right.
A right may be limited in scope.
Control may be delegated.
Permission may be conditional.
Authority may expire.
Some operations may require more than one form of approval.
The Architecture must therefore preserve the distinction:
Identity establishes the actor.
Rights establish the relationship.
Control establishes exercisable authority.
Ownership Is Not the Architecture
BitPangea’s finite Parcel supply naturally creates questions about ownership.
But ownership should not be allowed to dominate the Architecture before the World itself is fully defined.
A Parcel can exist without being owned.
A Parcel can remain the same Parcel while ownership changes.
A Parcel can be referenced without being transferable.
A participant may have permission to use a place without owning it.
An institution may have responsibility for a place without possessing economic ownership.
A Builder may be permitted to modify something within a Parcel without acquiring permanent control over the Parcel itself.
These distinctions are essential if BitPangea is to support more than one simplistic relationship between people and place.
The Architecture should therefore preserve the possibility of multiple governed relationships rather than assume that every legitimate interaction reduces to ownership.
No Predetermined Token Model
Nothing in the present BitPangea architecture requires Parcels to be represented as NFTs.
Nothing requires a Parcel token.
Nothing requires a particular blockchain.
Nothing requires ownership to be expressed through a transferable cryptographic asset.
Nothing requires every right to be publicly transferable.
And nothing requires a predetermined ownership model.
Those technologies or mechanisms may later be evaluated if they solve real architectural problems.
But they are not foundational assumptions.
This distinction is important because BitPangea begins with persistent place rather than with a token representing place.
The order matters.
The Parcel exists before any instrument that may later represent a relationship to the Parcel.
A representation of ownership is not the Parcel.
A token is not the territory.
A wallet address is not the actor.
A credential is not the right.
A transaction is not automatically legitimate merely because it is technically valid.
The Architecture must preserve those distinctions.
Authority Should Be Bounded
BitPangea also follows a principle of bounded authority:
Authority should not exceed the responsibility that justifies it.
A system responsible for identity should not quietly acquire the power to redefine Parcel territory.
A rights registry should not become the source of canonical spatial truth.
A Runtime service should not create authority simply because it can execute an operation.
An interface should not grant permission merely because it exposes a button.
Each Architecture domain should operate within its own responsibility boundary.
This reduces the risk that technical convenience turns into unintended control.
It also makes the system easier to replace, audit, and govern over time.
From Authority to Action
The conceptual flow can be expressed as:
This is a conceptual responsibility flow, not a claim that every implementation must use one identical technical pipeline.
It expresses the responsibility boundary.
Identity tells BitPangea who or what is acting.
Rights identify the governed relationship.
Authorization determines whether the requested action is permitted.
World Runtime executes legitimate change.
Persistence / Provenance preserves the resulting continuity and evidence.
Keeping these stages distinct allows BitPangea to change operational systems later without confusing one responsibility with another.
Legitimate Change
The purpose of Identity / Rights / Control is not to make the World restrictive.
It is to make change legitimate.
A persistent World must be capable of distinguishing:
- observation from modification,
- presence from authority,
- ownership from use,
- rights from permissions,
- permission from execution,
- and execution from canonical truth.
Without those distinctions, the World may change, but it cannot reliably explain why a change was allowed.
BitPangea therefore treats legitimate authority as part of the architecture required for persistent, coherent change.
The central principle remains:
Identity, ownership, rights, control, permission, and authority are not synonyms.
A coherent World depends upon preserving the differences among them.