| .. | ||
| Fixes | ||
| adapter-failure-discipline-v1.md | ||
| adapter-runtime-modes-v1.md | ||
| atlas-final-freeze-v1.md | ||
| atlas-negative-space-report-v1.md | ||
| atlas-to-ai-adapter-v1.md | ||
| atlas-v1-integrated-handoff.md | ||
| canonical-casebook-v1.md | ||
| civilization-bridge-modules-v1.md | ||
| cross-domain-freeze-note-v2.md | ||
| patch-governance-v1.md | ||
| patch-wave-2-freeze-note-v1.md | ||
| provenance-and-derivation-v1.md | ||
| README.md | ||
| release-and-freeze-policy-v1.md | ||
| tiny-planner-output-examples-pack-v1.md | ||
| troubleshooting-atlas-router-v1-usage.md | ||
| validation-basis-v1.md | ||
Atlas Hub
Problem Map 3.0 Troubleshooting Atlas
Folder index, freeze map, routing layer, and system control room
This folder is the structured vault for the Atlas system.
The main product-facing page lives here:
Problem Map 3.0 Troubleshooting Atlas
This README.md is not the public homepage.
It is the system hub for the Atlas folder.
Its job is simple:
- show what documents exist
- show what role each document plays
- show what is already frozen
- show what is patch-driven
- show what is bridge-facing or router-facing
- help humans and AI systems enter the atlas without getting lost
In short:
the main product page introduces the atlas
this hub explains how the atlas folder is organized, frozen, extended, and used
Current status
The current Atlas system should be read as a multi-layer structure with a stable first formal release and multiple formal post-freeze extensions.
At the moment, the following major assets are already established:
- atlas core structure
- negative-space boundary logic
- integrated handoff logic
- canonical casebook layer
- AI adapter layer
- adapter runtime and discipline layer
- patch governance and release policy layer
- first formal patch-wave freeze layer
- first formal cross-domain bridge layer
- provenance and validation layer
- fix and repair-facing layer
- first compact TXT router product layer
This means the project is no longer in the stage of “trying to find the core.”
It is now in the stage of:
- structured extension
- patching
- teaching
- productization
- AI-facing reuse
- router deployment
- repair-surface thickening
- bridge expansion
- provenance strengthening
Recommended reading order
Different readers need different entry paths.
Path A · first-time reader
- Problem Map 3.0 Troubleshooting Atlas
- Atlas Final Freeze v1
- Canonical Casebook v1
- Atlas-to-AI Adapter v1
Use this path if you want the shortest route from “what is this” to “how does this system behave in practice.”
Path B · engineering / system reader
- Atlas Final Freeze v1
- Atlas Negative Space Report v1
- Atlas v1 Integrated Handoff
- Patch Wave 2 Freeze Note v1
- Patch Governance v1
- Release and Freeze Policy v1
Use this path if you want the frozen core, its limits, and the formal rules for how the system grows.
Path C · teaching / onboarding reader
Use this path if you want to teach, explain, demo, or onboard new readers.
Path D · AI adapter / routing reader
- Atlas-to-AI Adapter v1
- Adapter Runtime Modes v1
- Adapter Failure Discipline v1
- Troubleshooting Atlas Router v1 Freeze Note
- Troubleshooting Atlas Router v1 Usage Guide
troubleshooting-atlas-router-v1.txt
Use this path if you want the AI-facing routing layer in both full-spec and compact TXT product form.
Path E · repair / execution reader
Use this path if you want to connect routing to first repair direction and deeper repair-facing work.
Path F · bridge / theory / provenance reader
- Cross-Domain Demonstration Pack v2
- Civilization Bridge Modules v1
- Cross-Domain Freeze Note v2
- Validation Basis v1
- Provenance and Derivation v1
Use this path if you want the strongest current account of why the atlas exists, how it was carved, and how it bridges beyond the AI-first domain.
Folder map
This folder is organized around several major document families.
1. Core atlas documents
These define the stable mother structure.
-
Atlas Final Freeze v1
The positive structure document.
Defines the seven-family mother table, routing rules, canonical layer, subtree layer, relation matrix, fix-facing layer, and patch protocol. -
Atlas Negative Space Report v1
The limit and boundary document.
Defines what remains intentionally open, weak, unpromoted, or patch-sensitive. -
Atlas v1 Integrated Handoff
The official delivery overview.
Explains howFinal Freeze v1andNegative Space v1should be read together.
2. Teaching and case documents
These teach how to actually use the atlas.
- Canonical Casebook v1
The first formal teaching layer.
Includes family anchor cases, boundary teaching cases, and repair teaching cases.
3. AI-facing adapter documents
These compress atlas logic into a reusable routing layer for models and systems.
-
Atlas-to-AI Adapter v1
The main AI adapter asset.
Includes core contract, routing stack, casebook injection logic, runtime modes, patch interface, and adapter discipline. -
Adapter Runtime Modes v1
The first formal runtime-mode layer.
Defines strict, teaching, repair-first preview, and compact routing behavior. -
Adapter Failure Discipline v1
The first formal adapter-discipline page.
Defines how the routing layer avoids drift, false confidence, premature repair, and mode confusion.
4. Router product documents
These turn the Atlas routing grammar into a compact TXT product.
-
troubleshooting-atlas-router-v1.txt
The first formal route-first TXT pack.
Designed for compact failure classification, boundary-aware diagnosis, broken-invariant reading, and first-fix guidance. -
Troubleshooting Atlas Router v1 Freeze Note
The formal product freeze note.
Defines what Router v1 now stabilizes and what it does not claim. -
Troubleshooting Atlas Router v1 Usage Guide
The practical usage guide.
Explains how to use the Router, what kind of input it needs, and how to interpret its output. -
Troubleshooting Atlas Router v1 Product Spec Freeze
The product-spec freeze document for the Router line.
Useful if you want to see the original MVP scope, output contract, and construction boundary.
5. Patch and governance documents
These define how the atlas grows without silently mutating the core.
-
Patch Wave 2 Freeze Note v1
The formal freeze point for the first major patch wave after v1. -
Patch Governance v1
Defines small patch, medium patch, large patch, and patch discipline. -
Release and Freeze Policy v1
Defines how releases, freezes, patch nodes, and superseded assets should be handled.
6. Cross-domain bridge documents
These show how the atlas extends beyond narrow AI-only reading.
-
Cross-Domain Demonstration Pack v2
The first formal bridge evidence pack.
Shows that the mother structure can absorb selected coordination, institutional, coherence, and broader complex-system pressures. -
Civilization Bridge Modules v1
Defines the current bridge modules that connect the AI-first atlas to more general complex-system failure space. -
Cross-Domain Freeze Note v2
Formal freeze wording for the current bridge layer.
7. Validation and provenance documents
These explain where the mother structure came from and why it should be trusted.
-
Validation Basis v1
The first formal validation summary.
Explains what kind of stress basis, routing pressure, and structural confidence support the current atlas. -
Provenance and Derivation v1
Explains how the atlas mother structure emerged through WFGY 1.0, 2.0, 3.0, and stress-driven carving.
8. Fix and repair-facing documents
These connect atlas diagnosis to first repair direction and deeper repair work.
- Fixes Hub
The main repair-facing entry point.
Connects official fixes, community fix lab, templates, demos, and advanced repair directions.
What is already frozen
The following can now be treated as stable first-version assets.
Frozen atlas body
- seven-family mother table
- major family boundary rules
- canonical node layer
- family-entry layer
- high-value subtree layer
- relation matrix v1
- patch protocol
Frozen teaching body
- first canonical casebook structure
- family anchor cases
- boundary teaching cases
- repair teaching cases
Frozen AI adapter body
- adapter contract
- routing stack
- runtime discipline
- failure discipline
- model-facing routing logic
Frozen router body
- Troubleshooting Atlas Router v1 as a formal TXT routing product
- route-first output contract
- first compact boundary pack
- first mini exemplar layer
- first-fix discipline in compact form
Frozen repair-facing body
- first repair-facing entry layer
- family fix surface direction
- official fixes hub structure
- first flagship repair demos
Frozen governance body
- first major patch-wave node
- patch-governance rules
- release-and-freeze policy
Frozen bridge body
- first cross-domain demonstration pack
- first bridge modules
- first bridge freeze wording
What is intentionally not fully frozen
The system is stable, but not fully closed.
The following areas remain intentionally open or patch-sensitive:
- work-branches not yet promoted
- weak or medium relations
- deeper subtree thickening
- broader cross-domain evidence
- stronger repair-surface integration
- more compact and deployable TXT layers beyond Router v1
- public packaging refinement
- deeper auto-repair planning layers
- later router patches and future router variants
- stronger bridge-to-civilization packaging
This is not a weakness.
It is part of the Atlas design discipline.
The current project is meant to be:
frozen at the core,
open at the edges,
and disciplined in growth
Cross-domain and civilization bridge direction
This atlas is currently grounded in AI troubleshooting, routing, teaching, repair-first workflows, and AI-facing routing products.
Its current formal state should be understood as:
- AI-first in its strongest validated public form
- already strong enough to support formal bridge work
- already strong enough to support first cross-domain canonical packs
- designed to grow through disciplined expansion rather than silent redefinition
Current bridge-facing materials already include:
- coordination and consensus pressures
- institutional drift and closure failures
- value, probability, knowledge, and coherence pressures
- broader complex-system failure framing
This should be read as a formal bridge layer, not as a claim of universal end-state completion.
What future work should not do
Future work should not:
- silently rewrite frozen structures
- promote branches by rhetoric alone
- flatten family, node, subtree, bridge, router, and overlay into one level
- confuse patching with core instability
- overstate bridge evidence as universal closure
- erase the distinction between core docs, product assets, and support documents
- pretend Router v1 is already a full repair engine
- collapse the difference between route-first repair and full auto-repair
These rules matter because the atlas is now a versioned system, not a floating concept.
What future work should do
The highest-value next directions are:
Repair-surface thickening
Strengthen the diagnosis-to-repair layer and keep the bridge into deeper repair logic clean.
Router deployment and refinement
Test and patch compact route-first TXT behavior through explicit versioning.
Demo expansion
Build cleaner human-facing and AI-facing demos.
Cross-domain bridge expansion
Extend the atlas carefully beyond AI-first troubleshooting without overclaiming total completion.
Product-facing distillation
Make the system easier to enter without flattening the structure.
Later patch waves
Continue strengthening the system through explicit patch nodes rather than silent mutation.
Official wording
When describing the current system in a new window, collaboration thread, or product workflow, use wording like this:
Problem Map 3.0 Troubleshooting Atlas now has a frozen first body of core atlas documents, a canonical teaching layer, an AI-facing routing adapter, a repair-facing fix layer, a formal patch-governance layer, a first cross-domain bridge layer, and a compact TXT routing product in Troubleshooting Atlas Router v1.
Future work proceeds through patching, thickening, productization, router refinement, and controlled bridge expansion.
This wording is strong, accurate, and safe.
Practical usage guide
For product work
Start with:
For system and routing work
Start with:
For teaching and onboarding
Start with:
For repair and execution work
Start with:
For bridge and provenance framing
Start with:
- Cross-Domain Demonstration Pack v2
- Civilization Bridge Modules v1
- Validation Basis v1
- Provenance and Derivation v1
For governance and version discipline
Start with:
One-line status
The Atlas core is frozen, the teaching layer exists, the AI adapter exists, the governance layer exists, the first cross-domain bridge exists, the repair-facing layer exists, and Troubleshooting Atlas Router v1 now exists as a formal compact TXT routing product. Further work proceeds in patch mode and controlled bridge expansion.
Closing note
This folder is where the atlas becomes a real system.
The main page tells you what the product is.
This hub tells you how the system is organized.
The linked documents tell you how to use it, teach it, extend it, connect it to repair-facing workflows, deploy it in compact TXT form, and bridge it toward broader complex-system reasoning.
If the main product page is the front gate, this folder is the control room.