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).

Autonomy level (L0–L8)

• What it is: The execution ladder for governed unattended agent work — each level defined by unit of autonomous delivery, what stays fixed, and where humans gate (Autonomy levels).
• Two finer axes: maturity grades a–d (Defined → Demonstrated → Repeatable → Operational) on every level, and sub-levels L1.1–L4.3 in the L1–L4 band. Notation L<level>.<sub><grade> plus scope, e.g. L2.2c in forge-lenses. Per-project scoring: Autonomy maturity framework.
• Not: LCDL schema maturity (L0–L4 contract rigor); standards precedence (L1–L6 policy stack); binary “autonomous on/off”; Wizard planning enum without matching runtime execution. Sub-level decimals (L2.2) belong only to the execution ladder — no other L-scheme in this workspace uses decimals.
• Demonstrated today: L1–L3 in Forge Dark Factory PoC with machine evidence — see bounded execution examples (retro-tagged L1.1b, L1.2b, L2.2b, L3.1b). L4–L8 are vision with explicit ADR, go/no-go, and strategic gates.
• Operator surface: Platform autonomy hub — readiness matrix and per-level building-block architecture.

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).
• Level / L3 (three-way): Autonomy L3 = end-to-end use-case slice in one app (logic + docs + UI + E2E evidence). LCDL schema L3 = contract maturity band in forge-lcdl docs — unrelated ladder. Standards precedence L3 = position in the Forge standards stack — unrelated ladder. Use autonomy level or execution L3 when scoping unattended runs (Autonomy levels).

---

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

Executive capsule

Purpose: Single-page canonical concept matrix (how core terms relate to lifecycles, owners, artifacts, and meetings) and a term-collision register for known ambiguities. Detailed term → path mapping remains in Forge & planning — naming reference. Maturity: defined.

Who this is for

Hands-on engineers at the discover stage. Skim the executive capsule first; agents should respect the page frontmatter contract.

Evidence and maturity

Maturity: defined. Statements here reflect the owning repo (blueprints) at last_reviewed; treat anything not explicitly marked as demonstrated as design direction rather than a shipped guarantee.

Trust boundary

Forge keeps humans in charge of promotion, approval, and release decisions; automation proposes and executes only within approved boundaries described here.

How to use this page

Read top-to-bottom at your depth: capsule for the decision, mechanism for design, links below for the next step in your journey.

The problem this solves

Teams adopting AI-assisted delivery need structure they can trust before they scale it. This page addresses that gap for its topic: it explains the situation the reader is in, the failure mode without the mechanism described here, and the outcome when it is applied.

How it fits the Forge ecosystem

This page belongs to its owning repo's canonical documentation and links outward to the related Forge surfaces (methodology in Blueprints, product docs in each product handbook, adoption narrative on forgesdlc.com). Follow the related links to stay on the governed path.

Related

See the owning repo's documentation index for neighboring pages.

Related pages

• Forge — artifact and decision model
• Autonomy levels
• Autonomy maturity framework
• Bounded execution examples
• Cost-aware planning and model tiering