ForgeSDLC — concept map and term-collision register

Sources: Forge & planning — naming reference, Forge — artifact and decision model, Forge ↔ SDLC ↔ PDLC bridge, Forge — connection to the SDLC foundation, Forge — ceremonies & events (prescriptive), Forge — roles (prescriptive), ../../../README.md, Software development lifecycle, Product development lifecycle (PDLC), Software architecture body of knowledge.

---

Concept matrix

The table above is a summary. The subsections below preserve full definitions, boundaries, and cross-links so nuance is not lost when cells are shortened.

---

Detailed concept notes

ForgeSDLC (Forge SDLC)

• What it is: Forge is a delivery methodology that plugs into the shared blueprint foundation: tracking spine + ceremony intents C1–C6. It defines how a team refines, scrutinizes, executes, and releases work — Ore → Ingot → Spark → Charge, evidence at Assay Gate, Ember Log for decision memory, and Versonas for discipline lenses (see Forge — connection to the SDLC foundation).
• Boundaries: Forge does not replace generic Software development lifecycle or Product development lifecycle (PDLC); it operationalizes SDLC phases A–F with Forge-specific mechanics and artifacts.
• Iteration: A Forge iteration is a delivery cycle (often 1–2 weeks) inside a Product Spark; scope and evidence are assessed at the iteration boundary (Forge & planning — naming reference).
• Prescriptive shape: Phase-tagged Sparks (discover: … release:), traceability Ore → Ingot → Spark, Assay Gate non-negotiable for evidence-based release (Forge — connection to the SDLC foundation).
• Naming: Publish Forge SDLC or Forge with a link to the methodology overview; ForgeSDLC (one word) is acceptable in branding only if defined once — avoid mixing spellings without a glossary entry.

Blueprints

• What it is: The Blueprints repository is reusable documentation and process packages: sdlc/, pdlc/, disciplines/, and support packages — prescriptive framework text for any adopting project (README.md).
• Framework vs methodology: Blueprints is the framework (shared vocabulary, lifecycles, templates). Forge is one methodology (operating detail) within that ecosystem, not the whole repo.
• Consumption: Sites such as blueprints.forgesdlc.com are handbook outputs; the source of truth for definitions remains Markdown in the blueprints repo (submodule in consumers).

Versona

• What it is: A discipline-focused virtual persona — typically AI-instantiated (e.g. Cursor rules) — that brings a professional lens; it is not an org chart role (Forge — roles (prescriptive), Versonas — discipline-focused virtual personas).
• §5 output: Teams may use a §5-shaped structured concern report (Versona contract); other activities (advise, draft, handoffs) are equally valid per Versona framework — kinds, interfaces, processes, sessions.
• Families: Engineering, Data, Product, Governance, Cross-cutting (e.g. Security) — see Forge — roles (prescriptive) table.
• Accountability: Versonas assist judgment; humans own delivery, release, and Ember Log integrity.

Versona session

• What it is: One interaction with a Versona: a folder under forge-logs/versona/<actor>/<session-id>/, which may contain several activities (Versona framework — kinds, interfaces, processes, sessions §1).
• Not a meeting: Meetings are calendar-accountable team events. Versona sessions are bounded discipline work with a different storage model — they do not replace daily sync, retro, or gates (Forge & planning — naming reference § “Meetings vs ceremonies vs Versona sessions”).
• Challenge pass: Informal name for a §5-shaped discipline review — one possible session activity, not the global meaning of “Versona” (Forge & planning — naming reference).
• Artifacts: Session manifests, work_item_kind values (e.g. spark, spike_discipline), optional ember_log_ref when a decision is logged (Forge & planning — naming reference).

Meeting

• What it is: Scheduled, accountable team collaboration — the preferred public label for Forge events in prescriptive docs (Forge & planning — naming reference).
• Ceremony: The same events are ceremonies when tied to blueprint intent types C1–C6 (Ceremony foundation (methodology-neutral)). Meeting = external-friendly label; ceremony = foundation mapping — not three competing object types vs Versona sessions.
• Inventory: Ore intake, refinement, planning, daily sync, review, Assay Gate, retro — inputs/outputs in Forge — ceremonies & events (prescriptive).

Forge Spark

• What it is: The smallest delivery unit (~1–4 hours), often phase-prefixed (discover:, specify:, design:, build:, verify:, release:). It maps to WBS Task; Spark = Task — one hierarchy, one namespace, no duplicate WBS (Forge — deep-dive package (blueprint), Forge — major processes & flow maps).
• Not a spike: Exploration / discipline spikes are time-boxed learning with a different lifecycle — not Forge Sparks (Discipline exploration spike — lifecycle and anchors).
• Traceability: Prescriptive rule: every Spark that ships should be linkable to parent Ingot and original Ore (Forge — connection to the SDLC foundation).
• PRs: Implementation slices for build: and verify: Sparks (Forge — connection to the SDLC foundation).

Product Spark (release slice / product increment)

• What it is: A potentially shippable product slice — PoC, MVP, or phased increment. Aliases (same meaning): release slice, product increment (Forge & planning — naming reference).
• Why keep all three names: Product Spark is the canonical Forge head term; release slice and product increment help readers coming from other practices — they are not separate concepts.
• Grain: Spans multiple Forge iterations; roadmap and WBS alignment in Planning flow — vision to daily Sparks.
• Collision: Never conflate with Forge Spark (task-level).

Charge

• What it is: Today’s selected Forge Sparks — the daily commitment (Forge & planning — naming reference).
• View, not board: Charge is a label/filter on the existing backlog — not a second board or parallel system (Forge — connection to the SDLC foundation anti-patterns).
• Ceremony fit: Aligns with daily sync and C3 (Forge — connection to the SDLC foundation C3 — Plan the slice / Execute & unblock).

Ore

• What it is: Raw, unrefined intake — ideas, problems, opportunities — before refinement (Forge & planning — naming reference).
• Flow: Phase A (Discover) in the seven-phase benchmark map; continuous intake; feeds refinement Ore → Ingot (Forge — connection to the SDLC foundation).
• PDLC: Validated product problems from P1 feed the Ore pipeline (Forge ↔ SDLC ↔ PDLC bridge).

Ingot

• What it is: Refined, plannable work (often story-level) with acceptance criteria — the “spec” step between Ore and executable Sparks (Forge & planning — naming reference, Forge — connection to the SDLC foundation).
• Not: Not yet the Spark / task execution grain; not raw Ore.

Assay Gate

• What it is: An evidence-based release decision — e.g. market-ready vs code-only — with per-work-type evidence expectations (Forge & planning — naming reference, Planning flow — vision to daily Sparks).
• Anti-pattern: Skipping Assay Gate under schedule pressure is explicitly out of bounds in Forge prescriptive guidance (Forge — connection to the SDLC foundation anti-patterns).
• PDLC / SDLC: Ties to P4 Launch readiness and SDLC Release (F) / Verify (E) prep (Forge ↔ SDLC ↔ PDLC bridge).

PDLC

• What it is: Product development lifecycle — Forge documents P1–P6 in Product development lifecycle (PDLC): Discover problem → Validate solution → Plan & Commit → Launch → Grow → Mature/Retire (sunset).
• SDLC nesting: After P3, the generic SDLC runs as the Build & Release engine inside the product lifecycle (Product development lifecycle (PDLC) opening, PDLC ↔ SDLC bridge).
• Seven-phase benchmark: External “seven-stage” NPD language maps to P1–P6 for comparison; Forge does not claim seven public PDLC phases — see Benchmark map (seven-phase reference) and Forge & planning — naming reference.

SDLC

• What it is: Software delivery lifecycle in blueprint terms: Discover / Prioritize → Specify → Design → Build → Verify → Release — “building the product right” (Software development lifecycle).
• Shorthand: A–F is internal shorthand for bridges and examples; reader-facing names are primary on Software development lifecycle.
• Ceremony intents C1–C6: Recurring collaboration should cover these intent types over time; they do not replace artifact obligations (Software development lifecycle § “Ceremony intents vs phases”).

Decision Record (mapped term)

• Canonical mapping: This phrase is not a separate artifact type in Forge & planning — naming reference. Use Ember Log entries for operational decision memory: trade-offs, risk acceptance, scope/priority changes — stored under ember-logs/YYYY-MM-DD.md (Forge & planning — naming reference Ember Log, Daily operations).
• Separation from ADR: Ember Log captures why at decision points; ADRs capture architectural decisions with template structure (Software architecture body of knowledge).
• Project choice: Teams may add a local sdlc/ convention naming structured “decision records” if they still roll up to Ember Log and traceability rules.

Retro Record (mapped term)

• Canonical mapping: Retro outputs must be documented enough to feed directives — with evidence, owner, approval, and review/expiry per team governance (Forge — ceremonies & events (prescriptive) § “From retro to directives”).
• Minimum bar: Link retro notes, metrics, or Ember Log entries that justify directive changes; experiments may graduate into directive updates.
• Not: A duplicate artifact category if the same content is already captured as retro notes + PR to rules files — the important part is traceability, not the label “Retro Record.”

Directive

• What it is: Markdown files that govern how the team works — e.g. project sdlc/ rules, .cursor/rules/, team norms, ADR-style process decisions (Forge — ceremonies & events (prescriptive)).
• Lifecycle: Retros produce experiments; successful changes become directive updates with evidence and owners — not informal chat.

ADR (Architecture Decision Record); Technical Decision Record

• ADR: Significant architectural choices documented with context, decision, and consequences — see Software architecture body of knowledge §3 and the ADR row in ../../../disciplines/documentation/templates/README.md.
• Technical Decision Record: Use only as plain-language synonym for ADR in reader-facing copy. Do not use it as a second bucket for Ember Log lines or directives — that creates three-way confusion with Ember Log and directives.

---

Term-collision register

Known collisions and the canonical resolution (expand in Forge & planning — naming reference where cited).

Detailed collision notes

• Spark (three-way): (1) Forge Spark = WBS task-level delivery unit. (2) Product Spark = product slice (PoC/MVP/phase); aliases release slice, product increment. (3) Discipline / exploration spike = learning spike — see Discipline exploration spike — lifecycle and anchors. Product spike (informal) = discipline spike on product/strategy — not a fourth official spike type and not a Product Spark (Forge & planning — naming reference).
• Session vs meeting: Meetings carry human accountability on the calendar. Versona sessions live under forge-logs/versona/ and may occur inside or outside a meeting. Ceremonies name the same meetings when mapping C1–C6 (Forge & planning — naming reference § “Meetings vs ceremonies vs Versona sessions”).
• Gate (two layers): Assay Gate = Forge iteration release evidence decision. PDLC stage gates (e.g. G1–G5 in bridges) and Stage-Gate NPD gates = product lifecycle decisions — different scope; align using PDLC ↔ SDLC bridge and Forge ↔ SDLC ↔ PDLC bridge.
• Increment: Product increment as an alias of Product Spark must be distinguished from generic Scrum “Increment” or informal “slice” language — prefer Product Spark or Forge iteration when clarifying (Forge & planning — naming reference).
• Persona: Versona (capital V) = discipline virtual persona in Forge. User/persona in Product development lifecycle (PDLC) = market/user research artifact — disambiguate by context.
• Framework vs methodology: Blueprints = reusable framework packages. Forge = methodology (how to run delivery) sitting on top of generic SDLC/PDLC text — avoid calling the whole repo “the Forge methodology.”
• Decision artifacts (three buckets): Ember Log = day-to-day decision memory and trade-offs. ADR = architecture decisions. Directives = team working rules updated from retros with evidence — not interchangeable labels (Forge — ceremonies & events (prescriptive), Software architecture body of knowledge).

---

Blueprint reference — align with Forge & planning — naming reference when planning or roles change.

Related pages

• Forge — artifact and decision model
• Forge ↔ SDLC ↔ PDLC bridge
• Forge & planning — naming reference
• Product creation → delivery — industry, Fo…
• Forge — deep-dive package (blueprint)