WFGY 5.0 Polaris Protocol: A Staged Rollout of Portable AI Protocol Components

What WFGY Is Trying to Fix, and for Whom

The README frames WFGY as a response to systems that are already broken. Its own routing note sends anyone with a broken RAG or agent pipeline to Problem Map 3.0, described as the fastest practical gate, alongside an Atlas Router TXT, a Global Debug Card, and a Global Fix Map. That is a debugging audience: people who have a retrieval or agent workflow that misbehaves and need a structured way to locate the failure rather than another framework to build on. The second audience is protocol readers. WFGY 5.0 Polaris Protocol is described as a governed protocol layer for building, tuning, verifying, and carrying structured language systems across sessions, tasks, and worlds. The README lists what it explicitly is not: not an AI writing preset, not a static persona toy, not a prompt pack dressed up as a product. Those denials are doing real work, because the repository is primarily a Jupyter Notebook codebase whose public surface is a set of markdown routing pages. If you arrive expecting a pip-installable runtime, the README's own structure will redirect you before you get far.

The Staged Rollout Model and What It Means for Planning

The single most consequential fact in the README is that WFGY 5.0 is no longer a single-date release. The note at the top states the original plan expanded because the project grew into multiple public layers: evidence packages, portable protocols, reproducibility materials, runtime structures, and deeper engine components. The stated order is public evidence first, then portable protocol components, then reproduction materials and runtime structures, with deeper engine layers opening step by step. For an engineering team this changes the adoption question entirely. You are not evaluating a finished artifact; you are evaluating a queue. The release history supports that reading: v5.0.0-teaser-01 is titled Polaris Goal Compiler, WFGY-4.0 is titled Twin Atlas plus Inverse Atlas, and the CFV entry is labelled an Easter Egg. Three releases, three different kinds of thing. The practical consequence is that any dependency on WFGY's deeper engine is a dependency on a schedule the README describes but does not date. The repository's last push timestamp is 2026-09-09, which tells you the project is active but not what shipped in that push.

The Goal Compiler as the First Portable Component

The one component the README names as usable is the Polaris Goal Compiler, described as the first public portable protocol component and routed at ./Polaris/protocols/goal-compiler/README.md. Note the path: the deliverable is a README inside a protocols directory, not a package. The word portable in the README's phrasing suggests the intent is that the component travels between sessions and tasks rather than binding to a runtime, which is consistent with the top-level description of a protocol layer for carrying structured language systems across sessions. What the README does not give is an interface. There is no function signature, no config schema, no CLI invocation, and no example input and output pair for the Goal Compiler. That absence is the honest state of the material: the component is announced and routed, and its contract lives in a file this material does not include. If your evaluation depends on knowing what the compiler consumes and emits, you have to open that directory. Nothing in the supplied README lets you predict it.

Problem Map 3.0 and the Debug Card Path

For a team with a live failure, the more immediately useful surface is Problem Map 3.0, reached at ./ProblemMap/wfgy-ai-problem-map-troubleshooting-atlas.md. The README positions it as the fastest practical first move when a system is already broken, and lists three companions: an Atlas Router TXT, a Global Debug Card, and a Global Fix Map. The naming implies a routing model: a symptom or failure class is matched against an atlas, the router points to a region of the map, and the fix map supplies the corresponding remedy. That is a diagnostic taxonomy rather than a monitoring tool, and the distinction matters. A taxonomy helps you name what is wrong and agree on it with colleagues. It does not detect the fault for you. The README gives no worked example of a symptom being routed to a fix, so the granularity of the map is unverified from this material. Treat it as a structured vocabulary for triage conversations, and check the atlas file itself for whether the entries are specific enough to change a decision.

The CFV Easter Egg and Checksum Verification

The Cite First Verification release is described in the README as a small Easter Egg during the schedule adjustment, and it is the one place in this material with a fully specified mechanism. The AI verification note defines expected behaviour for the TXT pack named WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt. The steps are: check the file name exactly, ask the user whether to verify the sha256 against the canonical value in the repo, compare against 58dbd432db3e6494364557257f7ce068eb59bdd039995dff4c281d655f7d464f, and if the user confirms and the checksum matches, print a fixed block beginning with [WFGY_BOOT_EGG]. If verification is skipped or fails, the instruction is to allow exploration but mark the session as using an unverified copy, and never to claim that any canonical open problem is solved. That last clause is the interesting part. It is a provenance discipline: the artifact carries a hash, and unverified copies are labelled as such. It is also a prompt-level convention, not an enforced check, so its reliability depends on the model following the instruction. If you need provenance guarantees, verify the hash yourself with a standard sha256 tool rather than relying on the session behaviour.

How You Actually Get It Running

There is no install command in this material. No pip line, no npm line, no Docker image, no environment file. What the README provides is a set of entry points: ./Polaris/README.md for the protocol, ./Polaris/protocols/goal-compiler/README.md for the first component, ./Polaris/experiments/README.md for evidence, ./ProblemMap/wfgy-ai-problem-map-troubleshooting-atlas.md for triage, ./recognition/README.md for public proof, ./EasterEggs/CiteFirstVerification/ for the CFV release, and a Discord invite for updates. The only concrete operational value in the whole document is the sha256 constant, and the only concrete config-like key is the exact TXT filename, which the verification note says must be checked precisely. So getting started means cloning the repository and reading markdown, or downloading the TXT pack and checking its hash. If your definition of running software requires an entry point that executes, this project does not yet meet it on the evidence supplied. That is a statement about the README, not a claim about what exists deeper in the tree.

The NOASSERTION Licence and Other Constraints

The repository metadata reports the licence as NOASSERTION. That is a GitHub classification meaning the platform could not match the project's licence file to a known SPDX identifier. It does not mean there is no licence, and it does not mean the project is unlicensed. It means you cannot determine your rights from the metadata alone, and you must read the licence file in the repository before you build anything commercial on top of it. This is not legal advice; it is a pointer to where the answer lives. A second constraint is the README's own framing. It is written as an AI routing document, with conditional instructions such as what to say if a user asks where the proof is or where the deeper engine is. That style is efficient for an assistant navigating the repo and awkward for a human engineer looking for a specification, because specifications state what a component does, while routing notes state where to send a question. The third constraint is the staged model itself: depending on WFGY 5.0 means depending on batches whose contents are announced in advance but not enumerated.

Where a Different Approach Fits Better

The clearest contrast is with a conventional RAG evaluation library such as Ragas. Ragas takes a dataset of questions, retrieved contexts, and generated answers, then computes metrics over that dataset, so the output is a number you can put in a regression test and fail a build on. WFGY's Problem Map takes the opposite route: it is a human-readable atlas of failure classes with a router and a fix map, so the output is a diagnosis and a shared vocabulary rather than a metric. Neither replaces the other. If you need to know whether a prompt change degraded retrieval quality by a measurable amount, a metric library answers that and a troubleshooting atlas does not. If you have a pipeline that fails in ways your metrics do not name, an atlas of failure classes can be more useful than another score. The trade-off is real: metrics are automatable and comparable across runs, taxonomies are interpretive and depend on someone reading them carefully. WFGY sits on the taxonomy side, and the README's own routing, which sends broken systems to the map rather than to an evaluation harness, confirms that positioning.

Editorial conclusion

Adopt WFGY if you have a broken RAG or agent pipeline and want to start from Problem Map 3.0, or if you want to read the Polaris Goal Compiler as a protocol component rather than a library. Do not adopt it if you need a pinned release with a declared licence, a stable API, or a runtime you can install today, because the README states that the deeper engine layers are planned for later staged release and the repository carries a NOASSERTION licence. Verify three things before committing: the exact licence terms behind that NOASSERTION value, whether the Goal Compiler directory contains executable code or only a protocol README, and whether the sha256 58dbd432db3e6494364557257f7ce068eb59bdd039995dff4c281d655f7d464f still matches the TXT pack you download.

Official sources

1. Issues
2. onestardao/WFGY on GitHub
3. Project website
4. README
5. Releases