THE URANTIA BOOK: A COSMIC PERSPECTIVE

But we should not assume beforehand what that process must look like. That would defeat the purpose of this investigation.

Instead, we are going to do exactly what we did with the hardware. We will read the specification. We will identify the components. We will determine what each component is said to do. We will follow how information, authority, energy and action move between them.

We will look for layers of administration and delegation. We will look for inputs and outputs. We will look for coordination. We will look for communication. We will look for repeating processes. And only then will we compare what we find with the architecture we have already developed.

Because now we have something we did not have when we began this book. We have a proposed machine. Paradise provides its center. Havona provides its organized central interior. The superuniverses and outer-space levels give us its maximum structure. Circuits connect its regions. Movement keeps the structure dynamic. Time provides sequence. The basic hardware is on the table.

Now Papers 15 through 31 allow us to begin examining what is running through it. And from the Codex View, that may be where this investigation becomes even more interesting.

Because a system does not become intelligent merely because it has structure. Structure has to do something. Information has to move. Functions have to coordinate. Processes have to execute. Different parts of the system have to communicate. Actions have to produce results. Results have to affect what happens next.

That is the transition we are making now. For the first fourteen Papers, we were largely studying the architecture of the machine. Beginning with Paper 15, we start opening the software.

We have crossed an important boundary. For the first fourteen Papers, much of our investigation centered on what a programmer might call the hardware of the system. We identified the center. We examined Paradise. We looked at Havona, the sacred spheres, the seven superuniverses and the outer-space levels. We found boundaries, circuits, gravity relationships, movement, counter-movement and time. By the end of Paper 14, we had something resembling a system diagram.

But a diagram of the hardware does not tell us what the machine is doing. Now that begins to change. Paper 15 starts with the Seven Superuniverses, so at first it appears that we are still examining physical structure. But the Paper itself explains why this physical description matters: understanding the material organization prepares us to understand the government, administration and intellectual development operating throughout those regions.

From a programmer's perspective, that is almost a perfect transition. We have mapped the machine. Now we are beginning to trace what runs through it. And Papers 15 through 17 give us our first real look at the software architecture of the universe.

Paper 15 — From Structure to Administration

Paper 15 begins with something we already know. There are seven superuniverses. But now the Book begins telling us how those seven enormous regions are actually organized. The seven superuniverses are not simply seven areas of space. They are administrative domains. The Book describes the first post-Havona creation as having been divided into seven enormous segments, each with its own headquarters and government. The Seven Master Spirits radiate their influence outward from Paradise, with each associated with one of these great divisions.

That immediately changes our perspective. In Paper 12, the seven superuniverses were part of the maximum structure. Now we discover that the same seven structural divisions are also being used as operational divisions. The hardware has been partitioned. And each partition has administration assigned to it.

That is very familiar from a systems perspective. You do not build one enormous system and allow every operation to occur everywhere indiscriminately. You divide it. You establish domains. You assign responsibility. You create local control while maintaining connection to the larger system. That is exactly what begins appearing here.

A Hierarchical System

Paper 15 then gives us a remarkably detailed hierarchy. The organization proceeds through seven major levels: 1. System 2. Constellation 3. Local Universe 4. Minor Sector 5. Major Sector 6. Superuniverse 7. Grand Universe

The system contains approximately one thousand inhabitable worlds. One hundred systems form a constellation. One hundred constellations form a local universe. One hundred local universes form a minor sector. One hundred minor sectors form a major sector. Ten major sectors form a superuniverse. Seven superuniverses form the Grand Universe.

This is our first major discovery of the software stage. Seven is no longer simply appearing as a number associated with cosmic structure. We now have a seven-stage administrative hierarchy. And once again, the important question is not: Did we find seven? The important question is: What is seven doing? It is organizing operation. That is exactly where our framework places it. 7 = Process.

At the maximum scale, twelve gave us the complete structural architecture. Here, seven gives us a progression through which that structure can be organized and administered. The system has layers. Each layer has a function. Each layer connects downward and upward. That looks much more like process architecture than simple geometry.

Local Control Inside Global Structure

Something else becomes visible in this hierarchy. Control is distributed. An inhabited planet has its own administration. A system has its headquarters. A constellation has its headquarters. A local universe has its headquarters. Minor sectors, major sectors and superuniverses have their own administrative centers. Yet none of them exist independently of the larger architecture.

This gives us: GLOBAL SYSTEM
↓
REGIONAL DOMAIN
↓
LOCAL DOMAIN
↓
SUBSYSTEM
↓
WORLD Information and authority can therefore move through levels without requiring every operation to occur directly at Paradise. In programming terms, we would call this delegation. The source establishes the architecture, but the work is distributed.

That is important because it continues something we already found in the earlier Papers. The Father does not need to personally perform every function. Capabilities can be provided. Authority can be delegated. Functions can be localized. Yet the localized component remains connected to the larger system. The software is becoming modular.