# Architecture Runway Plan: [Agile Release Train, product or solution name]

> Plan for building and maintaining the architectural runway of one
> agile release train, product or solution: the existing code,
> components and technical infrastructure that the next features need
> so they can be delivered without major redesign or delay. It records
> the architectural intent and guardrails (what is decided up front and
> what is left to emerge), the upcoming features, the current runway
> and its gaps, the enabler backlog, spikes, capacity allocation,
> sequencing, governance and runway health metrics. Terminology follows
> the Architectural Runway and Enabler concepts of the Scaled Agile
> Framework (SAFe 6.0, Core SAFe; AI-Native SAFe, introduced in June
> 2026, builds on it) and the intentional versus emergent architecture
> distinction found in agile architecture practice, including the Open
> Agile Architecture standard. Replace every `[bracketed]` value and
> every row marked *Example*.

<!--
Guidance: How to use this template
- Write one plan per release train, product or solution, and revise it
  before every planning interval (PI) planning event. It is a living
  document, not a one-time design.
- Start with section 3 (upcoming features). Runway is only useful in
  relation to the work that will consume it; enablers with no feature
  waiting for them are speculative architecture.
- Fill section 2 (intent and guardrails) with the architecture lead and
  the teams together. The aim is the smallest set of decisions that
  must be taken centrally; everything else is left to the teams.
- Keep enablers small enough to finish within one PI, with acceptance
  criteria, so the system stays releasable while the runway grows.
- Related documents: Architecture roadmap and transition architectures
  (`architecture/architecture-roadmap-transition`), Technical debt
  register (`architecture/tech-debt-register`), Fitness functions
  (`architecture/fitness-functions`), CBAM cost-benefit analysis
  (`architecture/cbam-analysis`), Quality attribute scenarios
  (`requirements/quality-attributes`), Architecture principles
  (`architecture/architecture-principles`), Platform golden path
  (`architecture/platform-golden-path`), Product roadmap
  (`product/roadmap`), Release plan (`product/release-plan`).
-->

## Document control

<!-- Guidance: Identify the train or solution, the planning horizon and who owns the runway. Update the version before every PI planning; the revision history then becomes a record of how the runway evolved. -->

| Field | Value |
|---|---|
| Document ID | [ARP-001] |
| Release train, product or solution | [Name] |
| Teams covered | [Team names or count] |
| Planning horizon | [Current PI and next n PIs, with dates] |
| PI cadence | [Length in weeks and iterations per PI] |
| Version | [0.1] |
| Status | [Draft / In review / Approved for PI planning / Superseded] |
| Owner | [@system-architect] |
| Approvers/reviewers | [@product-management], [@release-train-engineer], [@enterprise-architect], [@team-representatives] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| System or solution architect | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Product management | [@name] | [Decision] | YYYY-MM-DD |
| Release train engineer | [@name] | [Decision] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for PI [n] planning |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved at PI [n] planning; 25 percent enabler capacity agreed |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Revised after PI [n] system demo; ENB-03 replanned after SPK-02 result |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose, scope and planning horizon](#1-purpose-scope-and-planning-horizon)
2. [Architectural intent and guardrails](#2-architectural-intent-and-guardrails)
3. [Upcoming features and capabilities](#3-upcoming-features-and-capabilities)
4. [Current runway inventory](#4-current-runway-inventory)
5. [Runway gap analysis](#5-runway-gap-analysis)
6. [Enabler backlog](#6-enabler-backlog)
7. [Spikes and exploration](#7-spikes-and-exploration)
8. [Capacity allocation](#8-capacity-allocation)
9. [Sequencing and dependencies](#9-sequencing-and-dependencies)
10. [Governance and decision rights](#10-governance-and-decision-rights)
11. [Runway health metrics](#11-runway-health-metrics)
12. [Risks and assumptions](#12-risks-and-assumptions)
13. [Glossary and references](#13-glossary-and-references)

## 1. Purpose, scope and planning horizon

<!-- Guidance: Say which system the runway serves, how far ahead the plan looks and what is out of scope. A runway that is too short forces teams to build infrastructure inside feature work; one that is too long ties up capacity in architecture nobody uses yet. Two to three PIs ahead is a common horizon; justify yours. -->

### 1.1 Purpose

[One paragraph: why the runway matters now for this train, which
business outcomes depend on it and which decision this plan informs.]

*Example:* The merchant payments train (8 teams) will launch two new
markets and an instant payout product over the next three PIs. Each
needs capabilities the platform lacks today: a provider adapter layer,
multi-currency ledger support, regional data residency and an event
backbone for payout status. This plan identifies the enablers that
must land one PI ahead of the features that depend on them and the
capacity the train will reserve for them.

### 1.2 Scope

| In scope | Out of scope |
|---|---|
| [Systems, components, platforms owned by the train] | [Shared enterprise platforms owned elsewhere, listed as dependencies in section 9] |
| [Infrastructure and environments used by the train] | [Feature design, which belongs to the teams] |

### 1.3 Planning horizon

| PI | Dates | Planning status | Runway expectation |
|---|---|---|---|
| PI [n] (current) | YYYY-MM-DD to YYYY-MM-DD | Committed | Enablers in progress must finish |
| PI [n+1] | YYYY-MM-DD to YYYY-MM-DD | Planned at next PI planning | Runway for PI [n+2] features built here |
| PI [n+2] | YYYY-MM-DD to YYYY-MM-DD | Forecast | Runway needs identified; spikes running |
| PI [n+3] | YYYY-MM-DD to YYYY-MM-DD | Vision | Major intentional decisions only |

## 2. Architectural intent and guardrails

<!-- Guidance: Separate what must be decided up front (intentional architecture) from what teams discover while building (emergent design). Intentional decisions are few, cross-cutting and expensive to change; emergent decisions are local and cheap to change. Pitfall: treating every decision as intentional, which recreates big up-front design under another name. -->

### 2.1 Intent statement

[Three to five sentences: the architectural direction the runway
moves toward, linked to the architecture roadmap
(`architecture/architecture-roadmap-transition`) and principles
(`architecture/architecture-principles`).]

*Example:* Every payment flow runs through a provider-neutral core with
adapters at the edge. State changes are published as events on a
single backbone, and consumers never read another service's database.
Data for each market stays in its residency region. Teams choose their
own internal design within these rules.

### 2.2 Intentional or emergent

Use the criteria below to place each architecture decision.

| Criterion | Points to intentional (decide centrally, early) | Points to emergent (teams decide while building) |
|---|---|---|
| Cost of reversal | High: data migration, contract changes for many consumers | Low: change inside one service |
| Scope of effect | Several teams or the whole train | One team |
| Regulatory or contractual exposure | Present | Absent |
| Lead time to provide | Longer than one PI | Within an iteration |
| Learning still needed | Little: options are understood | A lot: build to learn |

| ID | Decision | Classification | Owner | Recorded in |
|---|---|---|---|---|
| DEC-INT-01 | *Example:* Event backbone technology and topic naming | Intentional | System architect | ADR-041 |
| DEC-INT-02 | *Example:* Provider adapter port contract | Intentional | System architect with payments teams | ADR-042 |
| DEC-INT-03 | *Example:* Regional data residency pattern | Intentional | Enterprise architecture | ADR-043 |
| DEC-EMG-01 | *Example:* Caching strategy inside the pricing service | Emergent | Pricing team | Team ADR |
| DEC-EMG-02 | *Example:* Internal module structure of each adapter | Emergent | Adapter teams | Team ADR |
| [DEC-INT-nn / DEC-EMG-nn] | [Decision] | [Intentional / Emergent] | [Owner] | [ADR ID] |

### 2.3 Guardrails

Guardrails are the rules every team follows so that emergent design
stays compatible with the intent. State each as a rule that can be
checked, and automate the check where possible.

| ID | Guardrail | Check | Fitness function |
|---|---|---|---|
| GR-01 | *Example:* Services publish state changes as events; no cross-service database reads | Dependency analysis in CI | FF-04 |
| GR-02 | *Example:* Every provider integration goes through the adapter port | Architecture unit test | FF-05 |
| GR-03 | *Example:* Personal data for a market is stored only in that market's region | Policy as code in deployment pipeline | FF-09 |
| GR-04 | *Example:* New public APIs follow the API design guidelines | Linting of API specification | FF-02 |
| [GR-nn] | [Rule] | [How checked] | [FF ID in `architecture/fitness-functions`] |

## 3. Upcoming features and capabilities

<!-- Guidance: List the features and capabilities planned for the horizon, from the program or solution backlog, with the runway each needs. This is the demand side of the plan. Ask product management for the real forecast, not a wish list, and mark the confidence of each item. -->

| ID | Feature or capability | Target PI | Business priority | Forecast confidence | Runway needed |
|---|---|---|---|---|---|
| FEAT-01 | *Example:* Launch payments in market B | PI n+2 | High | High | Provider adapter layer, multi-currency ledger, residency in region B |
| FEAT-02 | *Example:* Instant payouts to merchants | PI n+2 | High | Medium | Event backbone, payout status events, ledger real-time balance |
| FEAT-03 | *Example:* Add wallet provider W | PI n+1 | Medium | High | Provider adapter layer |
| FEAT-04 | *Example:* Merchant self-service refunds | PI n+1 | Medium | High | Existing refund API (runway present) |
| FEAT-05 | *Example:* Launch payments in market C | PI n+3 | Medium | Low | Residency in region C, local scheme connector |
| FEAT-06 | *Example:* Real-time fraud signals to merchants | PI n+3 | Low | Low | Event backbone, streaming analytics |
| [FEAT-nn] | [Name] | [PI] | [High / Medium / Low] | [High / Medium / Low] | [Runway elements] |

## 4. Current runway inventory

<!-- Guidance: Record what runway already exists and how healthy it is. An element that exists but cannot carry the load or is due for retirement is not runway. Be honest about state; this table drives the gap analysis. -->

| ID | Runway element | Type | State | Capacity or limits | Owner | Notes |
|---|---|---|---|---|---|---|
| RWY-01 | *Example:* Payments core and refund API | Component | Ready | 400 payments per second tested | Core team | Carries FEAT-04 without change |
| RWY-02 | *Example:* Single-currency ledger | Component | Partial | One currency per merchant | Ledger team | Blocks FEAT-01 |
| RWY-03 | *Example:* Region A cloud foundation | Infrastructure | Ready | One region only | Platform team | Landing zone per `architecture/landing-zone-design` |
| RWY-04 | *Example:* Point-to-point provider integrations | Component | Obsolete | Each new provider costs about 12 person-weeks | Payments teams | Replaced by adapter layer |
| RWY-05 | *Example:* Message queue per service | Infrastructure | Partial | No shared schema, no replay | Platform team | Precursor to event backbone |
| RWY-06 | *Example:* CI/CD pipeline with security scanning | Tooling | Ready | All teams onboarded | Platform team | |
| [RWY-nn] | [Element] | [Component / Infrastructure / Tooling / Compliance] | [Ready / Partial / Missing / Obsolete] | [Limits] | [Owner] | [Notes] |

## 5. Runway gap analysis

<!-- Guidance: Compare the runway each upcoming feature needs (section 3) with what exists (section 4). Each gap becomes one or more enablers. Record when the gap must be closed: normally at least one PI before the dependent feature starts, so that feature teams consume the runway rather than build it. -->

| ID | Gap | Features blocked | Runway elements affected | Needed by | Closed by |
|---|---|---|---|---|---|
| GAP-01 | *Example:* No provider-neutral adapter layer | FEAT-01, FEAT-03 | RWY-04 | Start of PI n+1 | ENB-01 |
| GAP-02 | *Example:* Ledger cannot hold more than one currency per merchant | FEAT-01 | RWY-02 | Start of PI n+2 | ENB-02 |
| GAP-03 | *Example:* No shared event backbone with schemas and replay | FEAT-02, FEAT-06 | RWY-05 | Start of PI n+2 | ENB-03, SPK-02 |
| GAP-04 | *Example:* No foundation in region B for resident data | FEAT-01 | RWY-03 | Start of PI n+2 | ENB-04 |
| GAP-05 | *Example:* No evidence that payout flows meet the scheme's settlement rules | FEAT-02 | None | End of PI n+2 | ENB-05 |
| [GAP-nn] | [Gap] | [FEAT IDs] | [RWY IDs] | [PI] | [ENB or SPK IDs] |

```mermaid
flowchart LR
  ENB01["ENB-01 Adapter layer"] --> FEAT03["FEAT-03 Wallet W (PI n+1)"]
  ENB01 --> FEAT01["FEAT-01 Market B (PI n+2)"]
  ENB02["ENB-02 Multi-currency ledger"] --> FEAT01
  ENB04["ENB-04 Region B foundation"] --> FEAT01
  SPK02["SPK-02 Backbone spike"] --> ENB03["ENB-03 Event backbone"]
  ENB03 --> FEAT02["FEAT-02 Instant payouts (PI n+2)"]
  ENB05["ENB-05 Settlement compliance evidence"] --> FEAT02
```

## 6. Enabler backlog

<!-- Guidance: Each enabler is a backlog item that extends the runway, sized and accepted like any feature. Classify it (exploration, architecture, infrastructure, compliance). Split large enablers so each part finishes within one PI and leaves the system working. Pitfall: enablers without acceptance criteria, which never finish. -->

### 6.1 Enabler list

| ID | Enabler | Type | Closes | Size (team-iterations) | Target PI | Owning team | Status |
|---|---|---|---|---|---|---|---|
| ENB-01 | *Example:* Provider adapter port, two reference adapters and contract test kit | Architecture | GAP-01 | 5.0 | PI n | Payments team 1 | In progress: 3.0 remaining, slipping into PI n+1 |
| ENB-02 | *Example:* Multi-currency balances and FX postings in the ledger | Architecture | GAP-02 | 2.0 | PI n+1 | Ledger team | Ready |
| ENB-03 | *Example:* Event backbone with schema registry and replay, first two producers | Infrastructure | GAP-03 | 1.5 | PI n+1 | Platform team | Waiting for SPK-02 |
| ENB-04 | *Example:* Region B landing zone and data residency controls | Infrastructure | GAP-04 | 1.0 | PI n+1 | Platform team | Ready |
| ENB-05 | *Example:* Settlement rule test suite and evidence pack for payouts | Compliance | GAP-05 | 0.5 | PI n+1 | Payouts team | Ready |
| [ENB-nn] | [Enabler] | [Exploration / Architecture / Infrastructure / Compliance] | [GAP IDs] | [Size] | [PI] | [Team] | [Status] |

### 6.2 Enabler definition

Write one block per enabler that is planned for the next PI.

**ENB-02** *(Example)*: multi-currency balances and FX postings

| Field | Value |
|---|---|
| Benefit hypothesis | Merchants in market B can hold balances in local currency, which is a launch condition for FEAT-01 |
| Scope | Ledger schema for multiple currencies per merchant, FX posting type, balance API version 2 |
| Out of scope | FX rate sourcing (existing treasury service), reporting changes |
| Acceptance criteria | 1. A merchant can hold balances in at least two currencies. 2. Every FX posting balances in both currencies. 3. Balance API version 1 keeps working for existing consumers. 4. Load test at current peak shows no p99 regression above 10 percent. |
| Guardrails respected | GR-01 (balance changes published as events) |
| Fitness functions added or updated | FF-11 ledger double-entry invariant check |
| Dependencies | Treasury FX rate API (external to train) |
| ADR | ADR-044 |

**[ENB-nn]**: [title]

| Field | Value |
|---|---|
| Benefit hypothesis | [Which features it enables and the outcome expected] |
| Scope | [What it delivers] |
| Out of scope | [What it does not] |
| Acceptance criteria | [Numbered, testable criteria] |
| Guardrails respected | [GR IDs] |
| Fitness functions added or updated | [FF IDs] |
| Dependencies | [Teams, platforms, suppliers] |
| ADR | [ADR ID] |

### 6.3 Enabler readiness checklist

- The enabler closes a named gap that blocks a named feature.
- Acceptance criteria are testable and include at least one quality
  measure taken from a scenario in `requirements/quality-attributes`.
- Its size fits within one PI for the owning team, or it has been
  split into parts that each do.
- The system remains releasable at the end of every iteration while
  the enabler is built.
- The team that will consume the runway has reviewed the interface; for
  new interfaces consider an ARID review (`architecture/arid-design-review`).
- Run costs and operational ownership after delivery are agreed.

## 7. Spikes and exploration

<!-- Guidance: Use time-boxed spikes when an enabler cannot be sized or designed because an important question is still open. A spike ends with an answer and a recommendation, not with production code. Record what would change the plan. -->

| ID | Question | Time box | Owner | Options explored | Decision it informs | Result |
|---|---|---|---|---|---|---|
| SPK-01 | *Example:* Can the existing ledger database partition by currency without downtime? | 1 iteration | Ledger team | Online repartition, new table set with backfill | ENB-02 design | *Example:* New table set with backfill; online repartition locks too long |
| SPK-02 | *Example:* Which event backbone meets replay and ordering needs at forecast volume? | 1 iteration | Platform team | Managed log service, self-hosted log cluster, existing queues with outbox | ENB-03 technology choice (DEC-INT-01) | [Pending] |
| SPK-03 | *Example:* Does market C's scheme require a local data processor? | 2 weeks | Compliance and architecture | Legal review, scheme rulebook review | FEAT-05 runway scope | [Pending] |
| [SPK-nn] | [Question] | [Duration] | [Owner] | [Options] | [Decision] | [Result] |

Where a spike compares several architectural strategies with a cost
and benefit, a short CBAM (`architecture/cbam-analysis`) can rank them
before the enabler is committed.

## 8. Capacity allocation

<!-- Guidance: Agree before PI planning what share of the train's capacity goes to new features, enablers and maintenance or debt reduction. Base the enabler share on the gap list, not on a fixed habit. Revisit it every PI: a train that keeps underfunding enablers pays later in slower features. -->

### 8.1 Allocation for the next PI

| Category | Share | Team-iterations | Content |
|---|---|---|---|
| Features | *Example:* 60 percent | 19.2 | FEAT-03, FEAT-04 and committed business work |
| Enablers (runway) | *Example:* 25 percent | 8.0 | ENB-02, ENB-03, ENB-04, ENB-05 and remainder of ENB-01 |
| Maintenance and technical debt | *Example:* 15 percent | 4.8 | Items from `architecture/tech-debt-register` |
| Total | 100 percent | *Example:* 32.0 (8 teams x 4 development iterations) | |

*Example:* Enabler demand for the next PI is ENB-02 (2.0), ENB-03
(1.5), ENB-04 (1.0), ENB-05 (0.5) and the remaining 3.0 of ENB-01,
which has slipped from the current PI: 8.0 team-iterations, equal to
the 25 percent allocation. Any further slip in ENB-01 would push ENB-03
out, and with it FEAT-02.

### 8.2 Allocation history

| PI | Features | Enablers | Maintenance and debt | Enablers completed / planned | Comment |
|---|---|---|---|---|---|
| PI n-2 | *Example:* 75 percent | 10 percent | 15 percent | 2 / 3 | Feature pressure before launch |
| PI n-1 | *Example:* 70 percent | 15 percent | 15 percent | 3 / 4 | Adapter work started |
| PI n | *Example:* 65 percent | 20 percent | 15 percent | [n / n] | Current |
| [PI] | [Share] | [Share] | [Share] | [n / n] | [Comment] |

### 8.3 Allocation rules

- Reserve enabler capacity for gaps whose dependent features start
  within the next two PIs; defer the rest.
- Do not borrow enabler capacity for features without product
  management and the system architect agreeing, and record the
  consequence on the dependent feature dates.
- Use the innovation and planning iteration for spikes and runway
  hardening where the train's cadence includes one.

## 9. Sequencing and dependencies

<!-- Guidance: Show when each enabler lands relative to the features that consume it, and which dependencies lie outside the train. Make the "one PI ahead" rule visible: an enabler finishing in the same PI as its feature is a schedule risk. -->

```mermaid
gantt
  title Runway and feature sequencing (Example)
  dateFormat YYYY-MM-DD
  axisFormat %b
  section Enablers
  ENB-01 Adapter layer          :e1, 2026-07-01, 2026-12-08
  ENB-02 Multi-currency ledger  :e2, 2026-11-11, 2027-01-19
  SPK-02 Backbone spike         :s2, 2026-11-11, 2026-11-24
  ENB-03 Event backbone         :e3, after s2, 2027-01-19
  ENB-04 Region B foundation    :e4, 2026-11-11, 2026-12-22
  section Features
  FEAT-03 Wallet W              :f3, 2026-12-09, 2027-01-19
  FEAT-01 Market B              :f1, 2027-01-20, 2027-03-30
  FEAT-02 Instant payouts       :f2, 2027-01-20, 2027-03-30
```

| ID | Dependency | Provider | Needed by | Status | Fallback |
|---|---|---|---|---|---|
| DEP-01 | *Example:* Treasury FX rate API version 2 | Treasury train | ENB-02 start | Committed in their PI plan | Use version 1 with daily rates for launch |
| DEP-02 | *Example:* Region B approval by enterprise cloud board | Enterprise architecture | ENB-04 start | Requested | Delay FEAT-01 by one PI |
| DEP-03 | *Example:* Scheme certification slot for payouts | External scheme | FEAT-02 release | Booked | Next available slot is 8 weeks later |
| [DEP-nn] | [Dependency] | [Team or supplier] | [Milestone] | [Status] | [Fallback] |

*Example:* PI n runs from 2026-09-02 to 2026-11-10, PI n+1 from
2026-11-11 to 2027-01-19 and PI n+2 from 2027-01-20 to 2027-03-30. The
slip of ENB-01 means it now finishes mid PI n+1 and FEAT-03 starts
straight after it in the same PI, which breaks the one-PI-ahead rule.
The risk is recorded as RR-01. Record every such tight pair in section
12.

## 10. Governance and decision rights

<!-- Guidance: Say who decides what, how often the runway is reviewed and how intentional decisions are recorded. Keep governance light: a short review before PI planning and at the system demo is usually enough if guardrails are automated. -->

### 10.1 RACI

| Activity | System architect | Product management | Release train engineer | Teams | Enterprise architecture |
|---|---|---|---|---|---|
| Maintain architectural intent and guardrails | A, R | C | I | C | C |
| Identify runway gaps from the feature forecast | R | A | I | C | I |
| Define and size enablers | A | C | I | R | C |
| Agree capacity allocation | R | A | R | C | I |
| Decide intentional architecture choices | A, R | C | I | C | C |
| Decide emergent design choices | C | I | I | A, R | I |
| Track runway health metrics | A | I | R | C | I |

R: responsible, A: accountable, C: consulted, I: informed.

### 10.2 Cadence

| Event | When | Runway topics |
|---|---|---|
| Pre-PI planning runway review | [n] weeks before PI planning | Gap list, enabler sizing, allocation proposal |
| PI planning | Start of each PI | Enablers committed with features; dependencies confirmed |
| System demo | End of each iteration | Enablers demonstrated with their acceptance criteria |
| Inspect and adapt | End of each PI | Runway health metrics, allocation history, lessons |
| Architecture board (if needed) | [Cadence] | Intentional decisions with enterprise impact, guardrail exceptions |

### 10.3 Records

- Record each intentional decision as an ADR in the decision log
  (`architecture/architecture-decision-log`) and link it from section
  2.2.
- Record guardrail exceptions with an expiry date; an exception without
  an expiry becomes technical debt and belongs in the debt register.
- Link each enabler to the fitness functions it adds, so the runway is
  protected from erosion after delivery.

## 11. Runway health metrics

<!-- Guidance: Measure whether the runway keeps pace with demand. Choose a few metrics, define each precisely and track the trend per PI. Targets are local decisions; the values below are examples, not norms. -->

| ID | Metric | Definition | Target | Current | Trend |
|---|---|---|---|---|---|
| RHM-01 | Runway coverage | Features in the next two PIs whose required runway is Ready, divided by all features in the next two PIs | *Example:* at least 70 percent | *Example:* 1 of 4 features (FEAT-04) = 25 percent | Rising as ENB-01 completes |
| RHM-02 | Runway lead | Number of PIs between an enabler's completion and the start of its first dependent feature | *Example:* at least 1 | *Example:* 0 for ENB-01 to FEAT-03 | Watch |
| RHM-03 | Enabler predictability | Enablers completed divided by enablers committed in the PI | *Example:* at least 80 percent | *Example:* 3 of 4 = 75 percent (PI n-1) | Improving |
| RHM-04 | Feature rework from missing runway | Feature stories added during the PI to build infrastructure the runway should have provided | *Example:* fewer than 5 per PI | [n] | [Trend] |
| RHM-05 | Guardrail conformance | Fitness function pass rate for GR-01 to GR-04 on the main branch | *Example:* 100 percent | [Value] | [Trend] |
| RHM-06 | Enabler share | Enabler capacity as a share of total capacity, per PI | Set by section 8 | 20 percent | Rising |
| [RHM-nn] | [Metric] | [Definition] | [Target] | [Value] | [Trend] |

*Example:* The next two PIs are PI n+1 and PI n+2. They contain four
features: FEAT-01, FEAT-02, FEAT-03 and FEAT-04 (FEAT-05 and FEAT-06
are in PI n+3 and are not counted). Only FEAT-04 has Ready runway
(RWY-01), so coverage is 1 of 4, or 25 percent. When ENB-01 completes,
FEAT-03 becomes covered and coverage rises to 50 percent. State which
features you count so the metric can be recomputed.

## 12. Risks and assumptions

<!-- Guidance: Record what could make the runway arrive late, arrive wrong or go unused. Include the risk of building runway for features that are later cancelled. -->

| ID | Risk or assumption | Type | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|---|
| RR-01 | *Example:* ENB-01 slips again and squeezes ENB-03 out of PI n+1 | Risk | Medium | FEAT-02 moves one PI | Split ENB-01; ship port and one adapter first | [@system-architect] |
| RR-02 | *Example:* Market C launch cancelled after residency work starts | Risk | Low | Wasted enabler capacity | Do not start region C work before SPK-03 result and go decision | [@product-management] |
| RR-03 | *Example:* SPK-02 picks a backbone the platform team cannot operate | Risk | Medium | Operational incidents after launch | Include operability criteria in the spike; SRE sign-off | [@platform-lead] |
| RR-04 | *Example:* Feature forecast for PI n+2 is stable | Assumption | n/a | Gap list valid | Recheck at pre-PI review | [@product-management] |
| [RR-nn] | [Statement] | [Risk / Assumption] | [H / M / L] | [Impact] | [Response] | [@owner] |

## 13. Glossary and references

<!-- Guidance: Define the terms as used in this plan and list the sources consulted with the date you checked them. Framework terms keep their framework names; the definitions here are this collection's own wording. -->

### 13.1 Glossary

| Term | Meaning in this plan |
|---|---|
| Architectural runway | Existing code, components and infrastructure that let near-term features be built without major redesign or delay |
| Enabler | Backlog item that extends the runway or supports future work: exploration, architecture, infrastructure or compliance |
| Intentional architecture | Decisions taken deliberately and early because they are cross-cutting or costly to reverse |
| Emergent design | Design that teams discover and refine while building, within guardrails |
| Guardrail | Checkable rule that keeps emergent design consistent with intent |
| Spike | Time-boxed exploration that answers a question needed to plan or design |
| Planning interval (PI) | Fixed time box in which a release train plans, builds and demonstrates a set of increments |
| Capacity allocation | Agreed split of a train's capacity between features, enablers and maintenance |
| Runway coverage | Share of upcoming features whose required runway is ready |

### 13.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Scaled Agile, Inc. *SAFe Framework*, Architectural Runway and Enablers articles, framework.scaledagile.com | SAFe 6.0 (Core SAFe); AI-Native SAFe introduced June 2026 (What's new page); checked YYYY-MM-DD | Concept names: architectural runway, enablers and their types, capacity allocation, PI |
| The Open Group. *Open Agile Architecture Standard*, Version 2.0 | April 2026 (catalogue listing) | Names only: intentional and emergent architecture |
| Ford, N., Parsons, R., Kua, P., Sadalage, P. *Building Evolutionary Architectures*, 2nd edition, O'Reilly, 2022 | Background reading (inspiration only) | Fitness functions as guardrails |
| Fitness functions catalogue (`architecture/fitness-functions`) | This collection | Guardrail checks |
| Architecture roadmap and transition architectures (`architecture/architecture-roadmap-transition`) | This collection | Longer-range target state |
| [Train or portfolio backlog] | [Date] | Feature forecast |

## Standard and licence note

Structure aligned with the Architectural Runway and Enabler concepts
of the Scaled Agile Framework (SAFe 6.0, as listed at
framework.scaledagile.com) and with the intentional versus emergent
architecture distinction named in agile architecture practice,
including the Open Agile Architecture Standard, Version 2.0, of The
Open Group. This template uses only the names of these concepts; all
text, tables, metrics and the worked example are original and do not
reproduce SAFe or Open Group content. SAFe and Scaled Agile Framework
are registered trademarks of Scaled Agile, Inc.; Open Agile
Architecture is a trademark of The Open Group. This template is not
affiliated with or endorsed by either owner. Check the current SAFe
version (SAFe 6.0 is presented as Core SAFe; AI-Native SAFe,
introduced in June 2026, builds on it) and the
current Open Group publication before use. Template licence: MIT.