Quick links:
- Back to Atlas landing page
- Get the Router TXT Pack
- Open the Router Freeze Note
- Open Atlas Final Freeze v1
- Back to Atlas Hub
- Open Official Flagship Demos
This guide explains how to use Troubleshooting Atlas Router v1 in real troubleshooting work.
Its purpose is simple:
show what the Router is for
when to use it
what kind of input to provide
what kind of output to expect
and how to read that output correctly
This is a usage guide.
It is not the full Atlas.
It is not the full teaching layer.
It is not the full repair engine.
It is the practical onboarding page for using the Router well.
Short version:
load the TXT
paste one real case
ask for route-first output
read the cut before you touch the fix
If you want the shortest practical path, do this:
- download the Router TXT Pack
- paste the TXT into ChatGPT, Claude, Gemini, Copilot, Cursor, or your preferred model
- paste one real case below it
- use the minimal prompt below
- read the output in this order:
primary_familywhy_primary_not_secondarybroken_invariantfirst_fix_directionmisrepair_riskconfidenceevidence_sufficiency
If that already works for you, you do not need to read the whole page first.
Here is the simplest way to use the Router.
Use the attached Troubleshooting Atlas Router v1.
Route the following case using the Router output contract.
Case:
[paste your bug, issue, trace, workflow failure, or structured-output failure here]
That is enough for a first pass.
Here is a small example of the kind of case that already works well.
Use the attached Troubleshooting Atlas Router v1.
Route the following case using the Router output contract.
Case:
The agent keeps producing valid-looking JSON, but the schema parser fails because required fields appear in inconsistent places across steps.
Expected behavior:
Stable schema-compatible output.
Actual behavior:
Parse failures and downstream workflow breaks.
This is not the only valid format.
It is just a simple example of the level of signal that helps the Router cut cleanly.
Troubleshooting Atlas Router v1 is a compact TXT pack designed to help AI systems read troubleshooting cases through the Atlas family map.
Its job is not to do everything.
Its job is to do the most important early step well:
- classify the most likely failure family
- explain why that family is primary
- identify the most likely broken invariant
- suggest the first repair direction
- warn about likely misrepair
- stay honest when evidence is weak
Short version:
the Router helps AI read failure cases more like a troubleshooting system and less like a guess generator
Use the Router when you have a real troubleshooting case and want a faster route-first judgment.
Good use cases include:
- AI bug reports
- issue threads
- workflow failures
- agent step failures
- structured-output failures
- prompt and output mismatches
- strange model behavior with logs or traces
- system summaries where something is clearly wrong but the failure family is not obvious yet
This product is especially useful when the question is not only:
- what happened
but more like:
- what kind of failure is this
- why is it this kind
- what should be tried first
- what should not be tried first
Do not use the Router as if it were already:
- a full autonomous repair engine
- a full benchmark framework
- a full root-cause analysis suite
- a replacement for logs, traces, or actual debugging work
- a substitute for the full Atlas when deep study is needed
If you need:
- richer family definitions
- full teaching examples
- deeper bridge logic
- more careful case interpretation
- stronger repair design
then move from the Router back into the larger Atlas system.
Short version:
use the Router for compact route-first help use the full Atlas when you need deeper structure
At minimum, you need two things:
You should have:
troubleshooting-atlas-router-v1.txt
The case can be small or medium-sized, but it should contain enough signal to support routing.
Useful forms of input include:
- a bug description
- an issue body
- an error summary
- a workflow trace excerpt
- expected vs actual behavior
- a prompt and output pair
- a JSON failure sample
- a short log snippet with context
You do not need a perfect formal schema.
But the better the case description, the better the route.
The Router is designed for a very simple flow.
Load or paste the Router TXT into the model context.
Paste your case below it.
Ask the model to route the case using the Router output contract.
Read the result in this order:
- primary_family
- secondary_family
- why_primary_not_secondary
- broken_invariant
- best_current_fit
- first_fix_direction
- misrepair_risk
- confidence
- evidence_sufficiency
Decide whether the result is strong enough to act on directly, or whether you need:
- more evidence
- deeper Atlas reading
- deeper WFGY bridge exploration
- a real implementation step
That is the healthy use pattern.
If you want a cleaner result, use a slightly more guided prompt.
Use Troubleshooting Atlas Router v1.
Please do the following in order:
1. identify the most likely primary family
2. identify the strongest neighboring family only if it is real
3. explain why the primary cut is stronger
4. identify the broken invariant
5. identify the best current fit at the highest honest resolution
6. give the first repair direction
7. warn about the most likely misrepair
8. report confidence and evidence sufficiency honestly
Case:
[paste case here]
This version tends to reduce sloppy outputs.
The Router works best when the case contains enough material to expose the failure shape.
The most useful ingredients are:
- what was supposed to happen
- what actually happened
- where the failure appears
- what evidence or trace exists
- whether this is a content problem, workflow problem, observability problem, boundary problem, or structure-carrier problem
- any concrete artifact such as output, log, schema, or snippet
The Router is still usable on shorter descriptions.
But the best results usually come when the case includes:
- expected behavior
- actual behavior
- one concrete failure artifact
That gives the model something real to cut.
The Router’s output is compact, but every field matters.
This is the most likely main failure region.
It tells you where the earliest decisive failure probably lives.
This is the strongest neighboring pressure, if there is one.
It is optional.
A good output may say none.
This is the most important field after primary_family.
It explains the cut.
If this field is weak, the route itself is usually weak.
This tells you what kind of structural failure the model thinks happened.
This is the bridge between routing and repair.
This gives the highest honest resolution the case supports.
Sometimes this will be node-like. Sometimes it should stay family-level.
This tells you the first move, not the whole solution.
This warns you what tempting wrong first move to avoid.
This tells you how stable the cut is.
This tells you whether the current case actually contained enough material to support the route strongly.
A good Router output usually has these qualities:
- the primary family makes structural sense
- the neighboring family is real, not decorative
- the cut is explained clearly
- the broken invariant is specific enough to guide action
- the first fix direction is modest and plausible
- the misrepair warning feels real
- the confidence level matches the actual evidence
A bad Router output usually has one or more of these problems:
- family chosen by topic words only
- secondary family added for decoration
- vague why-primary explanation
- broken invariant too generic
- first fix direction too ambitious
- confidence too high for the evidence
- no mention of missing evidence when the case is thin
That is how you should read the result.
Sometimes the Router will say:
- confidence is low
- evidence_sufficiency is low
- need_more_evidence is yes
That is not a failure.
That is often a sign that the Router is behaving honestly.
When this happens, the right next move is usually one of these:
- provide the actual output artifact
- provide expected vs actual behavior
- provide the relevant log or trace
- provide the schema or container that failed
- provide the step order or workflow context
- provide the evidence source that the answer was supposed to anchor to
Short version:
weak evidence should usually trigger better case input, not anger at the Router
The Router can be used across several common troubleshooting styles.
Useful input:
- user question
- retrieved chunk
- final answer
- what was wrong
Likely value:
- stronger F1 vs F7 vs F5 cuts
- better first move on re-grounding
Useful input:
- task description
- step order
- trace excerpt
- where the workflow failed
Likely value:
- stronger F3 vs F4 vs F5 cuts
- better first move on closure, continuity, or visibility
Useful input:
- expected schema
- actual output
- parse failure
- model prompt if useful
Likely value:
- stronger F7 vs F2 vs F1 cuts
- better first move on container repair
Useful input:
- observed failure behavior
- why it seems dangerous
- what is visible vs what is inferred
- whether the boundary itself is already drifting
Likely value:
- stronger F5 vs F6 separation
- fewer premature “danger means F6” mistakes
Router v1 is especially strong at these things:
It helps the model not jump to the loudest symptom too fast.
It pushes the model to justify the cut.
This is one of the biggest values in the whole system.
It helps resist fake certainty.
This is one of the biggest product thresholds the Router crosses.
Router v1 is useful, but it still has normal first-version limits.
It is still limited at:
- very thin cases with no real evidence
- extremely mixed cross-family cases
- very long workflow chains with missing trace details
- full repair planning
- full autonomous remediation
- deep cross-domain reasoning beyond the compact pack boundary
That is normal.
If you need stronger coverage, move up into:
- the full Atlas
- the Casebook
- the Adapter documents
- the deeper fix bridge
- deeper WFGY exploration
The Router should be seen as one layer in the larger system.
- compact route-first behavior
- direct AI usage
- quick family cuts
- first-fix guidance
- deeper family structure
- teaching cases
- negative examples
- cross-domain bridge logic
- patch history
- system-level provenance and validation
The Router is strongest when used as a front layer, not when forced to become the whole system.
If a human wants to use this product manually, the best pattern is:
- paste the Router into the model
- paste one real case
- read the output fields in order
- judge whether the cut feels structurally right
- apply only the first repair move
- do not escalate to full repair until the first cut looks sane
- move into deeper Atlas or WFGY layers only if needed
This keeps the product useful and honest.
If the Router is used inside a workflow, the safest first-version pattern is:
-
case enters system
-
Router produces route-first output
-
system reads:
- primary_family
- broken_invariant
- first_fix_direction
- confidence
-
if confidence is high enough, continue into the first repair workflow
-
if confidence is low, request more evidence or escalate to a richer Atlas layer
This keeps the Router acting like a disciplined front-end classifier.
To use Router v1 well, avoid these mistakes.
- treat it like a full repair engine
- expect perfect node-level diagnosis on tiny cases
- ignore
confidenceandevidence_sufficiency - force
secondary_familywhen it should benone - jump directly from route to full implementation
- treat every dangerous-sounding case as F6
- treat every structured-output case as F7
- treat every hard case as ambiguous or no_fit
These are exactly the kinds of mistakes the Router is meant to reduce.
If you need a short explanation for a README, demo, or collaboration thread, use wording like this:
Troubleshooting Atlas Router v1 is a compact TXT pack derived from Problem Map 3.0 Troubleshooting Atlas. It helps AI systems classify failures, explain the family cut, identify the likely broken invariant, and suggest the first repair direction without pretending to offer full repair closure.
This is strong, clear, and safe.
This guide explains how to use Troubleshooting Atlas Router v1 as a compact route-first TXT pack for failure classification and first-fix guidance.
If you want the shortest next path:
- Get the Router TXT Pack
- Open the Router Freeze Note
- See the Official Flagship Demos
- Open the Atlas Hub
If this guide helped you get started, a good next move is to test the Router on one real case before opening the deeper Atlas layers.
A good troubleshooting tool does not need to solve the whole system in one jump.
Sometimes the biggest upgrade is earlier than that.
Sometimes the biggest upgrade is simply this:
the model stops reading the case in the wrong way first
That is what Router v1 is for.
Back to the main entry: