vrr/WFGY
2
0
Fork 0
mirror of https://github.com/onestardao/WFGY.git synced 2026-04-28 03:29:51 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Create atlas-boundary-decision-guide-v1.mdatlas-boundary-decision-guide-v1.md

Browse source
This commit is contained in:
PSBigBig + MiniPS 2026-03-20 15:02:57 +08:00 • committed by GitHub
parent 57747e0007
commit 60312c706a
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 713 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

713
ProblemMap/Atlas/atlas-boundary-decision-guide-v1.mdatlas-boundary-decision-guide-v1.md Normal file
View file

@ -0,0 +1,713 @@
<!--
AI_NOTE_START
Document role:
This page is the public boundary-decision guide for the Atlas family layer.
How to use this page:
1. Read this page after the family mini-spec page if you need to separate two neighboring families more carefully.
2. Use this page when one family feels plausible, but a second neighboring family still remains live.
3. Use this page to identify the decisive separation question, the evidence that pushes left or right, and the cases where restraint is better than forced certainty.
4. Do not use this page as a replacement for the frozen core, the subtree index, the fit registry, or the repair manual.
What this page is:
- A public boundary-decision guide
- A middle-layer clarification page
- A route-first separation aid
- A beginner-friendly bridge between family reading and later fit discipline
What this page is not:
- Not the public homepage
- Not the Atlas Hub
- Not the full freeze document
- Not the subtree expansion index
- Not the fit candidate registry
- Not the output contract page
- Not the full repair manual
- Not a claim that every pairwise boundary is already fully closed
Reading discipline for AI:
- Treat boundary reading as a restraint layer, not as a license to overclassify.
- Start from the broken invariant and primary failure surface before using labels.
- Do not force a hard split when evidence is thin, contradictory, or under-instrumented.
- Preserve the distinction between family boundary, subtree boundary, overlay, and repair layers.
- Use this page to reduce confusion, not to inflate certainty.
Relationship to neighboring docs:
- Read after: [Atlas Family Mini-Specs](./atlas-family-mini-specs-v1.md) if you need the seven-family overview first.
- Read with: [Canonical Casebook v1](./canonical-casebook-v1.md) if you want examples alongside this guide.
- Read before: [Atlas Subtree Expansion Index v1](./atlas-subtree-expansion-index-v1.md), [Atlas Fit Candidate Registry v1](./atlas-fit-candidate-registry-v1.md), and [Atlas First Fix and Misrepair Discipline v1](./atlas-first-fix-and-misrepair-discipline-v1.md).
- Pairs with: [Atlas Evidence and Confidence Discipline v1](./atlas-evidence-and-confidence-discipline-v1.md), because boundary reading depends heavily on evidence restraint.
Freeze / patch status:
- Current status: public decomposition layer
- Safe to quote as: a public guide to high-value Atlas family boundary decisions
- Not a claim of: silent rewrite of the frozen core or exhaustive closure of all boundary cases
AI_NOTE_END
-->
# Atlas Boundary Decision Guide 🧭
## Problem Map 3.0 Troubleshooting Atlas
> Quick links, high-value family boundaries, and beginner-friendly route-first separation rules
This page exists for a very simple reason.
Knowing the seven families is already useful.
But in real use, people do not usually get stuck on the family names.
They get stuck here:
two families both feel plausible,
the symptoms overlap,
the wording looks similar,
and it is not yet clear where the primary failure surface actually sits.
That is what this page is for.
It does not try to solve every subtree question.
It does not try to force total closure.
It does not pretend that every hard case should be decided at once.
Its job is narrower and more practical:
help readers separate the most important neighboring families without turning the Atlas into a guessing game.
---
## Quick Links 🚀
If you are new, use these first.
### I want the public introduction
- [Problem Map 3.0 Troubleshooting Atlas](../wfgy-ai-problem-map-troubleshooting-atlas.md)
### I want the folder control room
- [Atlas Hub](./README.md)
### I want the full structure map first
- [Atlas Structure Map](./atlas-structure-map-v1.md)
### I want the family overview before this page
- [Atlas Family Mini-Specs](./atlas-family-mini-specs-v1.md)
### I want the stable core after this page
- [Atlas Final Freeze v1](./atlas-final-freeze-v1.md)
- [Atlas Negative Space Report v1](./atlas-negative-space-report-v1.md)
### I want examples while reading this page
- [Canonical Casebook v1](./canonical-casebook-v1.md)
### I want the next middle-layer pages after this one
- [Atlas Subtree Expansion Index v1](./atlas-subtree-expansion-index-v1.md)
- [Atlas Fit Candidate Registry v1](./atlas-fit-candidate-registry-v1.md)
### I want the compact practical route-first layer
- [Troubleshooting Atlas Router v1 Usage Guide](./troubleshooting-atlas-router-v1-usage.md)
- [Troubleshooting Atlas Router v1 TXT Pack](./troubleshooting-atlas-router-v1.txt)
---
## Why this page exists
A family-level label is often enough for a first pass.
But many real cases live near a boundary.
That is where systems become sloppy.
A weak system often does one of three things:
- it pretends the answer is obvious
- it chooses based on surface wording alone
- it hides uncertainty behind stronger rhetoric
This page is designed to block that behavior.
It gives a cleaner middle step between:
family recognition
and
later fit / subtree / repair decisions
That middle step is the boundary question.
---
## Scope
This page focuses on:
- high-value family boundaries
- the decisive separation question for each pair
- evidence that pushes one way or the other
- common misclassification patterns
- when restraint is better than forced certainty
This page does **not** focus on:
- full subtree boundaries
- full fit-promotion rules
- overlay handling in detail
- full repair sequences
- every possible pair among every future public node
This is a first public guide to the most important family-level boundaries.
---
## How to use this page
The safest reading order is:
### Step 1
Start from the family page, not from a vague symptom list.
Read:
- [Atlas Family Mini-Specs](./atlas-family-mini-specs-v1.md)
### Step 2
Ask which **two** families still seem most plausible.
Do not jump to six-way confusion if the case is really a narrow pair.
### Step 3
Use the boundary pair section here.
Look for:
- the decisive separation question
- what evidence pushes left
- what evidence pushes right
- what evidence is still missing
### Step 4
If the boundary remains unclear, do **not** fake certainty.
Move later to:
- [Atlas Evidence and Confidence Discipline v1](./atlas-evidence-and-confidence-discipline-v1.md)
- [Atlas Fit Candidate Registry v1](./atlas-fit-candidate-registry-v1.md)
That keeps the routing layer honest.
---
## Boundary reading rules
Before looking at any pair, keep these rules in mind.
### Rule 1. Start from the broken invariant
Do not start from vibe, tone, or isolated wording.
### Rule 2. Look for the first meaningful failure surface
Ask what seems broken first, not what looks loudest last.
### Rule 3. Do not confuse downstream noise with upstream cause
A representation mess may come from a grounding failure, or it may really be a representation failure.
That is why boundaries matter.
### Rule 4. Thin evidence should reduce confidence
Thin evidence does not become strong because the prose sounds clean.
### Rule 5. Some cases should remain unresolved for now
A restrained answer is often better than a fake precise answer.
---
## High-value boundary pairs
This first version focuses on the highest-value pairs for public use.
---
## F1 vs F7
### Grounding and Evidence Integrity vs Representation and Localization Integrity
### Why this pair is commonly confused
Both families can produce outputs that look wrong, misleading, or low quality.
A reader may see bad wording, strange format, or awkward output and think the issue is representational.
But sometimes the real problem started earlier: the answer was never grounded correctly.
### Decisive separation question
Is the main problem that the system is **not tied to the right evidence surface**,
or that it is **failing to package and render meaning well even when part of the right signal may exist**?
### Evidence that pushes toward F1
- the claims are not really supported by the retrieved or cited material
- the source surface is weak, mismatched, or missing
- the output sounds confident without a valid evidence anchor
- better formatting would not solve the deeper truth problem
### Evidence that pushes toward F7
- the system seems to contain relevant signal, but the packaging is poor
- formatting, rendering, localization, or structure is the main obstacle
- the answer becomes much more usable once representation improves
- the evidence anchor looks broadly present, but the final expression distorts it
### When to stay unresolved
Stay unresolved when:
- both grounding and representation are clearly weak
- the evidence surface is too thin to tell whether the signal was ever present
- the observed output is too degraded to infer the primary layer safely
### Common misclassification
A frequent mistake is calling everything “representation” because the output looks ugly, when the deeper failure is actually evidential.
### Repair consequence of getting this wrong
If you misread F1 as F7, you may polish surface format while leaving the false anchor untouched.
---
## F5 vs F6
### Observability and Diagnosability Integrity vs Boundary and Safety Integrity
### Why this pair is commonly confused
Both families often show up when something feels uncontrolled.
In one case, the problem is that the system cannot be inspected well enough.
In the other case, the problem is that the limits themselves are not holding.
### Decisive separation question
Is the main problem that the system is **too blind to diagnose safely**,
or that the system is **failing to maintain the right limits and edge discipline**?
### Evidence that pushes toward F5
- the core issue is diagnostic blindness
- you cannot tell what the system is doing or where it is failing
- instrumentation, tracing, metrics, or visibility is too weak
- more inspection would materially improve classification and intervention
### Evidence that pushes toward F6
- the edge rules exist but do not hold
- the system crosses boundaries inconsistently or unsafely
- limit behavior collapses under pressure
- the main concern is unreliable restriction or control discipline
### When to stay unresolved
Stay unresolved when:
- poor visibility prevents confident judgment about whether the boundary actually failed
- the system both lacks instrumentation and appears to violate a hard limit
### Common misclassification
A frequent mistake is calling a safety-control problem “observability” simply because the logs are weak.
Weak logs do not automatically mean the primary family is F5.
### Repair consequence of getting this wrong
If you misread F6 as F5, you may add monitoring while leaving a dangerous boundary weakness alive.
---
## F3 vs F4
### State and Continuity Integrity vs Execution and Contract Integrity
### Why this pair is commonly confused
Both families can produce a task that “does not complete correctly.”
The difference is subtle but important.
Sometimes the system fails because it cannot preserve state and continuity over time.
Sometimes it fails because it cannot carry a known contract into reliable action.
### Decisive separation question
Is the main problem that the system **loses continuity across turns, steps, or evolving state**,
or that it **fails to translate intent and explicit contract into correct execution**?
### Evidence that pushes toward F3
- earlier commitments are lost or drift over time
- state is not carried forward properly
- the task starts well and then continuity decays
- the system seems unable to keep the relevant thread alive across steps
### Evidence that pushes toward F4
- the contract is known, but execution still fails
- tools are invoked badly or in the wrong shape
- the system understands but does not perform correctly
- the failure is mainly in carrying plan into action
### When to stay unresolved
Stay unresolved when:
- a stateful task also contains a strong execution contract
- the execution trace is too thin to tell whether continuity failed first or action failed first
### Common misclassification
A frequent mistake is labeling all multistep failure as F3 just because the task spans time.
Sometimes the continuity is fine, but execution discipline is poor.
### Repair consequence of getting this wrong
If you misread F4 as F3, you may keep improving state carryover while the action contract remains broken.
---
## F2 vs F7
### Reasoning and Progression Integrity vs Representation and Localization Integrity
### Why this pair is commonly confused
Both can make an answer look “confusing.”
But confusion can come from two very different places.
One is that the underlying reasoning path is weak.
The other is that the meaning may partly exist, but is rendered badly.
### Decisive separation question
Is the main problem that the **reasoning path itself is structurally weak**,
or that the **final expression distorts or obscures an otherwise partially valid signal**?
### Evidence that pushes toward F2
- intermediate steps do not earn the conclusion
- the chain of progression contains invalid jumps
- even after cleaning the format, the logic still does not hold
- the weakness is structural, not cosmetic
### Evidence that pushes toward F7
- reformatting or reframing clarifies much of the intended meaning
- the structure is awkward, but the underlying path is not obviously broken
- localization or output packaging is a major part of the failure surface
### When to stay unresolved
Stay unresolved when:
- both the logic and the packaging are clearly unstable
- the final output is too compressed or noisy to inspect the underlying path safely
### Common misclassification
A frequent mistake is blaming representation first because the result looks messy, even when the deeper problem is an invalid chain of reasoning.
### Repair consequence of getting this wrong
If you misread F2 as F7, you may improve readability while preserving a broken argument.
---
## F1 vs F5
### Grounding and Evidence Integrity vs Observability and Diagnosability Integrity
### Why this pair is commonly confused
Both can make it hard to trust what the system is doing.
In one case, the trust problem comes from weak evidential anchoring.
In the other, the trust problem comes from weak visibility into the system.
### Decisive separation question
Is the main problem that the answer is **not tied to the right evidence**,
or that the system is **too poorly instrumented to diagnose its behavior confidently**?
### Evidence that pushes toward F1
- the answer-source linkage is weak or false
- citations or retrieval do not actually support the output
- the evidence surface itself is broken
- observability improvements alone would not repair the anchor
### Evidence that pushes toward F5
- the answer may or may not be grounded, but the current inspection surface is too weak to tell
- operational visibility is the blocker
- traces, metrics, or diagnostics are too poor for safe interpretation
### When to stay unresolved
Stay unresolved when:
- both source quality and diagnostic visibility are severely weak
- you cannot tell whether the bad answer reflects evidence failure, visibility failure, or both
### Common misclassification
A frequent mistake is calling a grounding problem “observability” because the debug tools are weak, even though the core evidence linkage is already clearly broken.
### Repair consequence of getting this wrong
If you misread F1 as F5, you may add dashboards while still answering from the wrong anchor.
---
## F4 vs F5
### Execution and Contract Integrity vs Observability and Diagnosability Integrity
### Why this pair is commonly confused
When a system behaves badly in operation, people often say “we need better observability.”
Sometimes that is right.
Sometimes the system is already obviously violating the task contract, and the primary problem is execution.
### Decisive separation question
Is the main problem that the system **cannot execute the intended contract reliably**,
or that the system **cannot be diagnosed clearly enough to understand what execution is doing**?
### Evidence that pushes toward F4
- the task contract is explicit and not followed
- tool calls are wrong, incomplete, or out of order
- action behavior is visibly off even without deep instrumentation
- the system’s execution surface is already the obvious failure point
### Evidence that pushes toward F5
- execution might be failing, but the main blocker is diagnostic blindness
- visibility is too weak to tell how or where the contract is being lost
- better observability would materially change confidence and intervention quality
### When to stay unresolved
Stay unresolved when:
- the logs are poor and the action contract is also visibly weak
- more visibility is genuinely needed before assigning the primary family confidently
### Common misclassification
A frequent mistake is labeling a visible execution failure as F5 because “better observability is always good.”
That may be true, but it does not settle the primary family.
### Repair consequence of getting this wrong
If you misread F4 as F5, you may invest in diagnostics while the system keeps failing the task contract.
---
## F3 vs F6
### State and Continuity Integrity vs Boundary and Safety Integrity
### Why this pair is commonly confused
Both can produce unstable behavior over time.
A continuity problem may look like bad limit handling.
A bad limit-handling problem may also look like instability across turns or sessions.
### Decisive separation question
Is the main problem that the system **cannot maintain continuity across evolving state**,
or that it **cannot preserve the right limits and constraints under edge pressure**?
### Evidence that pushes toward F3
- memory or continuity degrades over time
- commitments are dropped without clear edge-trigger behavior
- the system forgets or mutates state inconsistently
### Evidence that pushes toward F6
- the instability appears especially at edge conditions
- the system fails when boundary pressure rises
- rule preservation, refusal, or limit discipline is the main weak point
### When to stay unresolved
Stay unresolved when:
- a long-running task also includes strong edge constraints
- you cannot yet tell whether the system forgot state or crossed a limit first
### Common misclassification
A frequent mistake is reading every long-run degradation as continuity loss when the actual trigger is repeated edge-boundary weakness.
### Repair consequence of getting this wrong
If you misread F6 as F3, you may keep improving memory while the boundary discipline still collapses under pressure.
---
## F2 vs F3
### Reasoning and Progression Integrity vs State and Continuity Integrity
### Why this pair is commonly confused
Both can make multi-step outputs look incoherent.
But one problem is about the **quality of the reasoning path itself**,
while the other is about **preserving the right thread across evolving context**.
### Decisive separation question
Is the main problem that the **logic from step to step is bad**,
or that the **system cannot maintain the state needed for that logic to remain continuous over time**?
### Evidence that pushes toward F2
- the reasoning path is weak even inside a short window
- the argument contains jumps that do not depend on lost context
- the chain is structurally unsound even when continuity is held constant
### Evidence that pushes toward F3
- the earlier state matters, but is not carried forward cleanly
- the quality degrades as context evolves
- once continuity breaks, the later reasoning collapses too
### When to stay unresolved
Stay unresolved when:
- both short-window reasoning and long-run continuity look weak
- the available trace is too small to separate logic quality from state maintenance
### Common misclassification
A frequent mistake is calling an evolving-state failure “reasoning” because the final explanation looks incoherent, even though the deeper problem is that the system lost the needed state.
### Repair consequence of getting this wrong
If you misread F3 as F2, you may refine local reasoning prompts while the continuity surface keeps failing.
---
## Boundary restraint rules
A good boundary guide should not encourage overconfidence.
Use these restraint rules.
### Rule A. Stay at family level when that is the strongest safe claim
Not every case deserves immediate pairwise certainty.
### Rule B. Thin evidence should block hard separation
A clean explanation is not the same as a justified one.
### Rule C. Contradictory evidence should stay visible
Do not erase conflict just to finish the classification.
### Rule D. Observability weakness should lower confidence
Some boundaries cannot be decided well until the evidence surface improves.
### Rule E. Boundary reading should improve repair safety
If a forced split would increase repair risk, restraint is often the better move.
---
## Common boundary-reading mistakes
### Mistake 1. Choosing the louder symptom
The loudest symptom is not always the primary failure surface.
### Mistake 2. Confusing “helpful next fix” with “true primary family”
A useful next repair move does not automatically prove the primary classification.
### Mistake 3. Using rhetoric to compensate for weak evidence
Stronger wording does not strengthen the evidence.
### Mistake 4. Treating every mixed case as a clean split
Some cases are truly mixed, unresolved, or overlay-prone.
### Mistake 5. Forgetting the observability question
Sometimes the real answer is: we still cannot see enough.
---
## When this page is enough
This page is often enough when:
- the confusion is mostly between two neighboring families
- the case still lives at family level
- you need a safer first cut before moving to fit or repair
- the decisive separation question can already be answered with existing evidence
In those situations, this page can prevent a lot of early misrouting.
---
## When this page is not enough
This page is usually not enough when:
- the case clearly needs subtree-level detail
- a multi-family overlay is active
- the evidence is too thin for safe separation
- the repair consequences are high enough that fit discipline matters
- the case is mostly blocked by poor instrumentation or contradictory traces
When that happens, the right next pages are:
- [Atlas Subtree Expansion Index v1](./atlas-subtree-expansion-index-v1.md)
- [Atlas Fit Candidate Registry v1](./atlas-fit-candidate-registry-v1.md)
- [Atlas Evidence and Confidence Discipline v1](./atlas-evidence-and-confidence-discipline-v1.md)
---
## Practical use
The simplest practical workflow is this:
### Step 1
Use:
- [Atlas Family Mini-Specs](./atlas-family-mini-specs-v1.md)
Pick the one or two strongest family candidates.
### Step 2
Come here and read the relevant pair section.
### Step 3
Write down:
- the decisive separation question
- the evidence pushing left
- the evidence pushing right
- the missing evidence
### Step 4
If one side clearly wins, keep that as the current route-first read.
### Step 5
If not, do not fake precision.
Move to later pages and preserve the uncertainty cleanly.
This keeps the Atlas useful and honest at the same time.
---
## Relation to other Atlas docs
This page sits directly after the family layer.
### Upstream neighbors
These pages prepare the reader for boundary work:
- [Problem Map 3.0 Troubleshooting Atlas](../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Atlas Structure Map](./atlas-structure-map-v1.md)
- [Atlas Family Mini-Specs](./atlas-family-mini-specs-v1.md)
### Side neighbor
This page pairs especially well with:
- [Canonical Casebook v1](./canonical-casebook-v1.md)
Why:
this page gives separation logic, while the casebook gives worked shapes and examples.
### Downstream neighbors
These are the natural next steps:
- [Atlas Subtree Expansion Index v1](./atlas-subtree-expansion-index-v1.md)
- [Atlas Fit Candidate Registry v1](./atlas-fit-candidate-registry-v1.md)
- [Atlas First Fix and Misrepair Discipline v1](./atlas-first-fix-and-misrepair-discipline-v1.md)
- [Atlas Evidence and Confidence Discipline v1](./atlas-evidence-and-confidence-discipline-v1.md)
Why:
this page sharpens the pairwise family cut, but later pages govern how far that cut can be trusted and how it affects action.
---
## Current status
This page should be read as a stable **public boundary guide**.
That means:
- it is more explicit than a short family summary
- it is lighter than a full frozen structural treatment
- it gives useful pairwise discipline without pretending to settle every case
- it improves routing safety for both humans and AI systems
Its value is practical restraint.
It helps readers separate the most important neighboring families without forcing total closure too early.
---
## Future extension
This first version focuses on high-value family boundaries only.
Later versions may expand:
- additional family pairs
- subtree-adjacent boundaries
- more worked contrast patterns
- more explicit links to fit and misrepair consequences
But the right order still matters.
The intended ladder is:
family
to boundary
to subtree
to fit
to repair discipline
That order keeps the Atlas clean.
---
## Closing note 🔭
A good classification system is not only about naming categories.
It is also about knowing where categories are easy to confuse,
what evidence actually separates them,
and when a clean unresolved answer is better than a fake certain one.
That is what this page is for.
It helps the Atlas stay readable, useful, and disciplined right at the place where many systems usually start to bluff.