WFGY/ProblemMap/Atlas/atlas-structure-map-v1.md
2026-03-20 14:52:39 +08:00

25 KiB

Atlas Structure Map 🗺️

Problem Map 3.0 Troubleshooting Atlas

Quick links, layer map, reading paths, and document relationships for the Atlas system

This page exists for one simple reason:

many readers can already see that the Atlas has multiple files, but they still cannot tell how those files connect.

Some people open the public page first.
Some people jump straight into the router TXT.
Some people land in the hub, the fixes folder, or the freeze docs.

That is normal.

What is missing is a clean public page that explains:

  • what the major Atlas layers are
  • what each layer does
  • where new readers should begin
  • how the files relate to each other
  • what should be read as core, support, product surface, or bridge material

This page is that map.


If you are new, start here.

I just want the shortest beginner path

I want the folder control room

I want the stable core

I want the AI-facing routing layer

I want proof, examples, and demos

I want repair-facing materials

I want governance, validation, and bridge framing


Why this page exists

The Atlas has already grown beyond the stage where a single file can explain everything clearly.

At this point, the system includes:

  • a public-facing product page
  • a folder hub
  • frozen core documents
  • teaching and example documents
  • an AI-facing adapter
  • a compact router product
  • repair-facing materials
  • evidence and demo materials
  • governance documents
  • provenance and validation materials
  • cross-domain bridge materials

That is strong, but it also creates a very normal problem:

new readers can see the pieces, but they do not always know which piece comes first or why each piece exists.

So this page does not add a new theory.
It adds a new kind of readability.

It turns the Atlas from a file collection into a visible structure.


Scope

This page focuses on:

  • system structure
  • document layers
  • reading order
  • role separation
  • how major documents connect

This page does not try to do the job of the more detailed pages.

It does not define the seven families in full.
It does not settle boundary cases.
It does not provide the fit registry.
It does not replace the router usage guide.
It does not replace the freeze docs.

Its job is to help readers know where they are before they go deeper.


What this page covers

This page covers five practical questions.

1. What are the main Atlas layers?

It explains the system as a layered structure rather than a flat list of files.

2. Where should different readers begin?

It gives beginner, builder, research, repair, and bridge paths.

3. Which files are core, and which files are support?

It separates frozen core from support, product, demo, and bridge materials.

4. How do the layers connect?

It shows the rough flow from overview to routing to repair and extension.

5. What should not be confused?

It marks several important distinctions so readers do not flatten the system into one level.


What this page does not cover

This page does not do the following:

  • it does not define the seven-family mini-specs in detail
  • it does not give the boundary decision rules
  • it does not enumerate subtrees
  • it does not formalize fit promotion
  • it does not define output contracts in full
  • it does not replace the router TXT pack
  • it does not act as a proof surface by itself
  • it does not declare any new frozen core language

Those tasks belong to other Atlas pages.


Atlas as a layered system 🧱

The Atlas should be read as a layered system.

Not every file lives at the same level, and not every file serves the same kind of reader.

Layer 1. Public entry layer

This is where a new reader first understands what the Atlas is and why it exists.

Primary document:

Use this layer when:

  • you want the product-facing introduction
  • you want the big picture first
  • you are not ready to read the deeper folder stack yet

Layer 2. Hub and navigation layer

This is where the Atlas folder becomes a controlled, navigable system.

Primary document:

Use this layer when:

  • you want the folder control room
  • you want the current document inventory
  • you want to see frozen, support, and planned layers in one place

Layer 3. Frozen core layer

This is where the first stable core body lives.

Primary documents:

Use this layer when:

  • you want the stable mother structure
  • you want the explicit limits of the current freeze
  • you want to understand what is strong and what remains intentionally open

Layer 4. Teaching and interpretation layer

This is where the Atlas becomes easier to teach and easier to see in action.

Primary documents:

Use this layer when:

  • you want examples
  • you want teaching material
  • you want smaller practical output shapes before reading the deeper stack

Layer 5. AI-facing adapter layer

This is where Atlas logic becomes model-facing and reusable in a structured routing form.

Primary documents:

Use this layer when:

  • you want the full routing logic for AI systems
  • you want runtime modes
  • you want discipline rules that reduce drift and false confidence

Layer 6. Compact router product layer

This is where the route-first idea becomes a compact TXT product that people can actually try fast.

Primary documents:

Use this layer when:

  • you want to test the routing surface quickly
  • you want the shortest path from concept to practice
  • you want a compact route-first artifact rather than the full adapter stack

Layer 7. Repair-facing layer

This is where route-first reading starts pointing toward practical repair direction.

Primary document:

Use this layer when:

  • you want first repair direction after routing
  • you want official fixes and repair-facing structure
  • you want the execution-facing side of the Atlas

Layer 8. Evidence and demo layer

This is where the public proof surface becomes easier to inspect.

Primary documents:

Use this layer when:

  • you want public evidence
  • you want demos
  • you want a clearer proof surface without reading every core file first

Layer 9. Governance layer

This is where controlled growth is formalized.

Primary documents:

Use this layer when:

  • you want version discipline
  • you want patch rules
  • you want to understand how Atlas grows without silent mutation

Layer 10. Validation, provenance, and bridge layer

This is where the Atlas explains why it exists, where it came from, and how it extends beyond narrow AI-only framing.

Primary documents:

Use this layer when:

  • you want structural justification
  • you want derivation and validation context
  • you want cross-domain and civilization-facing framing

Layer 11. Planned public decomposition layer

This is the next wave of public pages that clarify the middle structure between the frozen core and the compact router.

Planned documents:

Use this layer when:

  • you want the public middle layer to become more readable
  • you want family, boundary, subtree, fit, and contract structure made explicit
  • you want clarification without silently changing the frozen core

Structure summary table 📚

Layer Main job Main starting files
Public entry Introduce the Atlas Problem Map 3.0 Troubleshooting Atlas
Hub Control room and folder map Atlas Hub
Frozen core Stable mother structure and limits Atlas Final Freeze v1, Atlas Negative Space Report v1, Atlas v1 Integrated Handoff
Teaching Cases and smaller examples Canonical Casebook v1, Tiny Planner Output Examples Pack v1
Adapter Full AI-facing routing logic Atlas-to-AI Adapter v1, Adapter Runtime Modes v1, Adapter Failure Discipline v1
Router Compact route-first product Troubleshooting Atlas Router v1 TXT Pack, Troubleshooting Atlas Router v1 Usage Guide, Troubleshooting Atlas Router v1 Freeze Note
Repair First repair direction Fixes Hub
Evidence and demos Public proof surface AI Eval Evidence, Cross-Domain Demonstration Pack v2
Governance Version and patch discipline Patch Wave 2 Freeze Note v1, Patch Governance v1, Release and Freeze Policy v1
Validation and bridge Why it exists, where it came from, where it can extend Validation Basis v1, Provenance and Derivation v1, Cross-Domain Freeze Note v2, Civilization Bridge Modules v1
Planned public decomposition Middle-layer clarification Atlas Family Mini-Specs v1, Atlas Boundary Decision Guide v1, Atlas Subtree Expansion Index v1

How the layers connect 🔗

The Atlas is easier to read if you think of it as a flow.

Flow A. New reader flow

Start with the product page, then move to the router usage guide, then try the TXT, and only after that open the hub or the freeze docs.

Recommended path:

Flow B. Structural reader flow

Start with the hub, then read the frozen core, then the negative space, then the integrated handoff.

Recommended path:

Flow C. AI routing flow

Start with the adapter stack, then move into the router surface.

Recommended path:

Flow D. Route-to-repair flow

Start with route-first materials, then move into fixes.

Recommended path:

Flow E. Proof and credibility flow

Start with evidence and demo materials, then move back into the structural documents.

Recommended path:

Flow F. Bridge and expansion flow

Start with provenance and bridge documents after the core structure is already understood.

Recommended path:


Beginner-friendly entry paths 🌱

Not every reader wants the same thing.

Path A. I just want to try something fast

Go here:

Path B. I want to know what this product is

Go here:

Path C. I want the real structure

Go here:

Path D. I want examples and proof

Go here:

Path E. I want repair-facing direction

Go here:


Important distinctions that readers should not flatten

The Atlas becomes much easier to understand once a few distinctions are kept clean.

The product page is not the hub

The public page introduces the Atlas.
The hub manages the folder and its current document structure.

Read:

The hub is not the frozen core

The hub tells you where things are.
The freeze docs tell you what the stable core body actually is.

Read:

The adapter is not the same as the compact router

The adapter is the fuller AI-facing routing layer.
The router is a compact product surface.

Read:

The router is not the full repair engine

The router helps classify and point toward first repair direction.
It should not be mistaken for total auto-repair closure.

Read:

Evidence pages are not the same as core-definition pages

Evidence and demo pages strengthen the public proof surface.
They do not replace the core freeze documents.

Read:

Planned public decomposition pages are not silent rewrites

The coming middle-layer pages clarify the system.
They are not retroactive changes to the frozen core.

Planned pages include:


Practical use

Here is the simplest practical reading advice.

If you are completely new, do not start from the deepest theory stack.

Start in this order:

  1. Problem Map 3.0 Troubleshooting Atlas
  2. Troubleshooting Atlas Router v1 Usage Guide
  3. Troubleshooting Atlas Router v1 TXT Pack
  4. Atlas Hub

If that already makes sense, then go deeper:

  1. Atlas Final Freeze v1
  2. Atlas Negative Space Report v1
  3. Canonical Casebook v1

After that, choose your branch:

  • for AI system routing, go to the adapter stack
  • for repair-facing direction, go to the fixes layer
  • for proof surface, go to evidence and demos
  • for bridge and provenance, go to validation and bridge materials

That is the simplest stable reading rhythm right now.


Relation to other Atlas docs

This page connects most directly to the following documents.

Closest neighbor

Reason: this page explains the structure of the Atlas system, while the hub manages the folder-level navigation and current document inventory.

Core neighbor

Reason: this page tells readers where the core sits, but the freeze page still defines the actual stable core body.

Beginner neighbor

Reason: many readers should still see the public-facing introduction before reading this structure page.

Future middle-layer neighbors

Reason: this page explains the overall structure first, then those pages will fill in the middle layer later.


Current status

This page should be read as a public structure map.

That means:

  • it is stable enough to guide readers
  • it does not replace the frozen core
  • it does not overclaim middle-layer completion
  • it improves readability without silently mutating the Atlas

At the moment, its value is practical:

it gives new readers a safe map, and it gives older readers a cleaner way to explain the Atlas to other people.


Future extension

This page will become even stronger once the planned middle-layer pages exist.

The most important next companions are:

Once those pages are written, readers will be able to move from:

structure map
to family map
to boundary map
to subtree map
to fit and repair discipline

That will make the Atlas much easier to study without forcing everyone to reverse-engineer the compact router or read the full freeze stack first.


Closing note 🔭

The Atlas is already more than a single page, a single PDF, or a single TXT pack.

It is now a document system with layers.

The public page helps people enter.
The hub helps people navigate.
The frozen core defines the stable body.
The adapter and router make the logic usable.
The fixes layer points toward repair.
The evidence and demo layer make the proof surface easier to inspect.
The governance layer keeps growth disciplined.
The validation, provenance, and bridge layer explains why the Atlas exists and how far it can responsibly extend.

This page sits in the middle of that picture.

Its job is simple:

help people see the Atlas as a structure before they try to master the deeper parts.