diff --git a/WORK_WITH_WFGY.md b/WORK_WITH_WFGY.md new file mode 100644 index 00000000..bd4c1ee7 --- /dev/null +++ b/WORK_WITH_WFGY.md @@ -0,0 +1,227 @@ + + +# Work with WFGY + +WFGY is an open-source reasoning and debugging framework for AI systems. +This page is the practical entry point for teams, sponsors, and contributors who want to work with WFGY in real settings. + +WFGY is currently most mature as a diagnostic and reasoning layer for broken RAG and agent pipelines, and is gradually expanding toward broader reasoning, stress-test, and long-horizon system interfaces. + +This page is not a sales brochure and not a donation page. It exists to make collaboration paths clear. + +## Who this is for + +WFGY is a good fit for people and teams who need structured debugging, reasoning design, or serious evaluation work. + +### 1. RAG and agent teams + +Teams whose systems run in production-like environments but still produce unstable, drifting, hallucinated, or poorly grounded outputs. + +### 2. Platform and infra owners + +Teams maintaining LLM, RAG, or agent platforms who want a more visible reasoning and debugging layer for internal or external users. + +### 3. Research and evaluation groups + +Groups designing stress tests, observables, failure taxonomies, or long-horizon reasoning benchmarks. + +### 4. Sponsors and collaborators + +People who believe in the direction of WFGY and want to help accelerate specific artifacts, benchmarks, docs, tools, or infrastructure. + +### 5. Contributors + +Engineers, researchers, writers, and operators who want to help extend the WFGY ecosystem in public. + +## Ways to work with WFGY + +### 1. Paid pilot or design partner collaboration + +This is the most direct path for teams that want to test WFGY against real system failures. + +Typical fit: + +- broken or unstable RAG systems +- agent workflows with recurring edge-case failures +- internal platforms that want a structured reasoning or debugging layer +- teams exploring whether WFGY can become part of a future product or platform interface + +Typical outputs may include: + +- structured failure mapping +- candidate root-cause lanes +- suggested next checks +- minimal fix directions +- a scoped pilot plan for further evaluation + +This path is best when your team already has a real system, real symptoms, and enough context to examine concrete failures. + +### 2. Reasoning and debugging architecture advisory + +This path is for teams that need help thinking at the level of structure, not just bug fixing. + +Typical fit: + +- redesigning a debugging workflow +- building a failure taxonomy +- designing evaluation logic for hard-to-debug AI systems +- planning reasoning interfaces, observables, or stress-test structures +- translating messy system behavior into a more coherent diagnostic model + +Typical outputs may include: + +- architecture advice +- failure-model design +- evaluation and observables design +- reasoning-layer framing +- suggestions for future system structure + +This path is for teams that want WFGY as a thinking partner on system design, not only as a troubleshooting checklist. + +### 3. Open-source sponsorship + +If your team benefits from the direction of WFGY and wants to accelerate specific open-source work, sponsorship is welcome. + +Examples include: + +- sponsoring a new diagnostic artifact +- sponsoring a benchmark or stress-test line +- sponsoring docs, tooling, or integration work +- sponsoring a specific module or public research direction + +This path supports open development while helping specific parts of the ecosystem move faster. + +### 4. Contributors and collaborators + +WFGY also welcomes people who want to help build, test, extend, or document the ecosystem. + +Examples include: + +- docs and onboarding improvements +- public integration evidence +- benchmark and evaluation work +- stress-test experiments +- contributor support for ecosystem mapping +- design, research, or implementation collaboration + +If you want to build with us in public, this is the right path. + +## What to send us + +If you contact us for collaboration, please include enough context to make the conversation concrete. + +A good first message usually contains: + +1. what kind of system or project you are working on +2. what is going wrong, or what you want to build +3. what you have already tried +4. whether the issue is reproducible +5. what kind of collaboration you are looking for +6. whether the case is public, private, or security-sensitive + +The clearer the initial context is, the more useful the next step will be. + +## What we usually provide + +Depending on the collaboration path, we usually provide some combination of the following: + +- structured failure mapping +- candidate causes and tension points +- recommended next checks +- suggested pilot scope +- architecture or reasoning-layer guidance +- references to the most relevant WFGY artifacts +- ideas for future observables, benchmarks, or diagnostics + +The exact form depends on the case. WFGY is not a one-size-fits-all service layer. + +## What we are not looking for + +To save everyone time, it is also helpful to be clear about what is not a fit. + +At this stage, we are primarily looking for: + +- design partners +- teams with real failure cases +- sponsors who want to accelerate open work +- contributors and collaborators who want to help build + +We are not actively looking for: + +- generic agency offers +- outbound vendor pitches +- unsolicited paid service sales +- low-context requests that expect immediate diagnosis without system details + +We care much more about real collaboration than generic business traffic. + +## What we do not claim + +WFGY is ambitious, but this page should stay precise. + +We do not claim: + +- that WFGY alone can solve every system problem +- that every collaboration will lead to production deployment +- that we currently offer enterprise SLA or managed-service guarantees +- that donation and sponsorship are the same as paid delivery +- that a short review without enough context is equivalent to a full diagnosis + +If a case needs deeper technical or security handling, we prefer to say so clearly. + +## Security and confidentiality + +For public and exploratory collaboration, the best starting points are: + +- GitHub issues +- GitHub discussions +- public ecosystem threads + +For security-sensitive, private, or confidential issues, please use the security contact path described here: + +- [SECURITY.md](./SECURITY.md) + +Please do not post sensitive production details in public if the case should be handled privately. + +## How to start + +If you want to work with WFGY, the simplest path is: + +1. identify the closest WFGY entry point + for example ProblemMap, Global Debug Card, or WFGY 3.0 + +2. prepare a short note with system context, symptoms, and goals + +3. choose the right path + public collaboration via issue or discussion + sensitive cases via SECURITY.md + +If the fit is good, we can decide the next step from there. + +## Useful entry points + +- [WFGY main repository](https://github.com/onestardao/WFGY) +- [RAG 16 Problem Map](https://github.com/onestardao/WFGY/blob/main/ProblemMap/README.md) +- [Global Debug Card](https://github.com/onestardao/WFGY/blob/main/ProblemMap/wfgy-rag-16-problem-map-global-debug-card.md) +- [WFGY 3.0 Event Horizon](https://github.com/onestardao/WFGY/blob/main/TensionUniverse/EventHorizon/README.md) +- [Recognition Map](https://github.com/onestardao/WFGY/blob/main/recognition/README.md) +- [Security Policy](https://github.com/onestardao/WFGY/blob/main/SECURITY.md)