WFGY System Map · Quick navigation

Problem Maps: PM1 taxonomy → PM2 debug protocol → PM3 troubleshooting atlas · built on the WFGY engine series

As of 2026-03, the WFGY RAG 16 Problem Map line has been adopted or referenced by
20+ frameworks, academic labs, and curated lists in the RAG and agent ecosystem.
Most external references use the WFGY ProblemMap as a diagnostic layer for RAG / agent pipelines,
not the full WFGY product stack.
A smaller but growing set also uses WFGY 3.0 · Singularity Demo as a long-horizon TXT stress test.

Some representative integrations:

Project	Stars	Segment	How it uses WFGY ProblemMap	Proof (PR / doc)
LlamaIndex		Mainstream RAG infra	Integrates the WFGY 16-problem RAG failure checklist into its official RAG troubleshooting docs as a structured failure mode reference.	PR #20760
RAGFlow		Mainstream RAG engine	Introduced a RAG failure modes checklist guide to the RAGFlow documentation via PR, adapted from the WFGY 16-problem failure map for step-by-step RAG pipeline diagnostics.	PR #13204
FlashRAG (RUC NLPIR Lab)		Academic lab / RAG research toolkit	Adapts the WFGY ProblemMap as a structured RAG failure checklist in its documentation. The 16-mode taxonomy is cited to support reproducible debugging and systematic failure-mode reasoning for RAG experiments.	PR #224
DeepAgent (RUC NLPIR Lab)		Academic lab / agent research	Adds a multi-tool agent failure modes troubleshooting note inspired by WFGY-style debugging concepts for diagnosing tool selection loops, tool misuse, and multi-tool workflow failures in agent pipelines.	PR #15
ToolUniverse (Harvard MIMS Lab)		Academic lab / tools	Provides a WFGY_triage_llm_rag_failure tool that wraps the 16 mode map for incident triage.	PR #75
Rankify (University of Innsbruck)		Academic lab / system	Uses the 16 failure patterns in RAG and re-ranking troubleshooting docs.	PR #76
Multimodal RAG Survey (QCRI LLM Lab)		Academic lab / survey	Cites WFGY as a practical diagnostic resource for multimodal RAG.	PR #4
LightAgent		Agent framework	Incorporates WFGY ProblemMap concepts into its documentation via a Multi-agent troubleshooting (failure map) section, providing a structured symptom → failure-mode → debugging checklist for diagnosing role drift, cross-agent memory issues, and coordination failures in multi-agent systems.	PR #24
OmniRoute		Gateway / routing infra	Adds an optional WFGY 16-problem RAG / LLM failure taxonomy to its official troubleshooting documentation, allowing teams to classify downstream RAG and agent failures with No.1 to No.16 alongside OmniRoute logs when the gateway itself appears healthy.	PR #164

For the complete 20+ project list (frameworks, benchmarks, curated lists), see the 👉 WFGY Recognition Map

If your project uses the WFGY ProblemMap and you would like to be listed,
feel free to open an issue or pull request in this repository.

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🚑 WFGY Emergency Room (for developers)

👨‍⚕️ Now online: Dr. WFGY in ChatGPT Room

This is a share window already trained as an ER. Just open it, drop your bug or screenshot, and talk directly with the doctor. He will map it to the right Problem Map / Global Fix section, write a minimal prescription, and paste the exact reference link. If something is unclear, you can even paste a screenshot of Problem Map content and ask — the doctor will guide you.

⚠️ Note: for the full reasoning and guardrail behavior you need to be logged in — the share view alone may fallback to a lighter model.

💡 Always free. If it helps, a ⭐ star keeps the ER running. 🌐 Multilingual — start in any language.

👵 Grandma’s AI Clinic (for everyone)

Visit Grandma Clinic →

• 16 common AI failure modes, each explained as a grandma story.
• Everyday metaphors: wrong cookbook, salt-for-sugar, burnt first pot.
• Shows both the life analogy and the minimal WFGY fix.
• Perfect entry point for beginners, or anyone who wants to “get it” in 30 seconds.

💡 Tip: Both tracks lead to the same Problem Map numbers. Choose Emergency Room if you need a fix right now. Choose Grandma’s Clinic if you want to understand the bug in plain words.

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

most fixes today happen AFTER generation:

• the model outputs something wrong, then we patch it with retrieval, chains, or tools.
• the same failures reappear again and again.

WFGY inverts the sequence. BEFORE generation:

• it inspects the semantic field (tension, residue, drift signals).
• if the state is unstable, it loops, resets, or redirects the path.
• only a stable semantic state is allowed to generate output.

this is why, once a failure mode is clearly mapped and monitored under the same conditions, it is usually stable for that configuration; if context changes, treat it as a re-mapping case.
you’re not only firefighting after the fact — you’re installing a reasoning firewall at the entry point of that stack.

---

📊 Before vs After

	Traditional Fix (After Generation)	WFGY Semantic Firewall (Before Generation) 🏆✅
Flow	Output → detect bug → patch manually	Inspect semantic field → only a stable state is allowed to generate
Method	Add rerankers, regex, JSON repair, tool patches	ΔS, λ, coverage checked upfront; loop/reset if unstable
Cost	High — every bug = new patch, risk of conflicts	Lower — once mapped, the bug is usually reduced under the same assumptions
Ceiling	Often plateaus around 70–85% stability in practice	In internal tests, 90–95%+ stability observed on selected stacks; not a universal guarantee
Experience	Firefighting, “whack-a-mole” debugging	Structural firewall, “fix once for a mapped family, then monitor for context drift”
Complexity	Growing patch jungle, fragile pipelines	Unified acceptance targets, one-page repair guide

---

⚡ Performance impact

• Traditional patching: in our internal experience, stability often plateaus around 70–85%. Each new patch adds complexity and potential regressions.
• WFGY firewall: in internal experiments on a small number of RAG/agent pipelines, we have seen 90–95%+ stability and roughly 60–80% reductions in repeat-debug time once failure families are properly mapped. These numbers are setup-dependent and should be treated as indicative, not as hard promises.
• Unified metrics: in our own recipes, every fix is measured (for example ΔS ≤ 0.45, coverage ≥ 0.70, λ convergent) so that acceptance is explicit rather than based on gut feeling.

🛑 Key notes

• This is not a plugin or SDK — it runs as plain text, zero infra changes.
• You should apply acceptance targets: don’t just eyeball; log ΔS and λ (or equivalent) to confirm for your own stack.
• Once acceptance holds, we treat that path as sealed for that configuration. If drift recurs after model, data, or prompt changes, we treat it as a new failure mode that needs mapping, not a simple re-fix of the old one. Ongoing monitoring is still required.

---

Summary: Others patch symptoms AFTER output. WFGY blocks unstable states BEFORE output.
That is why it often feels less like debugging, more like installing structural guardrails — risk-reducing heuristics, not a mathematical guarantee.

---

🗺️ This is the panoramic index: all common AI infra / RAG / reasoning errors are organized here by category. Prefer Quick Access — it is the fastest way to self-orient, understand how this system works, and jump to the right fix: Quick Access. If you want the full folder view, open the Global Fix Map home: Global Fix Map README.

🧭 Providers & Agents

🧭 Data & Retrieval

🧭 Input & Parsing

🧭 Reasoning & Memory

🧭 Automation & Ops

🧭 Eval & Governance

open in colab

detects: No.2 — Interpretation Collapse steps: run all, paste prompt+answer, read ΔS and fix tip

open in colab

fixes: No.6 — Logic Collapse & Recovery steps: run all, compare ΔS before/after, fallback to BBCR if needed

open in colab

explains: No.12 — Philosophical Recursion steps: run, tune anchors, read ε

open in colab

detects: No.3 — Long Reasoning Chains steps: run, supply ≥3 answers, read score

*distance from default LLM behavior to a production-ready fix.