The World Runtime

Change Without Losing the World

A persistent digital World must be capable of change.

Structures may be created.

Permissions may be updated.

Services may operate.

Content may be added.

Institutions may act.

Builders may modify what they are authorized to control.

Participants may interact with systems that alter the current condition of the World.

But change creates a difficult architectural problem:

If every operation can redefine canonical truth, the World becomes unstable.

If no operation can change anything, the World cannot become inhabited, useful, or historical.

BitPangea therefore requires a governed operational layer capable of processing legitimate change while preserving continuity.

That responsibility belongs to World Runtime.

The central principle is:

Spatial Truth and World State

The first distinction is between spatial truth and World State.

Spatial truth answers questions such as:

• What World exists?
• Where is a canonical location?
• Which Parcel occupies a particular place?
• What territory canonically belongs to that Parcel?
• What spatial relationships remain fixed?

World State answers a different question:

A Parcel may contain a structure today that did not exist yesterday.

A service may be operating now that was previously inactive.

An access rule may change.

A Builder may publish something.

An institution may receive authority.

A World object may move, appear, disappear, or change condition.

Those changes do not necessarily alter the spatial foundation itself.

This distinction allows BitPangea to remain stable at its deepest levels while becoming dynamic above them.

Persistent World State

World State must persist beyond the moment in which an interaction occurs.

If a legitimate operation changes the World, that change should not vanish merely because the user closes an application or the service that processed the request restarts.

This means BitPangea requires persistent operational state.

The exact implementation remains open.

What matters architecturally is the responsibility:

Persistent state allows the World to accumulate consequence.

Without it, activity becomes temporary display rather than durable World history.

Authorized Operations

World Runtime should not decide authority merely because it is capable of executing an operation.

Authorization belongs to the appropriate authority systems, including Identity / Rights / Control.

Runtime receives a request and must determine whether that request is permitted under the relevant rules and current conditions.

The responsibility sequence is:

These stages must remain distinct.

A request is simply an attempt to cause change.

Authorization determines whether that change is permitted.

Execution performs the permitted operation.

The result becomes part of World State if the operation succeeds.

This leads to another concise relationship:

Keeping these responsibilities separate prevents Runtime from quietly becoming the source of rights, identity, or Parcel truth.

Validation Before Change

A permitted operation must still be valid.

BitPangea therefore requires validation before consequential World State changes are accepted.

Validation may eventually consider:

• whether the actor is authorized,
• whether the target exists,
• whether the requested change is well formed,
• whether the operation violates canonical spatial truth,
• whether required dependencies are satisfied,
• whether the current state permits the requested transition,
• whether conflicting changes exist,
• or whether the operation would create an invalid World condition.

The exact validation rules will depend upon the operation.

The architectural principle is broader:

Runtime must preserve the integrity of the World, not merely process commands.

Execution

Once an operation is both authorized and valid, Runtime executes the change.

Execution should be deterministic wherever canonical outcome requires it.

Equivalent legitimate operations should not produce contradictory canonical results merely because different conforming systems process them.

That does not mean every implementation must use identical software.

It means the architecture must define enough shared meaning that one World does not become several incompatible Worlds through implementation variance.

Execution therefore sits at the boundary between architectural meaning and technical realization.

Implementation may vary.

Canonical outcome must remain coherent where the architecture requires one answer.

Protocols and Services

World Runtime will require mechanisms through which systems communicate and operations are requested.

These may include protocols and services.

A protocol defines how systems interact.

A service provides some usable capability.

Neither should automatically become a source of canonical authority.

A protocol may carry an authorized instruction without creating the right to issue that instruction.

A service may perform a useful operation without becoming the owner of the World truth it processes.

This distinction is important because service architecture will almost certainly change over time.

BitPangea should be able to replace a service without replacing the World.

Likewise, a protocol should remain a means of interaction rather than a hidden constitutional layer.

Integrity

A living World requires more than successful execution.

It requires integrity.

Integrity means that legitimate changes leave the World in a coherent condition.

That may eventually require safeguards against:

• contradictory updates,
• partial operations,
• invalid state transitions,
• duplicated effects,
• unauthorized mutation,
• corruption,
• or divergence among conforming systems.

The precise mechanisms remain unresolved.

But the architectural responsibility is established:

Where an operation has multiple dependent effects, the architecture must preserve a coherent outcome rather than leave the World in an ambiguous intermediate state.

The implementation can evolve.

The requirement for coherent outcomes should not.

Recovery

Persistent systems can fail.

Software crashes.

Networks partition.

Hardware fails.

Services become unavailable.

Implementations contain bugs.

BitPangea therefore cannot define continuity as the absence of failure.

It must define continuity as the ability to preserve or restore coherent World State when failure occurs.

Recovery architecture must eventually answer questions such as:

• What state is authoritative after interruption?
• How is incomplete work identified?
• How are conflicting records resolved?
• How can corrupted or failed components be replaced?
• How can the World resume without silently rewriting legitimate history?

The exact mechanisms remain open.

The principle is not:

It is:

Runtime and Provenance

Runtime changes the present.

Persistence / Provenance preserves the path to the present.

Those responsibilities are connected but should remain distinct.

Runtime should know enough to execute legitimate operations.

Provenance should preserve enough evidence to understand how a resulting state came to exist.

This makes later verification, accountability, historical preservation, correction, and institutional memory possible.

The distinction is:

A mature BitPangea should therefore be able to answer not only:

but, where appropriate:

One Operational World

BitPangea is intended to support one canonical operational World, even if multiple conforming implementations eventually participate in operating or experiencing it.

That requires Runtime semantics strong enough to prevent technical diversity from becoming contradictory World truth.

Different implementations may use:

• different programming languages,
• different internal databases,
• different service architectures,
• different optimization strategies,
• or different interface layers.

But where an operation has one canonical meaning, conforming implementations must preserve that meaning.

The principle remains:

This is not a commitment to one technical architecture.

It is a commitment to continuity of meaning.

The Purpose of Runtime

World Runtime is not the World itself.

It is not the source of Parcel identity.

It is not the source of actor rights.

It is not the permanent memory of every event.

It is the governed operational architecture through which legitimate change becomes current World State.

Its role can be summarized simply:

The World Runtime exists so BitPangea can become dynamic without becoming arbitrary.