Two Faces of Phoenix
Same Phoenix. Same six agents. Same thesis. Two doors into the same room.
Project Phoenix exists in two forms — as an integrated layer within the Cormorant Foraging Framework, and as an independent methodology that stands entirely on its own.
Both are the same Phoenix. The difference is audience and context.
Face One: The Standalone Methodology
Home: semanticintent.dev/phoenix
Phoenix as a self-contained legacy modernization methodology. No framework dependencies. No prerequisite knowledge. A CTO, consulting partner, or developer can read it cold and understand the entire proposition in five minutes.
What it contains:
- The core thesis: the code is not the asset, the business logic is the asset
- The six-agent pipeline: Extractor → Archaeologist → Synthesizer → Architect → Builder → Validator
- The human layer: agents execute, humans decide
- The economics comparison: 18–36 months vs 3–6 months
- Link to UC-024 for the full industry cascade analysis
What it does not reference:
- Cormorant Foraging Framework
- Chirp, Perch, Wake (3D Foundation)
- DRIFT scoring
- Fetch action layer
- GESA episode learning
- Layer architecture (Layer 0 → Layer ∞)
This is deliberate. Phoenix succeeds when people adopt it, not when people understand the framework underneath it. Face One is the fruit. People eat the fruit. They don't need to see the roots.
The public path:
X / Search → UC-024 → semanticintent.dev/phoenix → Done.Three hops. Problem, analysis, solution. No detours.
Face Two: The Integrated Framework Layer
Home: phoenix.cormorantforaging.dev
Phoenix as the terminal layer of the Cormorant Foraging stack. Full architectural integration. Deep documentation of how Phoenix connects to every other layer and why it sits where it sits.
Cormorant Foraging (3D Foundation)
→ DRIFT (See the Gap)
→ Fetch (Close the Gap)
→ GESA (Learn Why)
→ Phoenix (Rebirth)Phoenix is invoked when the DRIFT is so extreme that no incremental action can close it — when the system itself is the problem. You don't optimize a burning building. You let it burn, preserve what matters, and rebuild.
Face Two shows:
- How 3D sensing (Chirp, Perch, Wake) identifies legacy systems as candidates for Phoenix
- How DRIFT scoring quantifies the gap between current state and target state
- How Fetch thresholds determine when to invoke Phoenix vs incremental improvement
- How GESA captures learnings across Phoenix engagements for continuous refinement
- The complete stack diagram from Layer 0 through Phoenix
- Integration points with 6D cascade analysis and the StratIQX case library
This is the intellectual architecture. The why it works underneath the what it does.
Why Two Faces
The distinction isn't about hiding the framework. It's about respecting the audience.
The person who needs Phoenix — the CTO with a failed migration, the consulting partner watching legacy costs compound, the developer drowning in legacy code — needs the pipeline. They need the six agents, the economics, the thesis. They need to believe it works and understand how to start. The Cormorant framework doesn't help them do that. It's a detour they didn't ask for.
The person who wants to understand Phoenix — the practitioner who adopted it and wants to know why it works, the architect who wants to integrate it into a larger system, the researcher studying AI-native methodologies — needs the depth. They want the layers, the scoring models, the feedback loops, the philosophical foundation.
Face One creates adoption. Face Two creates understanding. Both are necessary. Neither is sufficient alone.
The people who find Face Two will be the people who went looking. They found UC-024, read Phoenix on semanticintent.dev, got curious, and discovered the full architecture underneath. They pulled it toward themselves. That discovery is worth more than any link we could hand them.
The Connection
Face One lives at semanticintent.dev because Phoenix IS semantic intent applied to legacy systems — extract the meaning, discard the implementation, rebuild from intent.
Face Two lives at phoenix.cormorantforaging.dev because within the framework, Phoenix is the terminal layer — the action you take when sensing, measuring, and learning all point to the same conclusion: the old system must burn for the knowledge to rise.
Same Phoenix. Same six agents. Same thesis.
One says "here's what Phoenix does."
The other says "here's why Phoenix works."