WFGY/CASE_EVIDENCE.md

<!--
AI NOTE · CASE_EVIDENCE

Purpose
- Translate public adoption evidence into capability signals.
- This page interprets what external integrations and citations suggest
  about where WFGY is useful in practice.

How this page differs from others
- ADOPTERS.md = short public adoption summary
- recognition/README.md = full ecosystem ledger
- CASE_EVIDENCE.md = interpretation of what the strongest cases mean

Boundary
- Do not overstate adoption.
- Do not imply paid customer relationships.
- Treat integrations as ecosystem signals, not endorsements.
-->

# CASE_EVIDENCE

This page interprets what the strongest public WFGY integrations and references **mean in practice**.

It does not duplicate the adoption list, and it does not attempt to track every mention.

Instead, it answers a more practical question:

**When external frameworks, labs, or research toolkits integrate or cite WFGY, what does that suggest about WFGY's role and usefulness?**

For the short adoption summary see  
[ADOPTERS.md](https://github.com/onestardao/WFGY/blob/main/ADOPTERS.md)

For the full ecosystem record see  
[WFGY Recognition Map](https://github.com/onestardao/WFGY/blob/main/recognition/README.md)

---

# Reading the ecosystem signals

Across current public evidence, the pattern is consistent.

The clearest adoption wedge today is:

**WFGY ProblemMap · the 16-problem failure map for RAG and agent systems**

In most public cases, WFGY appears as a **diagnostic layer** rather than a full runtime component.

Teams and researchers use it to:

- classify failure patterns
- structure debugging workflows
- reduce ambiguity when RAG or agent systems behave unpredictably
- turn symptoms into actionable troubleshooting steps
- create a shared vocabulary for failure analysis

The following cases show how that pattern appears across different parts of the ecosystem.

---

# Case 1 · LlamaIndex

## Context

[LlamaIndex](https://github.com/run-llama/llama_index) is one of the most widely used infrastructure frameworks for RAG and agent systems.

Documentation patterns in this ecosystem strongly influence how developers reason about system failures.

## Where WFGY fits

The **WFGY 16-problem failure checklist** was integrated into LlamaIndex troubleshooting documentation as a structured failure taxonomy.

This gives developers a more systematic way to interpret symptoms such as:

- hallucinated answers
- empty retrieval results
- unstable agent responses
- inconsistent knowledge grounding

## Public proof

[LlamaIndex PR #20760](https://github.com/run-llama/llama_index/pull/20760)

## What this suggests

This case shows that WFGY can function as a **framework-agnostic debugging reference**.

The ProblemMap is not tied to a single runtime stack.  
Instead, it can serve as a reusable conceptual layer for diagnosing failures across many RAG implementations.

## Important boundary

This integration demonstrates documentation-level adoption rather than full system embedding.

---

# Case 2 · RAGFlow

## Context

[RAGFlow](https://github.com/infiniflow/ragflow) is a production-oriented RAG framework focused on real pipeline deployments.

Frameworks at this layer care about practical debugging guidance because real systems often fail in ways that are difficult to diagnose.

## Where WFGY fits

A troubleshooting guide derived from the **WFGY 16-problem failure map** was merged into the RAGFlow repository to support structured RAG pipeline diagnostics.

The goal was to give developers a clear checklist of failure categories instead of leaving debugging entirely ad hoc.

## Public proof

[RAGFlow PR #13204](https://github.com/infiniflow/ragflow/pull/13204)

## What this suggests

The merge record shows that WFGY's failure-mode structure was useful enough to appear inside documentation for a mainstream RAG framework.

This suggests that WFGY is legible as a **practical debugging structure**, not only as a conceptual framework.

## Important boundary

Open-source documentation evolves over time.

This case is included as a **public merge record demonstrating ecosystem interaction**, not as a claim that documentation placement is permanent.

---

# Case 3 · FlashRAG

## Context

[FlashRAG (RUC NLPIR Lab)](https://github.com/RUC-NLPIR/FlashRAG) is a research-oriented RAG toolkit developed in an academic setting for experimentation and evaluation.

In research workflows, debugging structures need to support **reproducibility** in addition to practical troubleshooting.

## Where WFGY fits

FlashRAG documentation references the **WFGY ProblemMap** as a structured checklist for RAG failure analysis.

The taxonomy helps researchers reason about failure causes when evaluating retrieval pipelines and interpreting breakdowns across experiments.

## Public proof

[FlashRAG PR #224](https://github.com/RUC-NLPIR/FlashRAG/pull/224)

## What this suggests

This case shows that WFGY is useful not only in engineering operations but also in **research-side evaluation workflows**.

The ProblemMap can act as a bridge between experimentation, analysis, and debugging.

## Important boundary

Research citation does not imply benchmark status or universal adoption.

It shows that the framework was useful enough to be referenced in a structured evaluation context.

---

# Case 4 · DeepAgent

## Context

[DeepAgent (RUC NLPIR Lab)](https://github.com/RUC-NLPIR/DeepAgent) is an academic agent research project focused on complex multi-tool workflows.

In this setting, failures often come from tool misuse, poor tool selection, repeated tool loops, or weak coordination across steps.

## Where WFGY fits

DeepAgent includes a **multi-tool agent failure modes troubleshooting note** inspired by WFGY-style debugging concepts.

This extends the ProblemMap mindset beyond retrieval-heavy systems into **agent workflow diagnosis**, especially where the issue is not just missing context but incorrect tool behavior.

## Public proof

[DeepAgent PR #15](https://github.com/RUC-NLPIR/DeepAgent/pull/15#issuecomment-4020600680)

## What this suggests

This case suggests that WFGY-style failure mapping has value beyond classic RAG.

It can also help organize diagnosis in **multi-tool agent systems**, where errors are often procedural, compositional, or loop-driven.

## Important boundary

This example demonstrates conceptual extension rather than proof of full domain coverage.

Agent systems introduce many failure classes that go beyond the original 16-problem map.

---

# Case 5 · ToolUniverse

## Context

[ToolUniverse (Harvard MIMS Lab)](https://github.com/mims-harvard/ToolUniverse) is an academic-lab project exploring tool ecosystems for LLM systems.

Unlike a pure documentation reference, this project exposed a **tool interface** around WFGY triage logic.

## Where WFGY fits

ToolUniverse includes a `WFGY_triage_llm_rag_failure` utility that wraps the failure map as an incident triage tool.

This shifts WFGY from a static checklist into a **tool-level diagnostic mechanism**.

## Public proof

[ToolUniverse PR #75](https://github.com/mims-harvard/ToolUniverse/pull/75)

## What this suggests

This suggests that the WFGY failure map is structured enough to be operationalized as tooling, not just documentation.

It points to the possibility that WFGY concepts can serve as **diagnostic infrastructure**.

## Important boundary

This example shows conceptual wrapping rather than production deployment.

---

# Case 6 · Rankify

## Context

[Rankify (University of Innsbruck)](https://github.com/DataScienceUIBK/Rankify) focuses on ranking and reranking pipelines for retrieval systems.

Failures in these workflows are often subtle and difficult to categorize because the system can appear functional while still producing weak or unstable ranking behavior.

## Where WFGY fits

Rankify troubleshooting documentation references the **16-problem failure patterns** as a way to interpret common pipeline breakdowns in retrieval and reranking workflows.

## Public proof

[Rankify PR #76](https://github.com/DataScienceUIBK/Rankify/pull/76)

## What this suggests

This case indicates that the WFGY diagnostic framing remains useful even when the system boundary shifts away from pure retrieval and toward ranking-heavy workflows.

It suggests that the ProblemMap has some portability across adjacent retrieval infrastructure layers.

## Important boundary

This demonstrates conceptual reuse rather than domain-specific specialization.

---

# Case 7 · Multimodal RAG Survey

## Context

[Multimodal RAG Survey (QCRI LLM Lab)](https://github.com/llm-lab-org/Multimodal-RAG-Survey) is a survey-style academic resource.

Survey repositories help shape how the field organizes knowledge, and inclusion in a survey usually means a resource has become visible enough to be referenced in a broader research conversation.

## Where WFGY fits

The survey cites WFGY as a practical diagnostic resource for multimodal RAG systems.

## Public proof

[Multimodal RAG Survey PR #4](https://github.com/llm-lab-org/Multimodal-RAG-Survey/pull/4)

## What this suggests

This indicates that WFGY has begun to appear as a **field-facing reference point** for debugging and failure analysis, not just as an isolated project artifact.

## Important boundary

Survey citation is weaker evidence than direct integration.

It shows recognition and visibility, not operational use.

---

# Case 8 · LightAgent

## Context

[LightAgent](https://github.com/wanxingai/LightAgent) is an agent framework where system failures often emerge from coordination problems rather than simple retrieval issues.

Examples include:

- role drift between agents
- inconsistent shared memory
- coordination loops
- poor task decomposition
- unstable handoffs across agent roles

## Where WFGY fits

The documentation includes a troubleshooting section inspired by WFGY-style failure mapping.

This applies the ProblemMap approach to **multi-agent coordination failures** rather than only classic RAG retrieval issues.

## Public proof

[LightAgent PR #24](https://github.com/wanxingai/LightAgent/pull/24)

## What this suggests

This shows that WFGY-style structured debugging is not limited to RAG pipelines.

It can also help interpret failures in **agent orchestration systems**, especially when the failure is distributed across memory, coordination, and control flow.

## Important boundary

The agent domain introduces new classes of failure beyond the original map.

This example demonstrates conceptual portability rather than full domain coverage.

---

# Cross-case interpretation

Taken together, these cases suggest a consistent pattern.

## The strongest adoption wedge is the ProblemMap

The WFGY ProblemMap is currently the most visible and reusable component of the ecosystem.

It is the clearest entry point through which external projects can adopt, cite, adapt, or extend WFGY ideas.

## WFGY functions primarily as a diagnostic layer

Across integrations, the most common role is:

- debugging structure
- failure taxonomy
- triage framework
- troubleshooting reference
- shared interpretation layer for system failures

## The framework has crossed the pure-idea stage

WFGY now appears in:

- official documentation
- academic tools
- research toolkits
- agent troubleshooting guides
- survey-style research references
- curated ecosystem lists

This suggests meaningful ecosystem interaction rather than a purely internal theory project.

## The signal spans industry, research, and framework ecosystems

The strongest current public cases are not concentrated in a single niche.

They now span:

- mainstream RAG infrastructure
- academic RAG research
- agent tooling and orchestration
- survey and field-facing references

That distribution matters because it suggests the core diagnostic framing is legible across different audiences.

## Frontier components are still earlier

The **WFGY 3.0 tension reasoning engine** has visibility, but it currently has fewer public integration signals than the diagnostic layer.

That is expected for frontier reasoning infrastructure, where adoption usually comes later than the first diagnostic interfaces.

---

# What this means for teams evaluating WFGY

A realistic interpretation is:

- WFGY already has visible ecosystem traction
- the most mature interface today is the **diagnostic framework**
- the ProblemMap is currently the clearest adoption surface
- the frontier reasoning components are still emerging

This combination gives teams a practical entry point if they need more structured debugging for complex AI systems today, while also showing that the broader WFGY stack is still expanding.

---

# Related pages

Short adoption summary  
[ADOPTERS.md](https://github.com/onestardao/WFGY/blob/main/ADOPTERS.md)

Full ecosystem recognition log  
[WFGY Recognition Map](https://github.com/onestardao/WFGY/blob/main/recognition/README.md)

Collaboration and ecosystem participation  
[WORK_WITH_WFGY.md](https://github.com/onestardao/WFGY/blob/main/WORK_WITH_WFGY.md)

RAG failure taxonomy  
[RAG 16 Problem Map](https://github.com/onestardao/WFGY/blob/main/ProblemMap/README.md)

Global debugging card  
[Global Debug Card](https://github.com/onestardao/WFGY/blob/main/ProblemMap/wfgy-rag-16-problem-map-global-debug-card.md)