Quick links:
- Back to Atlas landing page
- Back to Atlas Hub
- Open Atlas Final Freeze v1
- Open Atlas Negative Space Report v1
- Open Atlas v1 Integrated Handoff
- Open Atlas-to-AI Adapter v1
- Open Case Format v1
If the Atlas core defines the map, this file is the first formal guide that teaches people and AI systems how to actually walk that map in practice. 🧭
This document does not replace the Atlas core.
It shows what the Atlas looks like when it becomes:
- teachable
- routable
- demo-friendly
- AI-readable
- repair-aware
Short version:
the Atlas defines the grammar
the casebook teaches how to use the grammar
the adapter later operationalizes that teaching for AI systems
That is the job of this file.
Use this path:
- read Atlas Final Freeze v1
- read this file
- read Atlas Negative Space Report v1
- read Atlas-to-AI Adapter v1 if you want AI-facing reuse
Start here:
- read Section 5 for the standard case format
- read Part I for the seven family anchors
- read Part II for the major boundary cuts
- read Part III for diagnosis-to-repair flow
- read Section 9 for patch protocol
Shortest possible reading:
family anchors teach what each family is
boundary cases teach where the knife-cut matters
repair cases teach why diagnosis changes the first move
This document is the frozen teaching and exemplar companion to Atlas v1.
It exists to provide a stable first case layer that helps humans and AI systems learn:
- how to route a case into the Atlas
- how to distinguish neighboring family cuts
- how diagnosis changes the first repair move
- how to use the Atlas as a practical troubleshooting grammar
This version is called Canonical Casebook v1.
It is frozen not because all future cases have already been collected, but because the first stable teaching set is now strong enough to function as the first formal casebook version.
Future work should proceed through casebook patch mode, not by silently rewriting the teaching structure.
The Atlas defines the map.
The casebook teaches how to walk the map.
If the Atlas core provides:
- family structure
- node structure
- routing rules
- boundary cuts
- relation logic
- repair-facing interfaces
then the casebook provides:
- representative family anchors
- difficult boundary exemplars
- diagnosis-to-repair teaching examples
- reusable routing demonstrations
- AI-readable example patterns
In short:
the Atlas defines the grammar
the casebook teaches how to use the grammar
Canonical Casebook v1 contains three layers.
One anchor case for each of the seven main families.
Purpose:
- teach the most basic meaning of each family
- give the cleanest first example for humans
- give AI systems a stable first exemplar set
A curated set of cases chosen because they sit near important family boundaries.
Purpose:
- teach why a case belongs to one family instead of a neighboring family
- teach the core knife-cuts of the Atlas
- reduce confusion in high-pressure routing zones
A curated set of cases chosen because they best demonstrate diagnosis-to-repair flow.
Purpose:
- show how correct routing changes the first repair move
- show how misrepair begins when routing goes wrong
- connect the Atlas to repair-facing thinking without pretending the full repair system is already complete
Canonical Casebook v1 claims that the following are now stable enough to freeze:
- the first 7 family anchor cases
- the first 6 boundary teaching cases
- the first 6 repair teaching cases
- the first stable case format
- the first reusable diagnosis-to-repair teaching layer
- the first reusable exemplar pack for AI-facing routing
This means the casebook is now stable enough to support:
- onboarding
- README explanation
- product copy support
- demo storyboard design
- AI routing exemplars
- future casebook patch waves
Canonical Casebook v1 does not claim that:
- all important cases have already been collected
- every family boundary is fully covered by examples
- every repair family already has all best possible exemplars
- all cross-domain exemplars are already included
- no future casebook patching is needed
Canonical Casebook v1 claims only that:
the first stable teaching set of family anchors, boundary cuts, and diagnosis-to-repair exemplars has been completed and frozen as the first formal casebook version
All canonical cases in v1 use the following stable structure:
- Case ID / Name
- Primary Family
- Secondary Family
- Why Primary Not Secondary
- Broken Invariant
- Best Current Fit
- Fix Surface Direction
- Why This Case Matters
This format is frozen in v1 because it is:
- compact enough for repeated use
- clear enough for engineering readers
- structured enough for AI systems
- reusable in future patch waves
For format discipline, see also Case Format v1.
These seven cases serve as the first anchor teaching set for the seven-family mother table.
They answer the most basic question:
what does each family look like when it appears in practice
Primary Family
F1 Grounding & Evidence Integrity
Secondary Family
F5 Observability & Diagnosability Integrity
Why Primary Not Secondary
The main failure is not merely that the error is hard to inspect.
The main failure is that the answer no longer remains anchored to the relevant evidence or retrieval source.
Broken Invariant
evidence-anchor integrity broken
Best Current Fit
F1_N01 Retrieval Anchor Drift
Fix Surface Direction
- re-grounding
- chunk-to-target trace
- evidence verification
- anchor re-check
Why This Case Matters
This is one of the best introductory cases for teaching that many “hallucination-like” failures are grounding failures first.
Primary Family
F2 Reasoning & Progression Integrity
Secondary Family
None
Why Primary Not Secondary
The primary failure lies in the breakdown of interpretation and reasoning progression, not in continuity, grounding, or representation.
Broken Invariant
interpretation progression integrity broken
Best Current Fit
F2_N01 Interpretation Collapse
Fix Surface Direction
- decomposition reset
- alternate parse validation
- interpretation checkpoint insertion
Why This Case Matters
This is one of the cleanest examples of a genuine reasoning-first failure.
Primary Family
F3 State & Continuity Integrity
Secondary Family
None
Why Primary Not Secondary
The primary failure lies in cross-session continuity loss, not in protocol closure or execution skeleton failure.
Broken Invariant
session continuity broken
Best Current Fit
F3_N01 Memory Continuity Failure
Fix Surface Direction
- memory persistence guard
- session carryover audit
- continuity restoration
Why This Case Matters
This is one of the best cases for teaching what a continuity-first failure actually looks like.
Primary Family
F4 Execution & Contract Integrity
Secondary Family
None
Why Primary Not Secondary
The primary failure lies in liveness collapse and execution deadlock, not in reasoning or visibility.
Broken Invariant
deployment liveness closure broken
Best Current Fit
F4_N02 Deployment Deadlock
Fix Surface Direction
- liveness watchdog
- deadlock break routine
- fallback execution route
Why This Case Matters
This case shows that the Atlas can handle runtime and deployment-level failures, not just language-level mistakes.
Primary Family
F5 Observability & Diagnosability Integrity
Secondary Family
F4 Execution & Contract Integrity
Why Primary Not Secondary
The main failure is that the failure path itself is not visible enough to diagnose.
Execution may or may not later prove to be broken, but diagnosability fails first.
Broken Invariant
failure-path visibility broken
Best Current Fit
F5_N01 Failure Path Opacity
Fix Surface Direction
- observability insertion
- trace exposure
- diagnostic logging uplift
Why This Case Matters
This is one of the strongest demonstrations of why F5 must exist as its own family.
Primary Family
F6 Boundary & Safety Integrity
Secondary Family
F5 Observability & Diagnosability Integrity
Why Primary Not Secondary
The primary failure lies in boundary instability itself, not merely in missing visibility or oversight.
Broken Invariant
alignment boundary integrity broken
Best Current Fit
F6_N01 Alignment Boundary Drift
Fix Surface Direction
- alignment guard
- target-boundary re-anchor
- proxy-goal separation
Why This Case Matters
This is a flagship case for teaching what a real boundary-first failure looks like.
Primary Family
F7 Representation & Localization Integrity
Secondary Family
F2 Reasoning & Progression Integrity
Why Primary Not Secondary
The primary failure lies in the inability of the formal or logical descriptor to faithfully carry reasoning structure.
Broken Invariant
formal descriptor fidelity broken
Best Current Fit
F7_N01_A Logic Descriptor Fidelity Failure
Fix Surface Direction
- descriptor fidelity audit
- formal adequacy validation
- logic-structure preservation
Why This Case Matters
This is one of the clearest examples of a container-first rather than progression-first failure.
These cases are selected because they teach the most important family cuts in the current Atlas.
They answer the harder question:
why is this case in one family instead of the neighboring one
Primary Family
F1 Grounding & Evidence Integrity
Secondary Family
F7 Representation & Localization Integrity
Why Primary Not Secondary
The main failure is that proxy similarity is incorrectly treated as true semantic alignment.
This is grounding-first, not container-first.
Broken Invariant
semantic target grounding broken
Best Current Fit
F1_N02 Semantic Grounding Mismatch
Fix Surface Direction
- semantic anchor checks
- proxy / true-meaning separation
- target-reference audit
Why This Case Matters
This is one of the best teaching cases for the F1 / F7 boundary.
Primary Family
F7 Representation & Localization Integrity
Secondary Family
F2 Reasoning & Progression Integrity
Why Primary Not Secondary
The symbolic or formal carrier itself fails to remain faithful enough to support reasoning structure.
The main failure is in the representational shell, not in reasoning progression first.
Broken Invariant
symbolic carrier fidelity broken
Best Current Fit
F7_N01 Symbolic Representation Fidelity Failure
More specifically: F7_N01_A Logic Descriptor Fidelity Failure
Fix Surface Direction
- descriptor fidelity audit
- formal adequacy validation
- logic-structure preservation
Why This Case Matters
This is one of the strongest cases for teaching the F2 / F7 cut.
Primary Family
F5 Observability & Diagnosability Integrity
Secondary Family
F6 Boundary & Safety Integrity
Why Primary Not Secondary
The main failure currently appears first in coherence visibility, meaning-profile visibility, and auditability of value / information / knowledge structure.
Boundary pressure is strong, but not the first failure layer.
Broken Invariant
coherence-profile visibility broken
Best Current Fit
F5 / F6 boundary-edge fit
Fix Surface Direction
- coherence visibility uplift
- meaning-profile tracing
- normative consistency audit
- then boundary stabilization if needed
Why This Case Matters
This is one of the most important high-abstract boundary cases for the F5 / F6 cut in v1.
Primary Family
F1 Grounding & Evidence Integrity
Secondary Family
F7 Representation & Localization Integrity
Why Primary Not Secondary
The main failure lies in extracting truth-like anchors from synthetic worlds, not in the synthetic container itself failing first.
Broken Invariant
synthetic truth-anchor grounding broken
Best Current Fit
F1_E01 Synthetic Truth Grounding
Fix Surface Direction
- truth-like anchor check
- synthetic target grounding audit
- referent extraction validation
Why This Case Matters
This is a flagship boundary case for the F1 / F7 synthetic cut.
Primary Family
F3 State & Continuity Integrity
Secondary Family
F6 Boundary & Safety Integrity
Outer Pressure
F4 Execution & Contract Integrity
Why Primary Not Secondary
The current best cut is that agent-level continuity threads fail first, not collective-boundary regime or protocol closure.
Broken Invariant
multi-agent continuity thread broken
Best Current Fit
F3_E01 Multi-Agent Continuity Instability
Fix Surface Direction
- role fencing
- ownership tracing
- continuity restoration
- then protocol or boundary repair if needed
Why This Case Matters
This is one of the best cases for teaching the F3 / F4 / F6 outer-pressure boundary.
Primary Family
F4 Execution & Contract Integrity
Secondary Family
F6 Boundary & Safety Integrity
Why Primary Not Secondary
The main failure currently appears first in rule-to-action closure, enforcement drift, and accountability thinning, not in collective boundary legitimacy first.
Broken Invariant
institutional enforcement closure broken
Best Current Fit
F4_E01 Institutional Enforcement Drift
Fix Surface Direction
- rule-to-action trace
- enforcement bridge checks
- accountability route repair
Why This Case Matters
This is one of the strongest cases for teaching the F4 / F6 cut at the institutional layer.
These cases are selected because they best demonstrate diagnosis-to-repair flow.
They answer the practical question:
once the route is correct, what kind of first move becomes correct
Primary Family
F1 Grounding & Evidence Integrity
Secondary Family
F5 Observability & Diagnosability Integrity
Why Primary Not Secondary
The output is no longer tied to the correct evidence source, so grounding fails before diagnosis support becomes the main issue.
Broken Invariant
evidence-anchor integrity broken
Best Current Fit
F1_N01 Retrieval Anchor Drift
Fix Surface Direction
- re-grounding
- chunk-to-target trace
- evidence verification
- anchor re-check
Why This Case Matters
This case teaches that hallucination-like behavior often requires a grounding-first repair move.
Primary Family
F3 State & Continuity Integrity
Broken Invariant
session continuity broken
Best Current Fit
F3_N01 Memory Continuity Failure
Fix Surface Direction
- memory persistence guard
- session carryover audit
- continuity restoration
Why This Case Matters
This case teaches that continuity failures usually require continuity infrastructure, not simply more instruction text.
Primary Family
F4 Execution & Contract Integrity
Broken Invariant
deployment liveness closure broken
Best Current Fit
F4_N02 Deployment Deadlock
Fix Surface Direction
- liveness watchdog
- deadlock break routine
- fallback execution route
Why This Case Matters
This case teaches that execution deadlocks require liveness repair first, not reasoning repair first.
Primary Family
F5 Observability & Diagnosability Integrity
Secondary Family
F4 Execution & Contract Integrity
Broken Invariant
failure-path visibility broken
Best Current Fit
F5_N01 Failure Path Opacity
Fix Surface Direction
- observability insertion
- trace exposure
- diagnostic logging uplift
Why This Case Matters
This case teaches that sometimes the correct first repair move is to expose the failure path before committing to a deeper family repair.
Primary Family
F5 Observability & Diagnosability Integrity
Secondary Family
F6 Boundary & Safety Integrity
Broken Invariant
pre-failure warning visibility broken
Best Current Fit
F5_E02 Early Warning Deficit
More specifically:
- F5_E02_A Fragility Signature Blindness
or - F5_E02_B Regime-Shift Warning Delay
Fix Surface Direction
- fragility signature extraction
- warning horizon extension
- pre-transition detector
- delay-sensitive alerting
Why This Case Matters
This case teaches that pre-failure warning capability is itself a first-class repair target, not just a supporting tool.
Primary Family
F6 Boundary & Safety Integrity
Secondary Family
F5 Observability & Diagnosability Integrity
Broken Invariant
alignment boundary integrity broken
Best Current Fit
F6_N01 Alignment Boundary Drift
Fix Surface Direction
- alignment guard
- target-boundary re-anchor
- proxy-goal separation
- control-path and intervention-margin review
Why This Case Matters
This case teaches that some problems remain boundary-first even after visibility is improved.
Canonical Casebook v1 matters because it turns the Atlas from a structural reference into a teaching and routing system.
It now teaches three things:
through the family anchor cases
through the boundary case pack
through the repair case pack
In other words:
the Atlas supplies the failure grammar
the casebook teaches how to use it
This casebook can now be used as:
- a teaching companion to Atlas Final Freeze v1
- a case-based onboarding document
- an AI routing exemplar set
- a README and documentation source
- a demo storyboard source
- a patch-wave baseline for future case additions
When using it in a new working context, treat it as the frozen casebook mainline and treat future additions as casebook patches.
This document depends on the Atlas core.
Use the Atlas core to understand:
- family structure
- routing rules
- canonical layout
- subtree structure
- relation lines
Use this casebook to understand:
- what those structures look like in practice
- how boundary cuts behave in real teaching cases
- how first repair moves depend on correct routing
This is why the casebook should be read after the core Atlas, not before it.
This casebook is also one of the foundations of the AI-facing adapter layer.
It supports:
- exemplar injection
- family anchor support
- boundary teaching support
- repair-preview support
That is why this document should be read alongside:
The adapter compresses the routing grammar.
The casebook supplies the teaching exemplars that help make that compression stable.
Canonical Casebook v1 is frozen, but not closed.
Use for:
- adding one or two new canonical cases
- confidence upgrades
- better secondary-family explanations
- improved fit notes
Use for:
- adding a new boundary teaching pack
- adding a new repair teaching pack
- adding a cross-domain demonstration pack
- adding a negative example pack
Only use if:
- major family boundaries require re-teaching
- multiple canonical cases become unstable under new Atlas patches
- the teaching structure itself must be redesigned
No large-patch pressure is currently justified.
Canonical Casebook v1 is now considered formally frozen.
Its current structure includes:
- 7 family anchor cases
- 6 boundary cases
- 6 repair cases
This means the first full teaching layer of the Atlas now exists.
Further work should continue in patch mode.
After this page, most readers continue with:
If you want the broader Atlas surface:
- Back to Atlas Final Freeze v1
- Back to Atlas Negative Space Report v1
- Back to Atlas Hub
- Back to Atlas landing page
Canonical Casebook v1 is frozen. Further casebook work proceeds in patch mode.
A strong Atlas is not enough by itself.
People and AI systems also need:
- clear first examples
- reliable boundary teaching
- repair-aware routing demonstrations
That is what this casebook is for.
If the Atlas is the map, this document is the first formal guide for learning how to move through it.