# End-to-end BA delivery work products

**Version:** 1.1  
**Published:** 2026-08-22  
**Companion case:** Northstar Equipment Services v1.1

Companion structures for Cookbook recipes 40–45. Copy only the sections the decision needs into your preferred document, whiteboard, spreadsheet, or repository.

## What this pack is for

This pack helps a business architect keep six questions connected:

1. Which parts of the organization contribute to value and capability outcomes?
2. What specifically limits a capability from producing the required outcome?
3. How must the operating model change?
4. Is the organization ready to operate the change?
5. How will value be observed and governed after release?
6. How does a policy or regulatory obligation alter the architecture and required evidence?

Use the blank structures selectively. The completed Northstar entries are compact examples, not universal answers or complete operating designs. The structures are not a phase-gate method and do not transfer accountability from organization design, delivery, change management, operations, risk, legal, compliance, or benefit owners.

## Shared engagement header

Use this header once when several structures support the same decision.

| Field | Working entry |
|---|---|
| Engagement / change | |
| Decision to be made | |
| Decision owner | |
| Decision forum and date | |
| Outcome to improve | |
| Scope included | |
| Scope excluded | |
| Evidence cutoff date | |
| Architecture baseline and version | |
| Assumptions requiring validation | |
| Contributors and authorities | |
| Stop condition | |
| Review / reopen trigger | |

### Completed Northstar shared header

| Field | Northstar entry |
|---|---|
| Engagement / change | I-01 Connected Service Promise, R1 |
| Decision to be made | Whether the defined three-branch operating change is ready, produces decision-grade evidence, and should later be adapted, scaled, or stopped |
| Decision owner | Investment Council for funding and scale; readiness authority delegated to the R1 readiness forum |
| Outcome to improve | O-01 promise reliability with usable branch discretion; O-02 service-margin protection; O-03 reduced avoidable customer disruption and repeat work |
| Scope included | POL-01, ST-02, C-110/C-130/C-140/C-170/C-180, BO-02/BO-05/BO-06, three purposively selected branches, M-01–M-08 |
| Scope excluded | ERP replacement, enterprise rollout, vendor selection, legal or regulatory interpretation, detailed solution design |
| Evidence cutoff | Episode A: E-001–E-007; Episode B: through E-008; Episode C: E-009 at day 30 and E-010 at day 90 |
| Stop condition | Stop when the accountable forum can decide readiness or continue/adapt/scale/stop with explicit evidence, conditions, authority, and reopen triggers |

---

# 40 · Organization-to-value contribution map

## Purpose

Show how organizational units contribute to capabilities, value-stream stages, information stewardship, and outcomes without treating the organization chart as the architecture.

## A. Organization register

| Org ID | Organizational unit | Mandate / contribution | Accountable executive | Scope / geography | Material capabilities | Value-stream stages | Business objects stewarded | Evidence | Confidence |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

## B. Contribution relationship

Use one row for each decision-relevant relationship. Avoid forcing a single owner where contribution is genuinely distributed.

| Relationship ID | Organization | Capability or value stage | Contribution type | Decision / accountability right | Inputs provided | Outputs or value enabled | Dependency | Friction / ambiguity | Evidence |
|---|---|---|---|---|---|---|---|---|---|
| | | | Accountable / operates / contributes / governs / assures / stewards | | | | | | |

## C. Organization questions

| Question | Finding | Consequence for the decision | Owner / next action |
|---|---|---|---|
| Is accountability absent, duplicated, or disconnected from operating authority? | | | |
| Are critical contributions split across units without a coordinating mechanism? | | | |
| Does one unit steward information another unit must use or change? | | | |
| Does the formal structure differ from how value is actually delivered? | | | |
| Would an organizational change alter capability or value outcomes? | | | |

## Completion check

- [ ] The organizational scope is bounded by the decision, not by the full chart.
- [ ] Capabilities remain stable business abilities rather than department names.
- [ ] Contribution, accountability, stewardship, and governance are distinguished.
- [ ] Material cross-unit dependencies and information relationships are visible.
- [ ] Ambiguities have an owner, forum, and required disposition.

## Completed Northstar example

| Relationship | Organization | Capability / stage | Contribution and formal right | Friction / consequence | Evidence |
|---|---|---|---|---|---|
| OR-01 | ORG-02 Branch manager | C-110 / ST-02 | Operates the practice; owns branch adoption and local capacity decisions | Local exception authority was implicit | E-003, E-008 |
| OR-02 | ORG-05 Regional VP Operations | C-130 / ST-02 | Coordinates cross-branch capacity and approves delegated regional exceptions | Peak-period escalation capacity is limited | E-007, E-008 |
| OR-03 | ORG-08 VP Supply Operations | C-140 / BO-05 | Accountable for part-availability performance and confirmed BO-05 owner | Provisional R1 source can lag physical stock and is not authoritative enterprise-wide | E-003, E-008 |
| OR-04 | ORG-09 EVP Service Operations | C-110 / C-170 | Accountable for capability performance and POL-01 | Requires Finance and Customer authorities for guardrails | E-008 |
| OR-05 | ORG-10 Chief Data Officer | C-180 / BO-02 and BO-05 | Governs object ownership and stewardship | Stewardship was confused with performance accountability | E-008 |
| OR-06 | ORG-15 R1 Readiness Forum | C-170 / R1 | Integrates readiness and early-life evidence; may authorize one contained remediation interval only where the governed guardrail explicitly delegates it and the named owner validates the breach | Cannot expand to R2, renew or waive a guardrail exception, exceed the investment band, or reopen procurement | E-008–E-009 |

**Decision consequence:** retain the current organization for R1, but make object, exception, capability, and measure rights explicit. A new reporting line would add disruption without addressing the demonstrated coordination problem.

---

# 41 · Capability improvement assessment

## Purpose

Diagnose why a selected capability cannot produce the required outcome. This is a decision-oriented constraint assessment, not a generic maturity survey.

## A. Capability and outcome frame

| Field | Working entry |
|---|---|
| Capability | |
| Required outcome / performance | |
| Current observed condition | |
| Gap and urgency | |
| Stakeholders affected | |
| Value-stream stages affected | |
| Evidence period | |
| Decision this assessment supports | |

## B. Limiting-condition assessment

Rate only where evidence is sufficient. Suggested disposition: `not limiting`, `contributing`, `material constraint`, `unknown`.

| Dimension | Required condition | Observed condition | Evidence | Disposition | Confidence | Causal hypothesis | Owner |
|---|---|---|---|---|---|---|---|
| People / skills | | | | | | | |
| Process / ways of working | | | | | | | |
| Information | | | | | | | |
| Technology | | | | | | | |
| Policy / rules | | | | | | | |
| Governance / decision rights | | | | | | | |
| Organization / accountability | | | | | | | |
| Capacity / demand | | | | | | | |
| Measures / incentives | | | | | | | |
| External dependencies | | | | | | | |

## C. Improvement options

| Option | Constraints addressed | Expected mechanism | Dependencies | Risks / side effects | Evidence gained | Reversibility | Recommendation |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## D. Assessment conclusion

| Field | Working entry |
|---|---|
| Primary limiting condition(s) | |
| Important contributing conditions | |
| Conditions ruled out and evidence | |
| Unknowns that could change the conclusion | |
| Recommended intervention boundary | |
| Decision required | |
| Reassessment trigger and date | |

## Completion check

- [ ] The assessment starts from an outcome gap, not a desire to assign a maturity score.
- [ ] Observations, judgments, and causal hypotheses are visibly separate.
- [ ] Confidence and disagreement remain visible.
- [ ] The recommendation addresses the material constraint rather than defaulting to technology.
- [ ] Further assessment stops when another dimension would not change the decision.

## Completed Northstar example

**Capability:** C-110 Service Promise Management  
**Outcome:** meet R1 feasibility thresholds for O-01 without breaching O-02 or O-03 guardrails.

| Dimension | Observed condition | Evidence | Disposition | Response |
|---|---|---|---|---|
| Policy | Regions use incompatible promise and cancellation rules | E-001, E-003 | Material constraint | CP-01 / POL-01 |
| Information | BO-05 and skill signals are not consistently usable | E-003 directly; E-006 is a corroborating outcome signal, not proof of the information condition | Material constraint; R1 source condition accepted, enterprise/future-state authority unresolved | CP-02 and OI-06 |
| Governance | Exception authority is implicit | E-003 | Material constraint | CP-03 and delegated rights in POL-01 |
| Capacity | Rural travel and specialist coverage constrain dates | E-007 | Contributing; not yet proven by performance evidence | Purposeful sample and governed exception route |
| Technology | Whether existing tools impose material manual-confirmation burden | E-004 demonstrates automatable functionality only; burden is not established in Episode A | Unknown / hypothesis | Measure manual effort and failure modes in R1; defer procurement |
| Skills / adoption | New practice has not been used | None at Episode A | Unknown | Training, observation, and M-07 |

**Conclusion:** policy, information, and decision rights are the primary supported constraints. Technology remains a hypothesis to test. Further decomposition is unnecessary for the Episode A funding decision.

---

# 42 · Operating-model change record

## Purpose

Define how an initiative changes the way the enterprise operates across capabilities, value, organization, information, policy, governance, process, measures, and enabling technology.

## A. Current-to-target operating delta

| Element | Current condition | Target condition | Why it must change | Change owner | Dependency | Evidence / source |
|---|---|---|---|---|---|---|
| Stakeholder / value proposition | | | | | | |
| Value-stream stage | | | | | | |
| Capability | | | | | | |
| Organization / role | | | | | | |
| Decision right / governance | | | | | | |
| Process / operating practice | | | | | | |
| Business information | | | | | | |
| Product / service | | | | | | |
| Policy / control | | | | | | |
| Measure / incentive | | | | | | |
| Technology enablement | | | | | | |

## B. Transition condition

| Transition ID | Required condition | Predecessor | Accountable owner | Evidence of completion | Needed by | Risk if absent | Status |
|---|---|---|---|---|---|---|---|
| | | | | | | | Not started / in progress / ready / accepted |

## C. Operating decision log

| Decision | Options considered | Architecture consequence | Decision owner / forum | Disposition | Conditions | Review trigger | Record reference |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## D. Handoff boundary

| Discipline / owner | Architecture contribution | Detail owned outside this record | Handoff evidence | Acceptance |
|---|---|---|---|---|
| Organization design | | | | |
| Process / operations | | | | |
| Product / service management | | | | |
| Change and adoption | | | | |
| Technology / solution architecture | | | | |
| Risk / legal / compliance | | | | |
| Delivery management | | | | |

## Completion check

- [ ] Every target change connects to an outcome, obligation, or diagnosed constraint.
- [ ] Organization, governance, information, policy, and measures are not hidden inside a technology workstream.
- [ ] Transition conditions have owners and observable completion evidence.
- [ ] Specialist disciplines retain ownership of their detailed designs and plans.
- [ ] The operating delta is sufficient to test release scope and readiness.

## Completed Northstar example

| Element | Current condition | R1 target condition | Change owner | Completion evidence |
|---|---|---|---|---|
| Policy | Local promise rules and informal overrides | POL-01 defines normal confirmation, change, cancellation, recovery, and exception paths | ORG-09 | Approved policy and scenario test |
| Decision right | Dispatcher and manager authority varies | ORG-03 applies; ORG-02 approves branch exceptions; ORG-05 resolves cross-branch exceptions | ORG-05 | Accepted decision-right record |
| Information | Part and skill statuses are interpreted locally | BO-02 is accepted for R1 under versioning/audit rules; ORG-08 owns BO-05; its inventory reservation source is provisional for R1, reconciled twice daily, and not authoritative enterprise-wide | ORG-08 / ORG-10 | Object decisions and source-quality tests |
| Operating practice | Promise may precede prerequisite confirmation | Normal promise requires confirmation or a transparent approved exception | ORG-02 | Observed scenario and adoption audit |
| Measures | Definitions and denominators vary | M-01 and M-04–M-08 are approved and reproducible | ORG-09 / ORG-12 | Parallel-run reconciliation |
| Technology | Current tools plus calls and local spreadsheets | Current tools retained; controlled manual log bridges unresolved automation | ORG-11 | Access, support, and rollback acceptance |

**Handoff boundary:** the BA preserves the architecture delta and trace. Operations owns procedures, Organization Design owns role detail, Change owns training/adoption execution, Technology owns configuration/support, Finance owns M-03, and Delivery Management owns plans and capacity commitments.

---

# 44 · Operational-readiness assessment

## Purpose

Decide whether the receiving organization can safely and sustainably operate a release, and make unresolved conditions explicit before go-live or handoff.

## A. Readiness criteria

Suggested status: `ready`, `ready with condition`, `not ready`, `not applicable`, `unknown`.

| Readiness area | Required condition | Evidence / acceptance test | Accountable owner | Status | Residual risk | Condition / action | Due date |
|---|---|---|---|---|---|---|---|
| Operating ownership | | | | | | | |
| Roles and capacity | | | | | | | |
| Skills and training | | | | | | | |
| Process and procedures | | | | | | | |
| Information quality / access | | | | | | | |
| Policy and controls | | | | | | | |
| Product / service support | | | | | | | |
| Technology and service support | | | | | | | |
| Measures and monitoring | | | | | | | |
| Suppliers / external dependencies | | | | | | | |
| Business continuity / rollback | | | | | | | |
| Communications and adoption | | | | | | | |

## B. Readiness disposition

| Field | Working entry |
|---|---|
| Release / operating change | |
| Readiness decision requested | |
| Decision owner and forum | |
| Overall disposition | Ready / ready with conditions / not ready |
| Conditions that must precede release | |
| Accepted residual risks and authority | |
| Deferred items and owner | |
| Early-life support period | |
| Escalation threshold | |
| Recheck / rollback trigger | |

## C. First operating cycle evidence

| Signal | Expected range / behavior | Actual observation | Evidence owner | Review point | Response if outside range |
|---|---|---|---|---|---|
| | | | | | |

## Completion check

- [ ] Readiness criteria describe operating conditions, not task completion alone.
- [ ] Each criterion has observable evidence and an accountable owner.
- [ ] `Unknown` has not been silently treated as `ready`.
- [ ] Conditional readiness includes explicit conditions, due dates, and accepted risk authority.
- [ ] Early operating signals, escalation, and rollback triggers are agreed.

## Completed Northstar example

| Area | Required condition | Evidence | Status | Condition / authority |
|---|---|---|---|---|
| Ownership | Branch, regional, capability, object, and measure rights accepted | Signed decision-right record | Ready | None |
| Policy | POL-01 approved and usable in scenarios | Policy and tabletop observation | Ready | None |
| Information | BO-02 and BO-05 R1 source statuses are explicit | BO-02 passes version/linkage audit; ORG-08 owns BO-05; its provisional inventory reservation source has delayed updates in one branch | Ready with condition | BO-05 twice-daily reconciliation; neither source is declared the enterprise future state; ORG-08 / ORG-10 accept |
| Evidence design | Branch selection and minimum volume accepted | Three purposeful branches; at least 100 eligible promises per branch and 450 aggregate over 90 days | Ready | Lower volume remains a confidence limitation; ORG-05 / ORG-14 |
| Capacity | POL-01 exceptions can be resolved within one operating shift | Peak simulation finds a rural bottleneck | Ready with condition | Regional backup approver; ORG-05 accepts |
| Measures | Definitions and baselines are reproducible | Parallel-run reconciliation | Ready | None |
| Training | Every participating shift passes scenarios | 91%; one shift incomplete | Not ready | Complete before that branch activates; ORG-02 |
| Rollback | Prior practice can resume without losing promise lineage | Tested rollback | Ready | None |

**Disposition — ORG-15 R1 Readiness Forum:** authorize a staggered R1 start only after the incomplete shift passes. Accept the BO-05 reconciliation and backup approver through the day-30 review; ORG-15 must then close, adapt, or explicitly renew each condition against E-009. Pause an affected branch or work type for severe customer harm or an uncontained guardrail breach.

---

# 43 · Value-realization trace

## Purpose

Keep the causal logic, measures, owners, assumptions, and review triggers visible after delivery so the enterprise can distinguish output completion from realized value.

## A. Outcome trace

| Trace ID | Stakeholder outcome | Value-stream change | Capability / operating change | Delivered release or intervention | Leading signal | Outcome measure | Benefit owner |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## B. Measure definition

| Measure | Definition | Baseline / period | Target / horizon | Source | Frequency | Accountable owner | Data confidence | Guardrail / countermeasure |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## C. Assumption and attribution log

| Assumption / causal claim | Evidence expected | Confounding factor | Test / observation window | Result | Consequence for the value claim | Owner |
|---|---|---|---|---|---|---|
| | | | | | | |

## D. Realization review

| Review date | Adoption / use observed | Leading signals | Outcome movement | Unintended effects | Disposition | Follow-up owner | Next trigger |
|---|---|---|---|---|---|---|---|
| | | | | | Continue / adapt / scale / investigate / stop | | |

## Completion check

- [ ] Measures distinguish delivery, adoption, capability condition, stakeholder outcome, and financial benefit.
- [ ] Baselines, definitions, sources, horizons, and owners are explicit.
- [ ] The trace states a testable contribution hypothesis rather than claiming automatic causation.
- [ ] Guardrails make value tradeoffs and unintended effects visible.
- [ ] The accountable forum knows when to continue, adapt, scale, investigate, or stop.

## Completed Northstar example

| Trace | Testable contribution hypothesis | Measure | Day 30 | Day 90 | Disposition |
|---|---|---|---:|---:|---|
| VR-01 | Confirmation or exception practice improves reliability | M-04 / M-01 | 84% / 89% | 92% / 93% | Feasibility thresholds reached at day 90 |
| VR-02 | Better preparation reduces avoidable rework | M-02 | 12% | 11% | Improve but do not claim target attainment |
| VR-03 | Reliability can improve without margin transfer | M-03 | 30.8% | 31.2% | Day-30 guardrail breach recovered; continue Finance review |
| VR-04 | Customer disruption does not increase | M-05 | 6.5 per 100 vs 6.2 pre-release | 5.6 per 100 | Within tolerance at day 30 and directionally improved by day 90 |
| VR-05 | The operating practice and exception route are used | M-07 | 78% | 96% | Adoption threshold reached after coaching |
| VR-06 | Formal exceptions preserve branch discretion | POL-01 one-shift criterion | 76% | 88% | Adapt; rural constraint remains |
| VR-07 | Reliability is not purchased through hidden field burden | M-06 | -4.1% | -2.0% | ORG-07 and ORG-12 validate the day-30 breach; it recovers within the guardrail |
| VR-08 | R1 remains within authorized cost and capacity | M-08 | $118,000 spent; $340,000 forecast; 5.8 FTE equivalent | $287,000; peak 5.8 FTE equivalent | ORG-12 and Delivery Management validate the forecast breach and scope correction; the final result stays within the band |

**Attribution and evidence volume:** the timing and adoption pattern support a contribution claim, not proof of causation. E-010 includes 486 eligible promises—176 metropolitan, 166 mixed-fleet, and 144 rural—so the approved minimum of 100 per branch and 450 aggregate is met. Seasonal demand, work mix, and purposeful branch selection remain confounders. The metropolitan branch reaches 95% M-01, the mixed branch 94%, and the rural branch 89%; the 93% aggregate does not prove repeatability.

**Review result:** after ORG-12 validates the M-03 result, use ORG-15's delegated one-interval remediation authority for that margin breach and continue R1 to day 90 without expansion. With ORG-07 and ORG-12 validating the M-06 breach, retain the no-scale response while productivity remains unresolved. With ORG-12 and Delivery Management validating the M-08 forecast, narrow one low-volume work type before the authorized band is exceeded. Neither response waives a guardrail or expands ORG-15's authority. At day 90, conclude R1 feasibility, permit R2 design/readiness work, and keep scale activation and platform procurement gated; ORG-13 owns any renewal of a guardrail exception.

---

# 45 · Policy and regulatory impact assessment

## Purpose

Translate an authoritative obligation or policy change into traceable business-architecture impacts, decisions, controls, evidence, and operational-readiness conditions.

## A. Obligation register

| Obligation ID | Authoritative source | Effective date | Jurisdiction / scope | Interpretation owner | Requirement / obligation | Ambiguity | Penalty / consequence | Evidence reference |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## B. Architecture impact trace

| Obligation ID | Stakeholder / outcome | Value-stream stage | Capability | Organization / role | Business information | Product / service | Process / practice | Technology | Existing control |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

## C. Gap and response decision

| Gap | Current evidence | Required condition | Response options | Recommended response | Accountable decision owner | Dependency | Due date | Residual risk |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## D. Control and evidence chain

| Obligation | Policy / rule | Control objective | Control owner | Operating procedure | Evidence produced | Evidence steward / retention | Test / monitoring | Exception route |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## E. Interpretation decision record

| Question | Interpretations considered | Legal / compliance advice | Architecture consequence | Decision owner | Disposition | Assumptions | Review trigger |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## Completion check

- [ ] The authoritative source, scope, effective date, and interpretation authority are recorded.
- [ ] Interpretation is visibly separate from architecture impact and delivery response.
- [ ] Every material obligation traces to owners, operating changes, controls, and retained evidence.
- [ ] Legal and compliance authorities retain responsibility for interpretation and acceptance.
- [ ] Readiness and post-implementation monitoring include compliance evidence and exception handling.

## Completed Northstar example: internal policy only

Northstar does not assert a fictional legal or regulatory obligation. The structure is used for **POL-01 Service Promise Policy**, an internal operating policy approved in Episode B.

| Obligation | Architecture impact | Control and retained evidence | Authority / exception route |
|---|---|---|---|
| Normal promise requires valid BO-02 data and required part, skill, geography, and capacity confirmation | ST-02; C-110/C-130/C-140; BO-02/BO-05/BO-06 | Confirmation timestamp, status source, and policy version | ORG-09; exception via ORG-02 or delegated ORG-05 |
| Unavailable confirmation requires a transparent exception with reason, approver, expiry, and customer communication | C-110/C-170; M-07; ORG-02/ORG-05; one-shift response criterion | Exception record and weekly review | ORG-09 owns policy; ORG-05 owns regional route |
| A changed promise preserves the prior promise and triggers notification | ST-02/ST-05; BO-02; C-160 | Linked version and notification record | ORG-06 |
| A broken promise opens recovery before outcome closure | ST-05; BO-02; C-160 | Recovery owner, action, and closure evidence | ORG-06 |

**Boundary:** Operations owns interpretation and acceptance of this internal policy. If a real legal or regulatory obligation applied, qualified Legal or Compliance authority would own interpretation; the BA would trace the resulting architecture impacts rather than invent the rule.

---

# Connected decision and open-item index

Use this small index when the six structures are maintained separately.

| ID | Type | Question / item | Source section | Owner | Forum / due date | Status | Disposition / link | Reopen trigger |
|---|---|---|---|---|---|---|---|---|
| | Decision / assumption / risk / dependency / evidence gap | | | | | | | |

## Completed Northstar index excerpt

| ID | Type | Question / item | Source | Owner | Status | Disposition / reopen trigger |
|---|---|---|---|---|---|---|
| DEC-001 | Decision | Authorize R1? | Episode A | Investment Council | Conditional | Authorize within band; reopen on readiness failure or guardrail breach |
| DEC-002 | Decision | Procure enterprise platform? | Episode A | Investment Council | Deferred | Reopen only with R2-quality repeatability evidence, material residual automation gaps, and a separate business case comparing vendor and non-vendor responses |
| OI-02 | Evidence / ownership gap | Who owns BO-05, and what source status is acceptable for R1? | Episode A/B | ORG-08 / ORG-10 | Closed for R1 | E-008 confirms ORG-08 as owner and accepts the inventory reservation record as the provisional R1 source with twice-daily reconciliation |
| OI-06 | Information-authority gap | What source should be authoritative for BO-05 beyond R1? | Episode B/C | ORG-08 / ORG-10 | Open | Decide before any R2 activation or enterprise source standard; reopen analysis on quality failure or a changed source landscape |
| DEC-005 | Decision | What follows R1? | Episode C | Investment Council | Conditional | Permit R2 design/readiness, not activation; reopen when named conditions are satisfied |

## Pack-level stopping rule

Stop adding detail when the accountable forum can:

- see the organization and capability contributions that matter;
- understand the material limiting conditions;
- compare the necessary operating changes;
- decide readiness with explicit conditions and residual risks;
- observe value with owned measures and testable assumptions; and
- trace applicable policy or regulatory obligations into controls and evidence.

Reopen only when a named trigger, new evidence, changed obligation, operating failure, or value result could alter one of those decisions.