Forge SDLC

Orientation: New to Forge? Start with What is ForgeSDLC?—a short definition. This page is the encyclopedia-style methodology overview (Ore → Spark → Charge, principles, scaling). Canonical prescriptive detail on forgesdlc.com includes the meetings model, Forge naming reference, and ceremonies (prescriptive). The artifact and decision model and CONCEPT-MAP.md live with the Blueprints framework (handbook + repo). The Blueprints handbook adds templates and deeper discipline navigation.

Why AI changes everything

Traditional delivery methodologies — Scrum, SAFe, Kanban, Waterfall — were designed for a world where humans write code and AI assists. That world is ending. AI agents now produce the majority of code, tests, and specifications in leading development teams. The human role has shifted from producer to governor. Forge SDLC is built for this inversion: humans own intent, judgment, and evidence-based release decisions; AI produces, and Versonas—discipline virtual personas whose activities include structured challenge passes—evaluate AI output before it ships.

What it is

Forge is a delivery methodology for work that benefits from rapid iteration, explicit challenge, and evidence-based release decisions. It keeps standard industry terms where the process is standard (backlog, refinement, planning, daily, review, retro, release) and introduces new terms only where the method is genuinely different.

Raw ideas enter as Ore, are refined into Ingots, decomposed into Sparks (the smallest meaningful executable unit), and selected into a daily Charge. Versonas (discipline virtual personas) apply discipline-specific judgment—including structured challenge passes that pressure-test work from each lens. Key decisions are captured in the Ember Log. Intentionally paused work is Banked. Release decisions pass an evidence-based Assay Gate.

Forge is not a rebranding of Agile — it is an extension of it for modern AI-enabled work. It improves clarity, decision quality, speed of learning, and release confidence.

Process diagram

Ore → Ingot → Spark → Charge → Review → Assay Gate → Release → learning feeds new Ore.

Core vocabulary (8 terms)

Exploration spikes (discipline)

A discipline exploration spike is time-boxed learning (feasibility, unknowns)—not a Forge Spark, which is the smallest delivery task. Spikes use Versona sessions under forge-logs/versona/, close with outputs/SPIKE-CLOSE.md, and may hand off to roadmap/WBS when anchors are missing. Full lifecycle: Discipline exploration spike.

Spark = Task (hierarchy mapping)

In projects using a milestone → epic → story → task hierarchy, Forge terms map directly to existing levels — no parallel namespace:

Spark IDs inherit from the project's WBS scheme (e.g. M1E1S1T1). Spark-specific data (state, DoD, journal) lives in forge-logs/, not in the requirements tree.

Mapping to this blueprint's SDLC

SDLC.md uses Phases A–F. Forge maps Sparks to phases via a prefix convention:

A Forge iteration typically contains Sparks across multiple phases.

Principles (summary)

1. Refine before you commit. Ore must become Ingot before execution.
2. Keep work small enough to challenge. Sparks make learning fast and waste visible.
3. AI strengthens thinking; humans own judgment. Versonas challenge, not decide.
4. Decisions deserve memory. The Ember Log captures why.
5. Release on evidence, not optimism. The Assay Gate makes release discipline explicit.
6. Paused is not failed. Banked is a strategic choice with preserved context.
7. Standard process stays standard. Forge adds precision inside standard meetings (see prescriptive package), not alternative rituals.
8. Scale by trust, not by process weight. Same vocabulary solo through enterprise.

Lean tenets (keeping Forge lightweight)

Forge must never add more ceremony than it removes waste. Key tenets:

• One hierarchy, one set of IDs. Sparks are existing Tasks with Forge semantics layered on — do not duplicate the WBS.
• Collapse levels when they already fit. If refinement already produces ready Stories, those are Ingots. No extra ceremony.
• Log decisions, not narration. Two lines explaining why beat two pages of session recap.
• Automate the journal. If logging feels like overhead, fix the tooling.
• Versonas at decision points, not everywhere. Before costly commitments, not as bureaucracy.
• Charge is a view, not a board. Label or filter, not a separate tracking surface.
• Scale formality to risk. Solo: self-assessment checklist. Enterprise: gate meeting.
• Defer tooling until volume demands it. Start with journal + git; add dashboards later.
• No shadow rituals. Standard Forge meeting names and mechanics inside—no parallel standing meetings for the same intent.

Scaling model

Prescriptive deep dive

Related guides

• Agentic SDLC — cross-cutting agent layer (Forge extends this with Versonas)
• Spec-driven development — durable specs complement Forge's Ingot refinement
• Scrum · Kanban · XP — Forge meetings map to the same C1–C6 foundation
• Ceremonies — Forge fork — C1–C6 mapped to Forge events
• Roles & archetypes — human accountability model