CONTROL TOWER ID:
CIVATLAS-CT-000
SYSTEM:
Civilisation Atlas
VERSION:
1.0
SCOPE:
CIVATLAS-A001 to CIVATLAS-A112
ROLE:
Canonical controller above the article library
PUBLIC INTERFACE:
CIVATLAS-A112
ROOT GATEWAY:
CIVATLAS-A001
STATUS:
Active master specification

The Civilisation Atlas contains 112 connected articles.

Without a Control Tower, those articles may gradually become:

• a large collection of related essays;
• several overlapping stage systems;
• repeated definitions;
• competing terminologies;
• disconnected historical cases;
• or an archive that humans can browse but artificial intelligence cannot reliably navigate.

The purpose of this Control Tower is to prevent that fragmentation.

The Civilisation Atlas Control Tower is the canonical routing, identity, dependency, crosswalk and quality-control architecture binding all 112 articles into one AI-readable system.

It tells an AI:

• which article defines each concept;
• which articles depend on which foundations;
• which stage system is being used;
• how an object should be classified;
• where contradictions must be resolved;
• which claims are observed or proposed;
• what must not be merged;
• and how to retrieve the minimum sufficient article set for a question.

1. Position of the Control Tower

The Control Tower is not another ordinary article.

It sits above the library.

CIVATLAS-CT-000
Canonical machine controller
↓
CIVATLAS-A001
Public gateway and human introduction
↓
CIVATLAS-A002–A100
Conceptual, analytical and operational Atlas
↓
CIVATLAS-A101–A111
Taxonomy, evidence, registry and technical architecture
↓
CIVATLAS-A112
Public Civilisation Control Tower Interface

CT-000

CT-000 contains:

• canonical laws;
• article IDs;
• article relationships;
• routing logic;
• version control;
• conflict resolution;
• AI guardrails;
• and completion status.

It may be published as a technical master page or retained as the canonical machine specification behind the public Atlas.

Article 112

Article 112 is the visible interface through which readers access:

• the live coordinate;
• stage status;
• lifecycle condition;
• fractures;
• repair;
• observatory readings;
• and article routes.

Article 112 displays the board.

CT-000 governs how the board is assembled.

2. Control Tower Mission

The Control Tower has eight missions.

MISSION 1
Preserve one canonical vocabulary
MISSION 2
Keep the three primary axes separate
MISSION 3
Assign every article a permanent identity
MISSION 4
Bind articles through explicit relationships
MISSION 5
Route AI towards the correct minimum article set
MISSION 6
Prevent unsupported synthesis and hallucination
MISSION 7
Track versions, evidence and completion
MISSION 8
Turn the Atlas into a living operating system
rather than a static article archive

3. The Three Primary Axes

Every AI reading must preserve the separation among the three primary Atlas axes.

Axis A — Chronological Capability Stage

Question:

What class of operating capability has civilisation developed?

FOUNDATION 0
Adaptive Human Worlds
STAGE 1
Settlement and Surplus Civilisation
STAGE 2
Administrative and Recorded Civilisation
STAGE 3
Industrial and Mass-Institution Civilisation
STAGE 4
Planetary Network Civilisation
STAGE 5
Regenerative and Self-Correcting Civilisation
STAGE 6
Multi-World Extension Civilisation
STAGE 7
Autonomous Multi-World Civilisation
STAGE 8
Distributed Interplanetary Civilisation

Axis B — Civilisational Lifecycle Phase

Question:

What condition and direction is the civilisation moving through?

TAKEOFF
CLIMB
CRUISE
DRIFT
DESCENT
REPAIR
RELAUNCH
COLLAPSE

Axis C — Habitat Independence

Question:

Across how many independently survivable habitats can civilisation continue?

H0
Planet-Bound Civilisation
H1
Orbital Extension
H2
Interplanetary Reach
H3
Dependent Off-World Outpost
H4
Persistent Off-World Settlement
H5
Multi-World Redundancy
H6
Autonomous Multi-World Civilisation
H7
Federated Multi-World Civilisation
H8
Distributed Interplanetary Civilisation

Non-merger law

CAPABILITY STAGE
≠
LIFECYCLE PHASE
≠
HABITAT INDEPENDENCE

An AI must never infer one axis directly from another.

A civilisation may be:

CAPABILITY:
Stage 4 Planetary Network
LIFECYCLE:
Drift
HABITAT:
H1 Orbital Extension

Another may be:

CAPABILITY:
Stage 5 Regenerative and Self-Correcting
LIFECYCLE:
Cruise
HABITAT:
H0 Planet-Bound

Interplanetary reach does not prove regenerative maturity.

Later capability does not prove lifecycle health.

Planet-bound status does not prove civilisational inferiority.

4. Canonical Civilisation Atlas Laws

These laws govern every article and every AI synthesis.

Law 1 — Capability is not moral worth

A later capability stage does not prove that a civilisation is:

• wiser;
• kinder;
• fairer;
• more legitimate;
• or more deserving.

Law 2 — Invention is not transition

A prototype, discovery, landing or elite capability does not create a civilisational stage.

A capability must become sufficiently:

• reliable;
• scalable;
• institutionalised;
• teachable;
• maintainable;
• distributed;
• and structurally consequential.

Law 3 — The lower floors remain active

Later stages do not replace earlier foundations.

AI still depends on electricity.
Electricity still depends on infrastructure.
Infrastructure still depends on materials and skill.
Skill still depends on education.
Education still depends on language, health and trust.
Human life still depends on food, water and ecology.

Law 4 — Civilisation is uneven

A society may contain:

• Stage 4 digital networks;
• Stage 3 industrial systems;
• Stage 2 administration;
• Stage 1 agricultural systems;
• and Foundation 0 local ecological knowledge

at the same time.

Law 5 — Civilisation can advance and regress simultaneously

Technical capability may rise while:

• trust;
• education;
• ecological stability;
• institutional legitimacy;
• or future optionality

declines.

Law 6 — Artefact is not capability

Possessing an artefact does not prove that civilisation can:

• reproduce it;
• maintain it;
• teach it;
• repair it;
• or govern it.

Law 7 — Case is not mechanism

A lion, tiger, emperor, empire or company is an example.

The reusable strategic object is the mechanism beneath the example.

Law 8 — Stress is not fracture

STRESS
Pressure
DRIFT
Loss of alignment
FRACTURE
Broken transfer
CASCADE
Spreading failure
INVERSION
Opposite function
COLLAPSE
Loss of essential continuity

Law 9 — Repair is not restoration

Repair does not necessarily recreate the previous system.

The previous system may contain the cause of failure.

Law 10 — Reach is not independence

REACH
≠
PRESENCE
≠
PERSISTENCE
≠
REDUNDANCY
≠
AUTONOMY

Law 11 — Strategy must protect the bucket

A strategically effective move is invalid if it destroys:

• human dignity;
• truth;
• essential capability;
• the BaseFloor;
• or future optionality.

Law 12 — Current coordinates are time-stamped

Humanity’s current stage, lifecycle and habitat readings are provisional and must be attached to a date and evidence state.

Law 13 — Future stages are proposed

Stages 5–8 must be clearly marked as:

• emerging;
• modelled;
• proposed;
• or unachieved

where appropriate.

Law 14 — Unknown remains unknown

Missing evidence must not be replaced by confident inference.

Law 15 — Every answer must preserve uncertainty

The AI must distinguish:

OBSERVED
INFERRED
PROPOSED
SCENARIO
UNKNOWN

5. Canonical Object Taxonomy

Every Atlas article must describe one or more recognised object types.

ATLAS
CONTROL_TOWER
AXIS
STAGE
LIFECYCLE_PHASE
HABITAT_LEVEL
MAP
CORRIDOR
ARTEFACT
CAPABILITY
STRATEGY_MECHANISM
INSTITUTION
SOCIETY
CULTURE
INFRASTRUCTURE
FRACTURE
INVERSION
REPAIR
TRANSITION
GATE
THRESHOLD
SENSOR
INDICATOR
COORDINATE
EVIDENCE_CARD
CASE
INTERFACE

No new top-level object type should be created casually.

A proposed new type must first be cross-walked against Article 101, the Canonical Object Taxonomy.

6. Canonical Relationship Vocabulary

Articles and objects must be connected through explicit relationship labels.

DEFINES
Article provides the canonical definition
EXTENDS
Article develops an earlier concept
DEPENDS_ON
Article cannot be interpreted without another article
CROSSWALKS_TO
Article has an important lateral relationship
APPLIES_TO
Mechanism or concept operates upon another object
EVIDENCES
Object provides evidence for a claim
ENABLES
Capability makes another capability possible
REQUIRES
Object depends on another condition
TRANSITIONS_TO
One stage or state may move towards another
DEGRADES_INTO
Healthy function may deteriorate into another state
INVERTS_INTO
System begins producing its opposite function
FRACTURES
Object damages or breaks another layer
REPAIRS
Object restores another object or transfer
SENSES
Sensor observes an object or condition
GOVERNS
Institution controls an object or flow
LOCATED_AT
Object receives an Atlas coordinate
CONTAINS
Larger system contains a smaller object
DISTRIBUTES
Capability or resource is spread through a system
CONCENTRATES
Capability or authority is brought towards a node
SUPERSEDES
New canonical article or version replaces an earlier one
CONTRADICTS
Two claims cannot both remain canonical without resolution

AI should use these exact labels in registry and crosswalk blocks.

7. Article Identity System

Every article receives a permanent ID.

CIVATLAS-A001
through
CIVATLAS-A112

The Control Tower uses:

CIVATLAS-CT-000

ID rules

1. The ID never changes when the title changes.
2. Deleted articles retain their IDs and become archived.
3. A replacement receives a new version, not a recycled ID.
4. URLs may change; IDs must not.
5. AI retrieval should prioritise ID over title similarity.
6. Aliases must point back to one canonical ID.
7. Article numbers must use three digits.

Correct:

CIVATLAS-A009

Incorrect:

Article9
CivAtlas-9
FractureMap

8. Mandatory Article Metadata Block

Every article should begin with a machine-readable metadata block.

This may be placed in a WordPress Custom HTML block or an HTML comment.

<!-- CIVATLAS:BEGIN
article_id: CIVATLAS-A009
canonical_title: Civilisation Atlas | The Fracture Map
version: 1.0
status: canonical
family: fracture
object_types:
  - MAP
  - FRACTURE
primary_question: How does civilisational stress become fracture, cascade, inversion and collapse?
primary_axes:
  - lifecycle
secondary_axes:
  - capability
  - habitat
required_parents:
  - CIVATLAS-A004
  - CIVATLAS-A006
  - CIVATLAS-A008
crosswalks:
  - CIVATLAS-A010
  - CIVATLAS-A059
  - CIVATLAS-A072
canonical_definitions:
  - civilisational_fracture
  - fracture_stack
evidence_status: mixed
time_status: structural
current_coordinate: false
ai_priority: canonical
supersedes: none
superseded_by: none
canonical_url: TO_BE_ASSIGNED
last_reviewed: YYYY-MM-DD
CIVATLAS:END -->

9. Mandatory Article Crosswalk Block

Every article should end with a visible or hidden crosswalk.

CIVILISATION ATLAS CROSSWALK
ARTICLE:
CIVATLAS-A009
READ BEFORE:
CIVATLAS-A004
CIVATLAS-A006
CIVATLAS-A008
READ NEXT:
CIVATLAS-A010
CIVATLAS-A059
CIVATLAS-A072
PRIMARY OBJECTS:
Fracture
Cascade
Inversion
Collapse
PRIMARY AXIS:
Lifecycle
SECONDARY MAPS:
Motion Landscape
Strategy Library
Repair Map
DO NOT MERGE WITH:
Ordinary stress
Temporary disruption
Routine institutional disagreement
DYNAMIC STATUS:
Structural framework; examples may require updating

This block makes each page self-locating.

10. Article Status System

Each article receives one publication state.

P0 — PLANNED
Title and position exist
D1 — DRAFTING
Article is actively being written
R1 — REVIEW
Article is complete but not yet canonical
C1 — CANONICAL
Article is approved as the active definition
U1 — UPDATE REQUIRED
Article remains active but contains stale dynamic material
S1 — SUPERSEDED
A newer article or version has replaced it
A1 — ARCHIVED
Preserved for history but excluded from canonical routing

AI must not treat P0 or D1 content as completed evidence.

11. Evidence Status System

Every significant claim should be marked as one of:

E0 — CONCEPTUAL
A proposed analytical idea
E1 — ILLUSTRATIVE
Supported by a representative case
E2 — MULTI-CASE
Observed across several cases
E3 — COMPARATIVE
Competing explanations or cases examined
E4 — EMPIRICAL
Supported by measured evidence
E5 — LIVE-VERIFIED
Supported by current, dated and reviewable evidence

Future-stage claims should normally remain E0–E2 unless supported by real-world operating evidence.

12. Time Status System

Articles fall into three time classes.

Structural

Definitions unlikely to change frequently.

Examples:

• Capability Axis;
• Lifecycle Axis;
• object taxonomy;
• Strategy Card.

Semi-dynamic

Interpretation may evolve as research and the Atlas develop.

Examples:

• Stage 5;
• control geometry;
• regenerative capacity;
• transition gates.

Dynamic

Requires dated evidence and regular review.

Examples:

• Live Human Civilisation Coordinate;
• Live Observatory;
• Civilisation Health Report;
• First True Multi-World Coordinate.

STRUCTURAL
Review when the Atlas model changes
SEMI-DYNAMIC
Review at least annually or after major conceptual revision
DYNAMIC
Review on a fixed reporting cycle and after major events

13. The Ten Article Families

The 112 articles are grouped into ten controlled families.

FAMILY K — ATLAS KERNEL
A001–A018
FAMILY M — FOUNDATIONAL MAPS
A019–A032
FAMILY S — CAPABILITY STAGES
A033–A041
FAMILY T — STAGE TRANSITIONS
A042–A048
FAMILY C — CAPABILITY CORRIDORS
A049–A058
FAMILY F — FRACTURE LIBRARY
A059–A072
FAMILY R — REPAIR LIBRARY
A073–A082
FAMILY O — LIVE OBSERVATORY
A083–A090
FAMILY H — HABITAT AND MULTI-WORLD
A091–A100
FAMILY X — TECHNICAL ARCHITECTURE
A101–A112

No article should exist outside a family.

14. AI Routing Runtime

When AI receives a Civilisation Atlas question, it must execute the following runtime.

Step 1 — Parse the question

Identify:

• object;
• time;
• place;
• scale;
• requested output;
• and whether the question is descriptive, comparative, diagnostic, strategic or future-facing.

Step 2 — Classify the object

Choose from the canonical object taxonomy.

Examples:

“What stage is humanity in?”
Object: COORDINATE
“How did writing change civilisation?”
Object: ARTEFACT + CAPABILITY
“Is this institution collapsing?”
Object: INSTITUTION + LIFECYCLE_PHASE + FRACTURE
“Can Mars survive without Earth?”
Object: HABITAT_LEVEL + COORDINATE

Step 3 — Select the primary axis

Capability question
→ Axis A
Health, rise or decline question
→ Axis B
Off-world independence question
→ Axis C

Do not use all three axes unless needed.

Step 4 — Load the root definition

Load the article that canonically defines the object.

Step 5 — Load required parents

Retrieve all articles in required_parents.

Step 6 — Load relevant crosswalks

Retrieve only the maps needed to answer the specific question.

Step 7 — Check time status

For dynamic claims, require:

• a date;
• current evidence;
• and uncertainty.

Step 8 — Check non-merger laws

Ensure that:

• stage is not lifecycle;
• lifecycle is not habitat;
• artefact is not capability;
• case is not mechanism;
• stress is not fracture;
• repair is not restoration.

Step 9 — Detect contradictions

Compare definitions, coordinates and evidence status.

Step 10 — Construct the answer

A standard Atlas answer may contain:

1. OBJECT IDENTIFICATION
2. PRIMARY COORDINATE
3. RELEVANT SUPPORTING MAPS
4. MECHANISM
5. DEPENDENCIES
6. FRACTURE OR REPAIR IMPLICATIONS
7. EVIDENCE STATUS
8. UNCERTAINTY

Step 11 — Name the article route

Where useful, state which Atlas articles generated the answer.

Step 12 — Write new insight as non-canonical

A new inference must be labelled:

PROPOSED EXTENSION
not
CANONICAL ATLAS DEFINITION

until reviewed.

15. AI Query Routing Matrix

16. Contradiction Resolution

When two articles appear to conflict, AI must not average the claims.

Use this priority order:

1. CIVATLAS-CT-000
Control Tower law
2. MOST RECENT CANONICAL VERSION
of the article specifically defining the object
3. A101–A109
Taxonomy, ID, registry and card specifications
4. ROOT DEFINITION ARTICLE
for the relevant concept
5. EXTENSION ARTICLE
that develops the concept
6. DYNAMIC OBSERVATORY ARTICLE
for dated current conditions
7. ILLUSTRATIVE OR CASE ARTICLE

Conflict procedure

DETECT CONFLICT
→ IDENTIFY DEFINITION OWNER
→ CHECK VERSION
→ CHECK DATE
→ CHECK EVIDENCE STATUS
→ PRESERVE CANONICAL CLAIM
→ RECORD ALTERNATIVE AS NON-CANONICAL
→ FLAG FOR REVIEW

An AI must not silently rewrite the Atlas to remove disagreement.

17. Canonical Definition Ownership

Each major concept has one primary owner.

Extension articles may refine these concepts but may not silently redefine them.

18. Hallucination Firewall

AI using the Atlas must obey the following firewall.

Rule 1

Do not invent content for an article that is still planned or incomplete.

Rule 2

Do not cite an article title as evidence unless the article contains the supporting argument.

Rule 3

Do not infer a current global coordinate from one statistic or one region.

Rule 4

Do not present Stage 5–8 as inevitable.

Rule 5

Do not call a temporary mission an independent civilisation.

Rule 6

Do not use a biological analogy as direct proof of social policy.

Rule 7

Do not treat a strategy mechanism as ethically legitimate merely because it is effective.

Rule 8

Do not treat a visible artefact as proof that the supporting capability remains alive.

Rule 9

Do not interpret civilisation as one uniform global unit.

Rule 10

Do not replace missing evidence with polished certainty.

Rule 11

Do not silently merge two definitions.

Rule 12

Do not allow a current-status article to overwrite a structural definition.

Rule 13

Do not classify a system as fractured without identifying the broken transfer.

Rule 14

Do not recommend repair without identifying the BaseFloor and sequence.

Rule 15

When uncertain, route to the canonical owner and state what remains unknown.

19. Article Completion Dashboard

The Control Tower should track progress through this structure.

TOTAL ARTICLES:
112
KERNEL:
18
FOUNDATIONAL MAPS:
14
STAGE LIBRARY:
9
TRANSITION LIBRARY:
7
CAPABILITY CORRIDORS:
10
FRACTURE LIBRARY:
14
REPAIR LIBRARY:
10
LIVE OBSERVATORY:
8
MULTI-WORLD LIBRARY:
10
TECHNICAL ARCHITECTURE:
12

Current branch position

Based on the present build sequence:

CIVATLAS-A001–A008:
Drafted
CIVATLAS-A009:
Active build / requires completion
CIVATLAS-A010–A112:
Queued

This status block must be updated as articles become canonical.

20. Master Article Registry

Family K — Atlas Kernel

Family M — Foundational Maps

Family S — Capability Stages

Family T — Stage Transitions

Family C — Capability Corridors

Family F — Fracture Library

Family R — Repair Library

Family O — Live Observatory

Family H — Habitat and Multi-World

Family X — Technical Architecture

21. Family Routing Rules

Kernel questions

Always begin with A001–A018.

These define the Atlas grammar.

Domain questions

Route to A019–A032 after loading the relevant kernel definition.

Stage questions

Route to A033–A041 only after A003 and A013.

Transition claims

Route through A042–A048.

No stage change may be declared without the transition runtime.

Corridor questions

Route through A049–A058.

Corridors explain development across time without treating one artefact as the whole transition.

Fracture questions

Route through A009 and one or more articles from A059–A072.

Repair questions

Route through A010 and the relevant A073–A082 sequence.

Current-state questions

Route through A011 and A083–A090.

Interplanetary questions

Route through A005, A091–A100 and the relevant Stage 6–8 article.

Technical questions

Route through A101–A112.

22. Standard AI Answer Modes

The Control Tower recognises seven output modes.

MODE 1 — EXPLAIN
Define one concept
MODE 2 — LOCATE
Assign an Atlas coordinate
MODE 3 — COMPARE
Compare two systems using common coordinates
MODE 4 — DIAGNOSE
Identify drift, fracture or lifecycle condition
MODE 5 — STRATEGISE
Select candidate movement mechanisms
MODE 6 — REPAIR
Sequence civilisational restoration
MODE 7 — BUILD
Create a new Atlas article, card or registry entry

The AI must identify its mode before producing the final answer.

23. Coordinate Output Standard

When locating a civilisation, the AI should use:

ENTITY:
Name
TIME:
Date or period
SCALE:
Local, regional, state, global, planetary or multi-world
CAPABILITY:
Foundation 0–Stage 8
LIFECYCLE:
Takeoff–Collapse
HABITAT:
H0–H8
DOMINANT MAPS:
Relevant map articles
CONTROL GEOMETRY:
Centralised, distributed, federated, networked or hybrid
BASEFLOOR:
Secure, strained, eroding, breached or recovering
REGENERATIVE CAPACITY:
Extractive, maintenance-dependent, repairing,
regenerative or self-correcting
MOTION VECTOR:
Direction of movement
FRACTURE RISKS:
Active or emerging fractures
REPAIR CAPACITY:
Available corrective capability
EVIDENCE STATUS:
E0–E5
UNCERTAINTY:
What remains unresolved

A coordinate is incomplete without a time and scale.

24. New Article Creation Runtime

When an AI proposes a new Atlas article, it must answer:

1. Does an existing article already own the definition?
2. Is this a new object, a new case or an extension?
3. Which family does it belong to?
4. What is its permanent ID?
5. Which articles are required parents?
6. Which objects does it define?
7. Which objects does it merely illustrate?
8. What must it not redefine?
9. What evidence level can it claim?
10. Which downstream articles should link to it?

A new article should not be approved merely because its title is attractive.

It must occupy a missing coordinate or mechanism.

25. Cross-Branch Continuity Protocol

When work continues in another conversation branch, begin by supplying:

SYSTEM:
Civilisation Atlas
CONTROL TOWER:
CIVATLAS-CT-000 v1.0
CURRENT ARTICLE:
CIVATLAS-A0XX
STATUS:
Planned, drafting, review or canonical
REQUIRED PARENTS:
List article IDs
CANONICAL DEFINITIONS:
List concepts that must remain unchanged
PREVIOUS ARTICLE:
CIVATLAS-A0XX
NEXT ARTICLE:
CIVATLAS-A0XX

The branch should not rely on conversational memory alone.

It should be anchored to permanent article IDs.

26. WordPress Binding Architecture

Every published article should contain five binding elements.

1. Canonical metadata block

Placed near the beginning.

2. Visible Atlas breadcrumb

Example:

Civilisation Atlas
→ Fracture Library
→ Truth Fracture

3. Primary coordinate label

Example:

PRIMARY AXIS:
Lifecycle
OBJECT:
Fracture
FAMILY:
F

4. Contextual internal links

Each article should link to:

• its required parents;
• its direct extensions;
• and two or three important crosswalks.

5. End crosswalk block

This states:

• read before;
• read next;
• related maps;
• object type;
• and non-merger warning.

WordPress categories and tags should support navigation, but the AI binding must depend on IDs and metadata rather than categories alone.

27. Required WordPress Categories

Civilisation Atlas
Atlas Kernel
Civilisation Maps
Capability Stages
Stage Transitions
Capability Corridors
Fracture Atlas
Repair Atlas
Live Observatory
Multi-World Civilisation
Atlas Technical Architecture

28. Required WordPress Tags

Tags should come from controlled vocabularies.

Axis tags

capability-axis
lifecycle-axis
habitat-axis

Stage tags

foundation-0
stage-1
stage-2
stage-3
stage-4
stage-5
stage-6
stage-7
stage-8

Lifecycle tags

takeoff
climb
cruise
drift
descent
repair
relaunch
collapse

Habitat tags

h0
h1
h2
h3
h4
h5
h6
h7
h8

Object tags

Use the canonical object taxonomy in lowercase.

Uncontrolled synonyms should not be added without alias mapping.

29. Control Tower Dashboard

The Control Tower interface should display:

ATLAS COMPLETION
ARTICLE STATUS
CURRENT HUMANITY COORDINATE
CAPABILITY-STAGE READING
LIFECYCLE READING
HABITAT-INDEPENDENCE READING
BASEFLOOR HEALTH
BUILDRATE
DRIFTRATE
REPAIRRATE
CORRIDOR WIDTH
TIME-TO-NODE
MAJOR FRACTURES
ACTIVE REPAIR ZONES
EVIDENCE FRESHNESS
ARTICLES REQUIRING REVIEW

30. The Atlas Integrity Audit

Before any article becomes canonical, the Control Tower should perform this audit.

IDENTITY
Does it have a permanent ID?
OWNERSHIP
Does it know which concept it defines?
DEPENDENCY
Are required parents listed?
NON-MERGER
Does it preserve the three axes?
TAXONOMY
Are object types canonical?
CROSSWALK
Are lateral relationships declared?
EVIDENCE
Are observed and proposed claims separated?
TIME
Are current claims dated?
LOWER FLOOR
Are hidden dependencies recognised?
BASEFLOOR
Is the protected civilisational minimum visible?
INVERSION
Does the article identify how the system may become harmful?
REPAIR
Does it identify correction or recovery where relevant?
AI SUMMARY
Can an AI identify the article’s purpose in one paragraph?
VERSION
Is the active version visible?

An article failing the audit remains R1 rather than C1.

31. Canonical AI Summary Block

Every article should contain a compact AI summary.

AI CANONICAL SUMMARY
This article defines:

[canonical object]

It answers:

[primary question]

It depends on:

[parent article IDs]

It must not be confused with:

[nearby concepts]

Its primary relationship to the Atlas is:

[one sentence]

Its evidence status is: [E0–E5] Its dynamic status is: [structural, semi-dynamic or dynamic]

This summary should remain concise and stable even when the article body expands.

32. Control Tower Retrieval Principle

The AI should retrieve the minimum sufficient connected subgraph, not all 112 articles for every question.

TOO LITTLE RETRIEVAL
creates unsupported answers
TOO MUCH RETRIEVAL
creates noise and concept collision

The correct route normally includes:

1 ROOT DEFINITION
+
REQUIRED PARENTS
+
1–3 RELEVANT CROSSWALKS
+
CURRENT EVIDENCE
where necessary

33. Control Tower Memory Principle

New Atlas learning must be written into one of four places.

DEFINITION UPDATE
Canonical owner article
NEW MECHANISM
Strategy Library or Strategy Card
NEW EVIDENCE
Evidence Card and relevant article
NEW CASE
Case library linked to canonical mechanisms

New information must not remain only inside a conversational branch.

34. Control Tower Escalation Rules

Escalate for human review when:

• two canonical definitions conflict;
• a new top-level object is proposed;
• a stage coordinate changes;
• humanity is proposed to have entered a new stage;
• an H-level is proposed to have been crossed;
• a dynamic claim lacks current evidence;
• an analogy is being used as policy proof;
• an article redefines another article’s canonical concept;
• or a repair recommendation risks crossing the BaseFloor.

35. The Control Tower Lock

The complete binding relationship is:

CT-000
governs the system
A001
introduces the Atlas
A002–A018
define the grammar
A019–A032
map the operating layers
A033–A041
define the capability stages
A042–A048
govern stage transitions
A049–A058
map capability corridors
A059–A072
map fracture
A073–A082
map repair
A083–A090
observe the live system
A091–A100
map multi-world independence
A101–A111
encode and route the Atlas
A112
displays the public Control Tower

36. Compact Machine Control Block

The following block may be given directly to an AI working on the Atlas.

SYSTEM_ID: CIVATLAS
CONTROL_TOWER_ID: CIVATLAS-CT-000
VERSION: 1.0
ARTICLE_RANGE: CIVATLAS-A001..CIVATLAS-A112
PRIMARY_AXES:
  capability:
    owner: CIVATLAS-A003
    values: [Foundation0, Stage1, Stage2, Stage3, Stage4, Stage5, Stage6, Stage7, Stage8]
  lifecycle:
    owner: CIVATLAS-A004
    values: [Takeoff, Climb, Cruise, Drift, Descent, Repair, Relaunch, Collapse]
  habitat:
    owner: CIVATLAS-A005
    values: [H0, H1, H2, H3, H4, H5, H6, H7, H8]
NON_MERGER_RULES:
  - capability_is_not_lifecycle
  - lifecycle_is_not_habitat
  - habitat_is_not_capability
  - artefact_is_not_capability
  - case_is_not_mechanism
  - stress_is_not_fracture
  - repair_is_not_restoration
  - reach_is_not_independence
  - invention_is_not_transition
  - capability_is_not_moral_worth
CANONICAL_FAMILIES:
  K: A001-A018
  M: A019-A032
  S: A033-A041
  T: A042-A048
  C: A049-A058
  F: A059-A072
  R: A073-A082
  O: A083-A090
  H: A091-A100
  X: A101-A112
ANSWER_REQUIREMENTS:
  - identify_object
  - identify_time
  - identify_scale
  - select_primary_axis
  - retrieve_definition_owner
  - retrieve_required_parents
  - retrieve_relevant_crosswalks
  - separate_observed_inferred_proposed_unknown
  - preserve_lower_floor_dependencies
  - state_evidence_status
  - state_uncertainty
CURRENT_CANONICAL_INTERFACE:
  gateway: CIVATLAS-A001
  public_control_tower: CIVATLAS-A112
  machine_controller: CIVATLAS-CT-000
PROHIBITED:
  - merge_primary_axes
  - invent_unpublished_article_content
  - infer_stage_from_one_metric
  - declare_future_stage_as_inevitable
  - classify_mission_as_independent_civilisation
  - use_analogy_as_direct_proof
  - hide_contradictions
  - replace_unknown_with_certainty

Strategic Summary

The 112 Civilisation Atlas articles are not 112 separate essays.

They form one connected machine.

The Control Tower binds them through:

• permanent IDs;
• canonical definitions;
• article families;
• required-parent relationships;
• crosswalks;
• controlled object types;
• evidence states;
• version rules;
• AI routing;
• non-merger laws;
• and integrity audits.

The main architecture is:

ONE CONTROL TOWER
THREE PRIMARY AXES
TEN ARTICLE FAMILIES
112 CANONICAL ARTICLE NODES
ONE CONTROLLED TAXONOMY
ONE CROSSWALK LANGUAGE
ONE EVIDENCE SYSTEM
ONE PUBLIC INTERFACE

The Control Tower prevents the Atlas from becoming an unmapped library.

It ensures that an AI can answer:

• what an object is;
• where it belongs;
• which article defines it;
• what it depends on;
• which concepts must remain separate;
• which fractures threaten it;
• how it may be repaired;
• and how confident the answer should be.

The final lock is:

The Civilisation Atlas becomes an operating system only when every article knows its identity, its parents, its relationships, its evidence status, its place in the three-axis coordinate system and the conditions under which an AI may safely use it.

This document is that binding layer.

CIVATLAS-CT-000
Civilisation Atlas Control Tower v1.0
STATUS:
Canonical controller for Articles 1–112