Identity, Rights, and Control
A persistent World requires more than places.
It requires actors.
It requires relationships between actors and World objects.
It requires rules governing what those relationships permit.
And it requires a way to distinguish between:
association
entitlement
permission
control
and authority.
These responsibilities belong to one of BitPangea’s recognized Architecture domains:
Identity / Rights / Control
The grouping is deliberate.
The concepts are deeply related.
But they are not the same thing.
BitPangea should preserve that distinction carefully.
Identity answers who.
Rights answer what governed relationship exists.
Control answers what authority may actually be exercised.
Those questions may eventually require further internal separation.
The Architecture preserves the domain now because the responsibility is enduring, even though its final internal design remains unresolved.
The First Question: Who or What Is the Actor?
Before a governed relationship can exist, BitPangea must be able to distinguish the actor to which that relationship applies.
This is the problem of Identity.
Identity asks:
Who or what is this?
The answer may eventually apply to more than human individuals.
BitPangea may need to recognize different classes of actors, including:
individuals
organizations
institutions
services
Builders
automated agents
World systems
other future actor types
The final actor model remains open.
The architectural requirement is already clear:
BitPangea must be able to distinguish actors persistently enough that rights, authority, actions, provenance, and history can refer to them meaningfully.
Without persistent actor identity, every higher relationship becomes fragile.
Identity Is Not a Username
A username may identify someone to an interface.
That does not make the username the canonical actor.
Likewise, an:
email address
wallet address
account number
public key
credential
device identifier
external platform account
may help authenticate or locate an actor.
None should automatically become synonymous with BitPangea identity merely because it is convenient to implement.
The distinction parallels the Foundational Survey Fabric.
Just as BitPangea should not confuse an implementation coordinate with canonical spatial reference, it should not confuse an implementation credential with persistent actor identity.
Conceptually:
Actor
persistent BitPangea identity
may be associated with:
username
credential
wallet
device
account
profile
external identity
Those associations may change.
The actor’s continuity should remain intelligible.
Authentication Is Not Identity
Authentication asks:
Can this entity demonstrate control of credentials associated with an identity?
Identity asks:
Which actor is this?
They are related.
They are not synonymous.
Credentials may be:
rotated
revoked
recovered
replaced
superseded
or rendered obsolete by technology
A change in credentials should not necessarily create a new historical actor.
Conceptually:
Actor Identity
may use over time
Authentication Credentials
The mechanism remains open.
The separation should not.
Identity Is Not Ownership
One of the most important distinctions in the domain is:
Identity does not imply ownership.
Knowing who an actor is does not establish what that actor controls.
Likewise:
≠
ownership
≠
rights
≠
permission
≠
authority
An actor may exist in BitPangea without possessing any special relationship to a Parcel.
An organization may possess a governed relationship that its individual members do not possess personally.
A service may have narrowly scoped authority to perform an operation without owning anything.
Identity makes governed relationships possible.
Identity is not itself the governed relationship.
The Second Question: What Relationship Exists?
Once an actor can be identified, BitPangea can ask a different question:
What governed relationship exists between this actor and a World object, place, system, or capability?
This is the problem of Rights.
The term should be used carefully.
“Rights” can carry:
legal
political
moral
contractual
technical
social
meanings.
BitPangea has not yet adopted a final rights taxonomy.
At the Architecture level, the concern is more general:
What recognized relationship gives an actor some governed standing with respect to something in the World?
That relationship may eventually take many forms.
Origins should preserve the need for the architecture without inventing its final categories.
Rights Require Provenance
A right should not exist merely because an application claims that it exists.
BitPangea should ultimately be able to determine, for consequential governed relationships:
What relationship is this?
Which actor possesses it?
To what object or capability does it apply?
What does it permit?
Where did it originate?
Which authority established it?
When did it become effective?
Can it expire?
Can it be delegated?
Can it be revoked?
Can it be superseded?
What evidence supports its present standing?
Not every relationship will necessarily require every one of these properties.
But the broader requirement is important:
Rights require provenance.
A system that preserves a right while losing the authority from which it came risks confusing assertion with legitimate standing.
This is one reason Persistence / Provenance is now a distinct Architecture domain.
Identity / Rights / Control may establish and use governed relationships.
Persistence / Provenance helps preserve their lineage.
Rights Are Not the Parcel
A Parcel may be the object to which a right refers.
The right is not the Parcel.
Conceptually:
Parcel
→ canonical spatial object
Right
→ governed relationship involving that object
This distinction protects the Parcel Cadastre.
If a right changes:
the Parcel does not disappear.
If a new actor acquires a relationship:
the Parcel does not move.
If a right expires:
the Parcel’s territorial definition does not change.
Thus:
The Parcel Cadastre owns Parcel truth. Identity / Rights / Control may reference Parcel truth without redefining it.
This is an application of the broader architectural rule:
Reference does not transfer authority.
Ownership Is Only One Possible Relationship
Digital-land systems often jump immediately from Parcel existence to ownership.
BitPangea should not.
Ownership may eventually become an important BitPangea concept.
But beginning with it would prematurely compress a richer architectural problem into one inherited word.
Future governed relationships could potentially distinguish concepts such as:
ownership
use
access
construction authority
administrative authority
delegated authority
temporary permission
occupancy
custodianship
shared control
service authority
These are illustrative only.
They are not adopted BitPangea rights classes.
The governing principle is:
Discover the relationships the World actually requires before deciding which inherited legal or technical words should describe them.
The Third Question: What May Actually Be Done?
Rights describe governed relationships.
Control concerns the ability to exercise authority.
The question becomes:
What may this actor actually cause to happen?
That is different from merely recording that a relationship exists.
An actor may possess some recognized right associated with a Parcel while still lacking authority to perform every possible operation affecting it.
Conceptually:
Actor Identity
Rights Relationship
Control / Authorization
permitted operation
World Runtime
execution
resulting World state
This sequence is important.
Rights describe standing.
Authorization determines whether a specific action is permitted under current conditions.
Control concerns exercisable authority.
Execution belongs to World Runtime.
Those responsibilities should not be collapsed into one field or one service merely because implementation would be simpler.
Authorization Is Not Rights
Rights and authorization should remain distinct.
Rights describe governed relationships.
Authorization evaluates a specific proposed action.
An authorization decision may depend upon:
rights
current World state
object state
time
policy
protocol
delegation
other governing conditions
Conceptually:
Rights
\+
current conditions
\+
applicable rules
Authorization decision
The exact mechanism remains unresolved.
The architectural distinction should remain.
A right may contribute to permission.
It does not necessarily guarantee every action.
Control Is Not Unlimited Authority
Control must be scoped.
Permission to perform one action should not silently become permission to perform everything.
Future BitPangea architecture may distinguish authority to:
view
enter
build
modify
operate
delegate
transfer
administer
remove
configure
Again, these are examples, not adopted categories.
The principle is:
Authority should be explicit enough that permission to do one thing does not silently become permission to do everything.
This becomes increasingly important once Builders, infrastructure, services, and persistent World state begin interacting.
One Owner Field Is Not an Architecture
A simplistic digital property system might store:
Parcel 1042
Owner: Alice
That may be enough for a prototype.
It does not answer the deeper architectural questions.
What identifies Alice?
What proves the relationship?
What authority created it?
What does “Owner” actually permit?
Can authority be delegated?
Can multiple actors hold different governed relationships?
Can different rights apply to different functions?
Can an actor temporarily exercise authority without acquiring ownership?
What happens when credentials change?
How is a dispute represented?
What provenance is preserved?
What historical record remains after the relationship changes?
The point is not that every Parcel must become legally complicated.
The point is that:
simplicity should be the result of understanding the architecture—not a substitute for understanding it.
Rights Need Not Be Parcel Rights
The 21,000,000 Parcels make Parcel relationships an obvious use case.
But the Identity / Rights / Control domain should not be designed only around Parcels.
Actors may eventually interact with:
constructed objects
infrastructure
services
institutions
organizations
shared systems
creative works
World capabilities
administrative functions
Builder tools
future object classes not yet imagined
The Architecture should therefore be capable of supporting governed relationships beyond ordinary Parcel control.
That does not require one universal rights model.
It requires avoiding a design so narrow that every new World object forces the domain to be reinvented.
Persistent Actor, Persistent Place, Changing Relationship
One of BitPangea’s strongest architectural advantages is the ability to separate persistent identities from changing relationships.
Conceptually:
Actor Identity
→ persistent actor
Parcel Identity
→ persistent place
Rights Relationship
→ may change over time
Control
→ may change according to the relationship and current conditions
This allows BitPangea to preserve meaningful history.
The same Parcel can remain the same place while different actors hold different relationships to it across time.
The same actor can preserve historical continuity even when credentials change.
The governed relationships can evolve without either identity having to be recreated.
Delegation
Delegation is one likely future requirement.
An actor possessing authority may need to permit another actor to exercise some subset of that authority.
Conceptually:
Actor A
possesses authority
delegates limited authority
Actor B
may exercise specified capability
If delegation exists, the Architecture will eventually need to answer:
Who may delegate?
What may be delegated?
For how long?
Under what conditions?
May delegated authority itself be delegated?
Can it be revoked?
What happens when the original authority ends?
How is provenance preserved?
These questions remain open.
Their existence reinforces why identity, rights, control, and provenance should not be treated as synonyms.
Shared and Multiple Relationships
BitPangea should also avoid assuming that every object must always have exactly one relevant actor.
A World may need relationships involving:
multiple individuals
organizations
institutions
groups
shared administration
joint projects
delegated operators
The architecture should not accidentally make singular control a permanent World rule merely because an early implementation stores only one account identifier.
Implementation convenience should not settle unresolved World relationships.
Time
Governed relationships may possess temporal dimensions.
A future relationship could theoretically be:
permanent
temporary
scheduled
conditional
revocable
expiring
future-effective
BitPangea has not adopted these as formal classes.
But time matters because a persistent World must be able to distinguish:
What is true now?
from:
What was true before?
and potentially:
What becomes true later?
This is another place where Identity / Rights / Control interacts with Persistence / Provenance.
The current relationship belongs to operational truth.
Its lineage belongs to historical and provenance truth.
Identity, Rights, Control, and World Runtime
The Identity / Rights / Control domain does not itself need to execute every change it authorizes.
That responsibility belongs to World Runtime.
A future consequential action might conceptually proceed:
Actor requests operation
Identity resolved
relevant rights determined
control / authorization evaluated
operation validated
World Runtime executes
persistent World state changes
Persistence / Provenance preserves lineage and evidence
This sequence protects responsibility boundaries.
Identity / Rights / Control answers whether the actor has standing and authority.
World Runtime governs legitimate operational change.
Persistence / Provenance helps preserve how that condition arose.
None should silently absorb the others.
Identity, Rights, Control, and Builders
Builders make these distinctions operationally important.
A Builder may eventually ask:
May this actor build here?
What may the actor modify?
What may be removed?
What constraints apply?
What authority supports the request?
The Builder should not invent these answers.
It should consume them from the relevant Architecture.
Conceptually:
Builder
references Parcel Cadastre
references Identity / Rights / Control
requests legitimate World change
World Runtime validates and executes
Persistence / Provenance preserves appropriate evidence
The Builder creates.
It does not become cadastral authority.
It does not become rights authority.
It does not become World Runtime merely because it initiates an action.
Infrastructure May Require Different Relationships
World-scale infrastructure may introduce relationships that ordinary Parcel control cannot describe adequately.
A future:
road
transport system
communications network
shared utility
public service
digital-native infrastructure system
may cross many Parcels.
It would be architecturally weak to assume that all such systems must be modeled through the same relationship as one actor controlling one Parcel.
The broader principle is:
Different classes of World responsibility may require different classes of authority.
The final relationships remain open.
The Architecture should preserve enough flexibility to discover them.
Formal Rights and Social Relationships Are Different
BitPangea should also distinguish formal World-recognized relationships from relationships created socially by civilization.
A community may recognize:
custom
membership
tradition
reputation
voluntary obligation
local expectation
without those relationships becoming canonical World rights.
Similarly, not every social rule needs World Runtime enforcement.
The distinction is important:
Architecture governs what must be governed. Civilization may create additional relationships that remain social rather than canonical.
BitPangea should not turn every human relationship into protocol merely because it can represent one.
Identity and Privacy
Persistent identity does not require universal public disclosure.
The Architecture may eventually need to distinguish among:
existence of identity
proof of identity
identity attributes
credential data
public presentation
private attributes
authorization-relevant information
These are different concerns.
BitPangea may need to know enough to establish legitimate authority without making every identity fact public to every participant.
The governing distinction is:
Persistent identity and maximal disclosure are not the same requirement.
Identity and Pseudonymity
Meaningful identity also does not necessarily require a real-world legal name.
A persistent pseudonymous actor may still accumulate:
history
reputation
relationships
rights
responsibility
creative work
institutional roles
BitPangea should therefore determine identity assurance according to what a particular action requires rather than assuming one universal real-world identity standard.
Some actions may require stronger assurance.
Others may not.
That question remains open.
Authority Must Be Traceable
Consequential World actions should ultimately be explainable.
For an important change, BitPangea should aspire to answer:
Who acted?
Under which persistent identity?
Against which World object or capability?
Using what authority?
What rights or relationships supported the decision?
What authorization was evaluated?
What changed?
When did it occur?
What provenance was preserved?
This does not mean every trivial action must become administratively heavy.
It establishes a principle for consequential World change:
Authority should be traceable.
A persistent World should be able to distinguish legitimate change from unexplained mutation.
The Creator’s Authority
This domain eventually applies to the Creator as well.
During the Creator Period, the Creator necessarily possesses extraordinary authority.
The World is still being established.
Its enduring systems do not yet exist independently enough to govern every action.
But unlimited Creator authority should not automatically become the permanent model of a mature BitPangea.
As Architecture becomes established, authority should increasingly belong to explicit systems rather than informal intervention.
The principle remains:
The Creator should become progressively less authoritative as BitPangea moves from World creation toward civilization.
This does not mean the Creator becomes irrelevant.
The role changes.
Creation increasingly becomes stewardship.
A mature World should be capable of answering:
Why was this action permitted?
with something stronger than:
Because the Creator could do it.
No Premature Tokenization
BitPangea’s fixed Parcel count and Bitcoin inspiration make tokenization an obvious future possibility to consider.
They do not make it a present architectural requirement.
Parcel rights do not presently require:
NFTs
a Parcel token
a particular blockchain
wallet-based ownership
on-chain governance
a specific transfer protocol
Any of those technologies may eventually be evaluated if they solve actual BitPangea requirements.
The correct order remains:
requirement
architecture
technical evaluation
implementation
not:
preferred technology
architecture invented to justify it
No Premature Legal Analogy
The same restraint applies to physical property law.
Terms such as:
deed
title
lease
easement
tenant
landlord
estate
may someday provide useful analogies.
But BitPangea should not inherit their full legal meaning merely because Parcels resemble territorial property.
Some concepts may map well.
Others may not.
Digital place may require relationships for which physical land law has no clean equivalent.
The governing rule is:
Use analogy to aid understanding. Do not allow analogy to replace architectural reasoning.
History of Authority
Persistent identity, governed relationships, control, Runtime execution, and provenance together create the possibility of reconstructing the history of authority.
For a Parcel or another World object, future BitPangea may be able to determine:
Which actor held which relationship?
During what period?
Who established it?
Was authority delegated?
Which actions occurred under it?
How was that authority changed or superseded?
How did the present condition arise?
Current state answers:
What is true now?
Provenance and history answer:
How did it become true?
Those are distinct kinds of knowledge.
A mature World may require both.
Internal Decomposition Remains Open
Identity / Rights / Control is now a recognized Architecture domain.
That recognition does not mean the domain’s internal architecture is complete.
Continued design may ultimately distinguish separate authorities for:
Identity
Rights
Authorization
Control
Policy
Delegation
Credentialing
Recovery
other responsibilities
The domain should therefore not be treated as one monolithic service merely because its name contains three concepts.
The Architecture has identified the enduring responsibility.
Its internal decomposition remains an open design problem.
What Is Established
The current Architecture supports the following statements:
Identity / Rights / Control is a recognized Architecture domain.
BitPangea requires persistent actor identity.
Identity is distinct from authentication.
Identity does not establish ownership, rights, permission, or authority by itself.
Rights describe governed relationships involving actors, World objects, or capabilities.
Rights require traceable authority and provenance.
The Parcel Cadastre remains authoritative for Parcel truth.
Rights may reference Parcels without redefining them.
Control concerns exercisable authority.
Authorization is distinct from the mere existence of a right.
Authority should be explicitly scoped.
World Runtime executes legitimate operational change.
Identity / Rights / Control should inform Runtime authorization without becoming World Runtime itself.
Persistence / Provenance should preserve the lineage and evidence associated with consequential authority and change.
Builders should consume rights and control information rather than invent it.
The domain should not be reduced prematurely to “ownership.”
Parcel rights do not presently require tokens, NFTs, or any particular blockchain.
Persistent identity does not require universal public disclosure.
Pseudonymous persistent identity remains architecturally possible.
The domain may ultimately require substantial internal decomposition.
What Remains Open
Major questions remain, including:
the canonical actor identity model
which actor classes BitPangea recognizes
the relationship between BitPangea identity and external identities
authentication mechanisms
credential recovery
identity continuity
privacy architecture
pseudonymity
identity assurance levels
the formal categories of governed relationships
whether ownership becomes a canonical BitPangea term
how rights originate
how rights are transferred
how rights expire
how rights are revoked
delegation
shared authority
institutional authority
infrastructure authority
authorization mechanisms
control boundaries
policy architecture
exception handling
dispute handling
recovery mechanisms
history of authority
the exact interface with Persistence / Provenance
the exact interface with World Runtime
the eventual internal decomposition of the domain
These questions should remain open until the Architecture can justify their answers.
Origins should preserve the problem faithfully rather than manufacture a rights system simply to make the diagram look complete.
The Principle
Identity, Rights, and Control determine whether BitPangea can move from persistent digital place into a World where actors can participate without dissolving the boundaries among:
actor
place
relationship
authority
and action.
The essential distinctions are:
Identity answers who.
Rights answer what governed relationship exists.
Control answers what authority may be exercised.
Authorization determines whether a particular action is presently permitted.
World Runtime performs legitimate change.
Persistence / Provenance preserves how that authority and change came to exist.
And beneath all of them remains the question:
By whose authority?
That question prevents BitPangea from reducing its future social architecture to an owner field, a wallet address, or an access-control shortcut.
A mature digital World should eventually be able to know:
who acted, what relationship supported the action, what authority was exercised, why the action was permitted, what changed, and how that change can later be explained.
The governing principle is therefore:
Identity establishes the actor. Rights establish the relationship. Control establishes exercisable authority. None should silently inherit the authority of the others.