SAFe ↔ FCC Vocabulary Reconciliation

Status: CANONICAL. This is the single source of truth for translating SAFe terms into the FCC three-layer convention and back. Maintained by the SAFe-FCC Bridge Interpreter (SFBI) persona.

Origin: this table was absorbed from the ice_ext project's ROADMAP.md in v1.4.1 as part of the ice_ext absorption pillar. FCC adopts it verbatim as the ecosystem-wide canonical.

The canonical table

SAFe term	FCC term (used here)	Artifact
Portfolio Epic	Layer 1: Emergent Design	ROADMAP.md
Program Epic / Capability	Layer 2: Intentional Architecture	STRATEGIC_ARCHITECTURE_REVIEW.md
Solution Intent / Enabler	Layer 3: Protocol Architecture	AGENTS.md
Program Increment (PI)	Release	CHANGELOG + docs/safe/pi-calendar.md
PI Objective	Release exit gate	bolded line per release in ROADMAP / CHANGELOG
Enabler Story (20-30%)	CI / docs / FTO / scaffolding	called out per release
Feature	Patent claim or FCC integration surface	traceability matrix in ARCHITECTURE.md

Narrative: why we mapped it this way

SAFe 6.0 ships with a clear vertical stack — Portfolio Epic → Program Epic → Feature → Story → Task — designed for organizations running multiple Agile Release Trains at program level and coordinating across a portfolio tier. The canonical vocabulary is battle-tested and, for organizations adopting SAFe fresh, it's the fastest way to get everyone speaking the same language.

FCC was not adopting SAFe fresh. Before v1.4.1, FCC already had a three-layer documentation convention codified across its repositories: ROADMAP.md captured the emergent, iterative roadmap (what we discovered we needed to build); STRATEGIC_ARCHITECTURE_REVIEW.md captured the intentional architecture (what we decided should exist and why); and AGENTS.md captured the protocol architecture (how agents actually interact at the contract surface). This was originally an ice_ext convention that proved useful enough that the wider ecosystem absorbed it.

Faced with SAFe adoption in v1.4.1, FCC had two options: rename its three layers to SAFe terms (losing the design-discovery-to-protocol semantics the ice_ext pattern captured), or publish a reconciliation table that lets both vocabularies coexist. The ice_ext project had already done this at the top of its own ROADMAP.md, and the mapping worked cleanly in practice: Portfolio Epics map naturally to Layer 1 because both are emergent-scale, quarter-to-multi-quarter, discovery-first; Program Epics map to Layer 2 because both are PI-scoped architectural specifications; Solution Intent / Enablers map to Layer 3 because both are contract-surface protocol specifications. FCC adopted the ice_ext reconciliation table verbatim in v1.4.1, which is what you are reading.

The reconciliation is not a lossy translation. Both vocabularies remain valid simultaneously. A portfolio-tier stakeholder reviewing FCC's roadmap can legitimately call a line item "Portfolio Epic PE-007" or "Layer 1 patent-delegation emergent-design item"; both reference the exact same artifact. The SAFe-FCC Bridge Interpreter (SFBI) persona is responsible for keeping that duality honest. When vocabulary drifts — for example, when an ecosystem project starts using "Feature" to mean Layer 2 content instead of Layer 3 contract surface — SFBI authors a bridge report with source + line references and publishes it so the drift can be corrected.

Below the table line, two nuances deserve calling out:

Program Increment ↔ Release. SAFe treats the PI as a 10-week time box and uses it as the primary planning unit. FCC treats Release (a tagged, published, versioned unit) as the planning unit because FCC's PyPI publishing cadence is the load-bearing boundary for downstream consumers. A PI in the FCC SAFe instance is always aligned to a release; the two terms can be used interchangeably as long as the PI calendar (pi-calendar.md) shows the alignment clearly. This mapping is borrowed directly from ice_ext.

Enabler Story ↔ CI / docs / FTO / scaffolding. SAFe recommends reserving 20-30% of PI capacity for enabler stories — the architectural, infrastructure, compliance, and exploration work that keeps future delivery possible. FCC's equivalent is all of CI hygiene, docs-as-code maintenance, FTO (freedom-to-operate) analysis, vocabulary-parity audits, and scaffold generation. These map cleanly onto SAFe's enabler category, and the 20-30% capacity target carries over.

Usage rules

• The canonical reconciliation table in this file is the single source of truth. No ad-hoc renaming anywhere in the ecosystem.
• Every translation in a bridge report must cite source artifact + line reference. SFBI enforces this.
• Authors pick the vocabulary that suits their audience; both are equally valid. SAFe-fluent stakeholders can use SAFe terms; FCC-native contributors can use the three-layer terms. The mapping keeps them synchronized.
• Drift is a signal, not a failure. When an ecosystem project uses "Feature" inconsistently (e.g., to mean Layer 1 emergent intent rather than Layer 3 contract surface), SFBI flags it — but the fix is a PR with cited evidence, not a silent rename.
• Extension candidates are welcomed. When a SAFe term lacks a clean FCC mapping (or vice versa), SFBI flags it as an extension candidate. Governance Compliance Auditor (GCA) owns the extension-review process.

Related personas

• SFBI (SAFe-FCC Bridge Interpreter) — owns this table, authors bridge reports, supplies translation hint feeds to SMC and TLDR. See src/fcc/data/personas/safe_fcc_bridge_interpreter.yaml.
• SMC (SAFe Metrics Crafter) — consumes translation hints from SFBI to keep PI scorecard vocabulary aligned. See src/fcc/data/personas/safe_metrics_crafter.yaml.
• TLDR (Three-Layer Doc Reconciler) — enforces ROADMAP/SAR/AGENTS three-layer convention across every ecosystem project, consuming SFBI translation hints. See src/fcc/data/personas/three_layer_doc_reconciler.yaml.
• VDS (Vocabulary Drift Sentinel) — monitors SHA-256 parity across the 13+ VocabularyProviderPlugins; complementary to SFBI's vocabulary-translation work but focused on cryptographic integrity rather than terminology. See src/fcc/data/personas/vocabulary_drift_sentinel.yaml.

Related documents

• ROADMAP.md — Layer 1 Emergent Design canonical.
• STRATEGIC_ARCHITECTURE_REVIEW.md — Layer 2 Intentional Architecture canonical.
• AGENTS.md — Layer 3 Protocol Architecture canonical.
• ARCHITECTURE.md — traceability matrix mapping Features ↔ patent claims + integration surfaces.
• CHANGELOG.md — historical PI / Release record.
• portfolio/epics.md — 9 portfolio epics in YAML front-matter form.
• pi-calendar.md — 4-PI rolling calendar aligned to RC.

References

• SAFe 6.0 framework. Scaled Agile, Inc. https://scaledagileframework.com/
• ice_ext ROADMAP.md header table — origin of this reconciliation pattern.
• FCC v1.4.1 release notes — ice_ext absorption pillar.