# Architecture Change Request: [ACR-YYYY-NN] [Change title]

> An Architecture Change Request proposes a change to an approved
> architecture: its target, a Transition Architecture, a requirement, a
> principle or standard, or an Architecture Contract. It belongs to Phase H
> (Architecture Change Management) of the Architecture Development Method
> (ADM) in The TOGAF Standard, 10th Edition (2025 release with Technical Corrigendum 1), where the
> Architecture Board assesses each change and decides whether it is a
> simplification change, an incremental change or a re-architecting
> change that needs a new ADM cycle. This template records the driver,
> the affected architecture, the classification, the impact, the options,
> the recommendation, the decision and the follow-through. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Raise one request per change. Bundle only changes that cannot be decided
  separately.
- The requester fills sections 1 to 4. The assessing architect fills
  sections 5 to 8. The board secretary records section 9. The owner of the
  change completes sections 10 to 12 after the decision.
- Classify early (section 5), because the class decides the route: a
  simplification can be approved by the lead architect, an incremental
  change goes to the board, and re-architecting needs a new Request for
  Architecture Work (`architecture/request-for-architecture-work`).
- A request is not a dispensation. If a project simply cannot meet an
  architecture requirement for a while, ask for a dispensation under the
  Architecture Board Charter (`architecture/architecture-governance-charter`).
  Use a change request when the architecture itself should change.
- The worked example continues the fictional insurer of the TOGAF template
  set: the policy system A vendor delays its APIs, which threatens
  Transition Architecture TA-1 and work package WP-02.
-->

## Document control

<!-- Guidance: Give every request a unique ID and keep its status current, because the board's agenda and the change register are built from it. Record the architecture baseline the change applies to. Pitfall: requests that stay "under assessment" for months; set a decision date. -->

| Field | Value |
|---|---|
| Document ID | [ACR-YYYY-NN] |
| Change title | [Short title] |
| Version | [0.1] |
| Status | [Raised / Under assessment / Awaiting decision / Approved / Approved with conditions / Rejected / Deferred / Implemented / Closed] |
| Requester | [@requester, team] |
| Assessing architect | [@architect] |
| Owner of the change (after approval) | [@owner] |
| Approvers / reviewers | [Architecture Board, sponsor, affected contract owners] |
| Architecture affected | [Engagement name; ADD-ENG-001 version; ARS-ENG-001 baseline; roadmap version] |
| Date raised | YYYY-MM-DD |
| Decision required by | YYYY-MM-DD |
| Urgency | [Routine / Expedited / Emergency] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Conditions | Date |
|---|---|---|---|---|
| Assessing architect | [@architect] | [Recommendation] | [Conditions] | YYYY-MM-DD |
| Lead architect of the engagement | [@lead-architect] | [Supports / Does not support] | [Conditions] | YYYY-MM-DD |
| Sponsor | [@sponsor] | [Agrees / Does not agree] | [Conditions] | YYYY-MM-DD |
| Architecture Board chair | [@chair] | [Approved / Approved with conditions / Rejected / Deferred] | [Board outcome record] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@requester] | Driver, description and affected architecture raised |
| 0.3 | YYYY-MM-DD | [@architect] | *Example:* Classification, impact and three options assessed |
| 1.0 | YYYY-MM-DD | [@chair] | *Example:* Approved with conditions (outcome record ARB-2027-011) |
| 1.1 | YYYY-MM-DD | [@owner] | *Example:* Implementation recorded; closed after post-change review |

## Contents

1. [Change summary](#1-change-summary)
2. [Change driver and source](#2-change-driver-and-source)
3. [Description of the proposed change](#3-description-of-the-proposed-change)
4. [Affected architecture](#4-affected-architecture)
5. [Change classification](#5-change-classification)
6. [Impact assessment](#6-impact-assessment)
7. [Options considered](#7-options-considered)
8. [Recommendation](#8-recommendation)
9. [Decision](#9-decision)
10. [Implementing the change](#10-implementing-the-change)
11. [Communication](#11-communication)
12. [Monitoring and closure](#12-monitoring-and-closure)
13. [Glossary and references](#13-glossary-and-references)

## 1. Change summary

<!-- Guidance: In a few lines, say what should change, why, what it costs and what the board is asked to decide. Write it after section 8. Pitfall: a summary that describes the problem but never states the proposed change. -->

| Field | Value |
|---|---|
| Proposed change | *Example:* Feed customer changes from policy system A to the customer data hub through interim change data capture until the vendor's APIs arrive, instead of waiting for the APIs |
| Driver | *Example:* Policy system A vendor has moved its API release by nine months (risk RSK-01 has materialised) |
| Class | *Example:* Incremental change |
| Architecture affected | *Example:* Transition Architecture TA-1, work package WP-02, requirements ARS-INT-01 and ARS-INT-04 (new), contract AC-02 |
| Cost | *Example:* USD 175,000 over the interim period, drawn from the roadmap contingency; committed roadmap total unchanged at USD 2,415,000 |
| Effect on dates | *Example:* TA-1 exit moves by six weeks instead of nine months |
| Decision asked | *Example:* Approve option B and the amendment of contract AC-02 |

## 2. Change driver and source

<!-- Guidance: Name the force behind the change and give evidence. Drivers come from outside the architecture (new strategy, regulation, market, technology, supplier events) or from inside it (lessons learned, compliance findings, expiring dispensations, monitoring results). Pitfall: a request driven by a team's preference, presented as a business need. -->

### 2.1 Driver type

| Driver type | Typical examples | This request |
|---|---|---|
| Business strategy or operating model | New product, merger, divestment, new channel | [ ] |
| Regulation or legal | New law, supervisory finding, court decision | [ ] |
| Supplier or technology event | Release delay, end of support, price change, new capability | *Example:* [x] |
| Lessons learned from delivery | A design that does not work as assumed | [ ] |
| Compliance review finding | A contract cannot be met as written | [ ] |
| Dispensation expiry | An exception ends and the underlying issue remains | [ ] |
| Standards or principles update | A standard retired, a new principle adopted | [ ] |
| Performance and value monitoring | Success measures off track at a plateau | [ ] |

### 2.2 Evidence

| Item | Detail |
|---|---|
| Source | *Example:* Vendor roadmap letter dated YYYY-MM-DD; confirmed in the supplier review meeting |
| What changed | *Example:* The customer API for policy system A moves from release R7 to R9, about nine months later |
| Link to known risk | *Example:* Vision risk RSK-01 (vendor cannot deliver APIs before contract renewal) |
| Who raised it | [@requester], WP-02 delivery lead |
| Consequence if no change | *Example:* WP-02 cannot master policy system A customers; TA-1 exit slips nine months; TA-2 and the KPI-01 benefits follow |

## 3. Description of the proposed change

<!-- Guidance: Describe the current approved position and the proposed position side by side, then explain why now. Keep design detail out; link to an ADR or design note. Pitfall: describing only the new solution, so reviewers cannot see what is being given up. -->

### 3.1 Current and proposed position

| Aspect | Current (approved) | Proposed |
|---|---|---|
| *Example:* How policy system A customer data reaches the hub | Vendor customer API, planned for release R7 | Interim change data capture from the policy system A database, published as customer events in the target format; switch to the vendor API when R9 is live |
| *Example:* TA-1 definition | Hub is master for customers from systems A and B through APIs | Hub is master for customers from systems A and B; system A fed by the interim path |
| *Example:* Integration principle AP-01 | Met through published APIs | Met for consumers; the interim feed is a provider-side exception with an end date |
| [Aspect] | [Current] | [Proposed] |

### 3.2 Why now

*Example:* The data hub contract (AC-02) has a TA-1 checkpoint in about
three months (2027-08-30). Deciding now lets the team build the interim feed in parallel
with the hub configuration; deciding after the checkpoint would add the
build time to the delay.

### 3.3 Out of scope of this request

*Example:* the choice of change data capture product (left to the
platform team within the approved standards), and any change to policy
systems B and C.

## 4. Affected architecture

<!-- Guidance: List every approved work product, building block, requirement, contract, principle and dispensation the change touches. Use the repository IDs. This list becomes the update checklist in section 10. Pitfall: missing downstream items (a contract or a success measure) that then contradict the updated architecture. -->

| Item type | ID | Item | Effect of the change |
|---|---|---|---|
| Architecture Definition Document | ADD-ENG-001 section 4.2 | Target data architecture | Note the interim feed for system A; target unchanged |
| Transition Architecture | TA-1 *(Example)* | Foundation | Exit criteria reworded; date moves six weeks |
| Work package | WP-02 *(Example)* | Customer data hub and data quality | Adds the interim feed; cost and duration change |
| Requirement | ARS-INT-01 *(Example)* | Events carry golden ID and schema version | Applies to the interim feed as well |
| Requirement | ARS-INT-04 *(Example, new)* | Interim feed publishes the same customer events as the target API | Added to the specification |
| Contract | AC-02 *(Example)* | Data hub vendor and data team | Amended: new requirement and checkpoint |
| Principle | AP-01 *(Example)* | Integrate through published interfaces | Temporary provider-side exception, dated |
| Building block | *Example:* Change data capture service | New, interim | Retire when the vendor API is live |
| Success measure | SM-02 *(Example)* | Golden ID coverage | TA-1 target date moves six weeks |
| Decision record | *Example:* ADR-021 (new) | Interim feed for policy system A | Records the option choice |
| [Type] | [ID] | [Item] | [Effect] |

```mermaid
flowchart LR
  ACR["ACR change"] --> TA1["TA-1 Foundation"]
  ACR --> WP2["WP-02 Data hub"]
  WP2 --> AC2["Contract AC-02"]
  ACR --> R1["ARS-INT-01"]
  ACR --> R4["ARS-INT-04 (new)"]
  R4 --> AC2
  TA1 --> SM2["SM-02 TA-1 date"]
  ACR --> ADR["ADR-021"]
```

## 5. Change classification

<!-- Guidance: Classify the change by how much of the architecture it alters, because the class decides who approves it and whether a new ADM cycle is needed. Answer the questions in section 5.2 honestly and record the reasoning. Pitfall: calling a change "incremental" to avoid a new cycle when it really alters the target. -->

### 5.1 Classes and routes

The three class names come from Phase H; the descriptions, examples and
routes below are this template's suggestions. Set your own routes in the
Architecture Board charter.

| Class | What it means here | Typical examples | Route |
|---|---|---|---|
| Simplification change | Reduces, consolidates or tidies the architecture without changing what it delivers or its target | Removing a duplicate standard, merging two building blocks, retiring an unused interface | Lead architect approves; recorded in the change register; board informed |
| Incremental change | Adds to or alters part of the architecture while the target direction and its basis stay the same | Interim component, changed Transition Architecture, new requirement inside existing goals | Architecture Board decides; existing deliverables updated, or selected phases repeated |
| Re-architecting change | Alters the target, its goals or its fundamental constraints | New business model, replacing a core platform choice, goals that no longer hold | New Request for Architecture Work and a new ADM cycle; board and sponsor decide |

### 5.2 Classification questions

| Question | Answer *(Example)* | Points to |
|---|---|---|
| Does the change alter the target architecture? | No; the target still uses the vendor API | Not re-architecting |
| Does it change business goals, drivers or principles? | No; one principle gets a dated exception | Not re-architecting |
| Does it change a Transition Architecture, a work package or a requirement? | Yes: TA-1, WP-02, ARS-INT-04 | Incremental |
| Does it only remove or consolidate without changing outcomes? | No; it adds an interim component | Not simplification |
| Does it change a signed contract? | Yes: AC-02 | Board decision needed |
| Does it move cost beyond the approved envelope? | No, funded from contingency (USD 140,000 left) | Sponsor agreement; board informed of contingency use |

### 5.3 Result

| Field | Value |
|---|---|
| Proposed class | *Example:* Incremental change |
| Reasoning | *Example:* The target and its basis are unchanged; one Transition Architecture, one work package, one contract and the requirements change. Option C in section 7 would be re-architecting and is assessed only to show the board the alternative |
| Route | *Example:* Architecture Board decision at the next meeting; update existing deliverables; no new ADM cycle |

```mermaid
flowchart TD
  Q1{"Target, goals or<br/>basis change?"} -->|Yes| RA["Re-architecting<br/>New Request for Architecture Work"]
  Q1 -->|No| Q2{"Adds to or alters a transition,<br/>work package, requirement or contract?"}
  Q2 -->|Yes| INC["Incremental<br/>Board decides"]
  Q2 -->|No| SIM["Simplification<br/>Lead architect approves"]
```

## 6. Impact assessment

<!-- Guidance: Assess the impact across business, value, cost, schedule, risk, security and privacy, compliance, operations and people. Give numbers where you have them and show the comparison with doing nothing. Pitfall: assessing only cost and schedule, and discovering the privacy impact after approval. -->

| Dimension | Impact of the proposed change *(Example)* | Rating |
|---|---|---|
| Business outcome | TA-1 benefits arrive six weeks late instead of nine months late | Low negative |
| Success measures | SM-02 at 60% moves from month 8 to month 9.5; SM-01 at TA-2 unaffected if TA-2 keeps its date | Low negative |
| Cost | USD 85,000 build plus USD 10,000 per month to run for nine months: USD 175,000 | Medium |
| Schedule | TA-1 exit plus six weeks; TA-2 unchanged by using float in WP-03 | Low |
| Delivery risk | New interim component; vendor database schema could change without notice | Medium |
| Security and privacy | Database-level access to personal data; needs a service account with read-only rights and monitoring | Medium |
| Compliance and contracts | AC-02 amended; vendor support terms checked for database access | Medium |
| Operations | One more component to run, then retire | Low |
| People and skills | Platform team needs change data capture skills; one engineer trained | Low |
| Principles | AP-01 exception on the provider side for about nine months | Medium |
| [Dimension] | [Impact] | [High / Medium / Low] |

### 6.1 Cost arithmetic

| Item | Option B amount *(Example)* |
|---|---|
| Interim feed build and test | USD 85,000 |
| Run cost: USD 10,000 per month for 9 months | USD 90,000 |
| **Total** | **USD 175,000** |
| Roadmap base; contingency 15% (USD 315,000); committed total | USD 2,100,000; USD 315,000; USD 2,415,000 |
| Option B funded from contingency: contingency left | USD 315,000 minus USD 175,000 = USD 140,000 |
| Committed total after the change | USD 2,415,000 (unchanged) |
| Capital envelope (CNS-01) | USD 2,500,000 |

*Example check:* adding USD 175,000 on top of the committed USD 2,415,000
would give USD 2,590,000, which breaks CNS-01 by USD 90,000. Funding the
change from contingency keeps the commitment inside the cap; option A
(USD 255,000) would leave only USD 60,000 of contingency for the rest of
the programme.

## 7. Options considered

<!-- Guidance: Always include "do nothing" (or "wait") and at least one alternative to the proposal. Compare options on the same criteria and say which class each would be. Pitfall: presenting a single option, which leaves the board no real choice and invites a deferral. -->

| Criterion | A: Wait for vendor API | B: Interim change data capture | C: Bring forward policy system A consolidation |
|---|---|---|---|
| Change class | None (accept the delay) | Incremental | Re-architecting (changes target sequence and platform basis) |
| TA-1 date effect | Plus nine months | Plus six weeks | Plus twelve months for re-planning and delivery |
| Added cost *(Example)* | About USD 255,000: legacy CRM extended support USD 120,000 plus dual running USD 15,000 per month for 9 months | USD 175,000 | Brings WP-05 (USD 460,000) forward and needs a new funding decision |
| Effect on target | None | None | Target changes |
| Risk | CRM support gap; KPI-01 benefits slip | Interim component and schema drift | Large, new cycle |
| Principles | Met | AP-01 dated exception | Met |
| Reversibility | High | High: retire the feed | Low |
| Recommendation | No | **Yes** | No, unless option B proves infeasible |

### 7.1 Option evaluation notes

*Example:* Option A looks cheapest only if the cost of delay is ignored;
once the extended CRM support and nine months of dual running are
counted, it costs more than option B and delivers later. Option C solves
the root cause but turns a supplier delay into a new architecture cycle;
it remains the fallback if the vendor's database terms forbid change data
capture.

## 8. Recommendation

<!-- Guidance: State the recommended option, the class, the conditions you propose and the exit from any interim state. Make it a decision the board can take as written. Pitfall: recommending "option B, subject to further analysis", which is a deferral in disguise. -->

*Example:* Approve option B as an incremental change, with these
conditions:

1. C1: The vendor confirms in writing that read-only database access for
   change data capture is within support terms, before build starts.
2. C2: The interim feed passes the same contract tests as the target API
   (ARS-INT-04) before it feeds the hub in production.
3. C3: The security architect approves the service account design and
   monitoring before go-live.
4. C4: The interim feed is retired within three months of the vendor API
   going live; the AP-01 exception ends on that date or on YYYY-MM-DD,
   whichever is earlier.
5. C5: If C1 fails, the assessing architect returns with option C as a
   new Request for Architecture Work.

## 9. Decision

<!-- Guidance: The board secretary records the decision, the conditions, the votes or consensus, and the reasons. Link the board outcome record. Pitfall: approval without named owners and dates for each condition, so conditions are forgotten. -->

| Field | Value |
|---|---|
| Decision | *Example:* Approved with conditions |
| Decided by | *Example:* Architecture Board, outcome record ARB-2027-011 |
| Decision date | YYYY-MM-DD *(Example: 2027-06-07)* |
| Class confirmed | *Example:* Incremental change |
| Option chosen | *Example:* B: Interim change data capture |
| Reasons | *Example:* Lowest total cost including delay; target unchanged; reversible |
| Dissent or concerns recorded | *Example:* Security member asked for a penetration test of the feed before go-live (added as C6) |

### 9.1 Conditions

| ID | Condition | Owner | Due | Status |
|---|---|---|---|---|
| C1 *(Example)* | Vendor written confirmation of support terms | [@supplier-manager] | YYYY-MM-DD | [Open / Met] |
| C2 *(Example)* | Contract tests passed against both sources | [@wp02-lead] | YYYY-MM-DD | [Open / Met] |
| C3 *(Example)* | Service account design approved | [@security-architect] | YYYY-MM-DD | [Open / Met] |
| C4 *(Example)* | Interim feed retired after vendor API go-live | [@platform-lead] | YYYY-MM-DD | [Open / Met] |
| C5 *(Example)* | Fallback to option C if C1 fails | [@architect] | YYYY-MM-DD | [Not triggered] |
| C6 *(Example)* | Penetration test of the feed | [@security-architect] | YYYY-MM-DD | [Open / Met] |
| [Cn] | [Condition] | [@owner] | YYYY-MM-DD | [Status] |

### 9.2 Decision outcomes available

| Outcome | Meaning |
|---|---|
| Approved | Proceed as recommended |
| Approved with conditions | Proceed once the listed conditions are met, or while meeting them |
| Deferred | Decide later; state what information is missing and the new date |
| Rejected | Do not proceed; the approved architecture stands |
| Referred to a new cycle | The change is re-architecting; raise a Request for Architecture Work |

## 10. Implementing the change

<!-- Guidance: Turn the decision into updates of the approved architecture. Every item in section 4 must be updated, versioned and linked to this request. Pitfall: changing the delivery plan while the repository still shows the old architecture, so the next compliance review uses the wrong baseline. -->

### 10.1 Repository and document updates

| Item | Update | Owner | Done |
|---|---|---|---|
| ADD-ENG-001 | Note interim feed in section 4.2; new version | [@data-architect] | [ ] |
| ARS-ENG-001 | Add ARS-INT-04; update traceability; new version | [@requirements-owner] | [ ] |
| Roadmap | TA-1 exit criteria and date; WP-02 cost and duration; contingency drawn (USD 175,000) | [@lead-architect] | [ ] |
| Contract AC-02 | Variation VAR-02 with ARS-INT-04, conditions C2, C3 and C6 | [@contract-owner] | [ ] |
| ADR-021 | Record the decision and options | [@architect] | [ ] |
| Change register | Entry with class, decision and status | [@board-secretary] | [ ] |
| Principle exception | AP-01 exception logged with end date | [@board-secretary] | [ ] |
| [Item] | [Update] | [@owner] | [ ] |

### 10.2 Delivery actions

| Action | Owner | Due |
|---|---|---|
| *Example:* Build and test the interim feed | [@platform-lead] | YYYY-MM-DD |
| *Example:* Update the WP-02 plan and budget | [@wp02-lead] | YYYY-MM-DD |
| *Example:* Schedule the compliance check of the feed at the TA-1 checkpoint | [@architect] | YYYY-MM-DD |
| [Action] | [@owner] | YYYY-MM-DD |

Record decisions in the architecture decision log
(`architecture/architecture-decision-log`) and full records with the ADR
template (`architecture/adr-full`). Project-level changes to scope, cost
and schedule follow the project change control process
(`project/change-control`).

## 11. Communication

<!-- Guidance: Tell everyone whose work, plans or contracts change, in terms they care about, and say what they must do. Pitfall: the board decides, the repository is updated, and the delivery teams hear about it at the next compliance review. -->

| Audience | Message | Channel | When | Owner |
|---|---|---|---|---|
| *Example:* WP-02 team and hub vendor | Interim feed approved; contract amendment; new checkpoint | Contract meeting | Within 5 working days | [@contract-owner] |
| *Example:* WP-03 team | TA-2 date unchanged; float used | Programme meeting | Next meeting | [@programme-manager] |
| *Example:* Sponsor and steering group | Decision, cost, dates, conditions | Steering report | Next report | [@lead-architect] |
| *Example:* Distribution segment architects | Customer events unchanged for consumers | Architecture community update | Within 10 working days | [@architect] |
| *Example:* Security operations | New service account and monitoring | Ticket and briefing | Before go-live | [@security-architect] |
| [Audience] | [Message] | [Channel] | [When] | [@owner] |

## 12. Monitoring and closure

<!-- Guidance: Check that the change delivered what was expected and that any interim state really ends. Close the request only when its conditions are met and the repository reflects the new baseline. Pitfall: interim solutions that become permanent because nobody owns their retirement. -->

### 12.1 Monitoring

| Indicator | Expected | Check at | Owner |
|---|---|---|---|
| *Example:* Interim feed events passing contract tests | 100% | Weekly until TA-1 exit | [@wp02-lead] |
| *Example:* TA-1 exit date | Planned date plus six weeks or earlier | TA-1 checkpoint | [@lead-architect] |
| *Example:* Actual cost against USD 175,000 | Within 10% | Monthly | [@finance] |
| *Example:* Vendor API release R9 status | On the new date | Supplier review | [@supplier-manager] |
| [Indicator] | [Expected] | [When] | [@owner] |

### 12.2 Closure criteria

- [ ] All conditions in section 9.1 met or formally closed
- [ ] All updates in section 10.1 done and versioned
- [ ] Interim component retired, or its retirement scheduled with an owner
      and the principle exception end date confirmed
- [ ] Post-change review held and lessons recorded
      (`project/lessons-learned`)
- [ ] Change register entry set to Closed

### 12.3 Post-change review

*Example:* Review held YYYY-MM-DD. The interim feed met contract tests
from week two. TA-1 exited five weeks late against six planned. Lesson:
add a supplier API readiness check to the design checkpoint of every
contract that depends on a vendor interface.

### 12.4 Change register entry

| ACR ID | Title | Class | Driver | Decision | Board record | Status | Closed |
|---|---|---|---|---|---|---|---|
| ACR-2027-03 *(Example)* | Interim feed for policy system A | Incremental | Supplier event | Approved with conditions | ARB-2027-011 | Closed | YYYY-MM-DD |
| [ACR-YYYY-NN] | [Title] | [Class] | [Driver] | [Decision] | [ARB-YYYY-NNN] | [Status] | YYYY-MM-DD |

## 13. Glossary and references

<!-- Guidance: Define the change management terms used and list the documents the request relies on. -->

### 13.1 Glossary

| Term | Meaning in this document |
|---|---|
| Architecture Change Management | Phase H of the ADM: keeping the approved architecture fit for purpose as drivers change |
| Change register | The list of all change requests with class, decision and status |
| Dispensation | A time-limited permission to deviate from an architecture requirement, principle or standard without changing the architecture |
| Incremental change | A change to part of the architecture that leaves the target direction and its basis unchanged |
| Re-architecting change | A change to the target, its goals or its fundamental constraints, handled by a new ADM cycle |
| Simplification change | A change that reduces or consolidates the architecture without changing what it delivers |
| Transition Architecture | A stable intermediate state between the baseline and the target |
| [Term] | [Meaning] |

### 13.2 References

| ID | Reference | Version / date |
|---|---|---|
| REF-01 | The TOGAF Standard, 10th Edition (The Open Group, catalogue C220), incorporating Technical Corrigendum 1 (U254, 15 May 2025) | 19 May 2025 |
| REF-02 | Architecture Board Charter (`architecture/architecture-governance-charter`) | [x.y] |
| REF-03 | Architecture Definition Document (`architecture/architecture-definition-document`) | [x.y] |
| REF-04 | Architecture Requirements Specification (`architecture/architecture-requirements-specification`) | [x.y] |
| REF-05 | Architecture Roadmap and Transition Architectures (`architecture/architecture-roadmap-transition`) | [x.y] |
| REF-06 | Architecture Contract (`architecture/architecture-contract`) | [AC-nn] |
| REF-07 | Architecture Compliance Assessment (`architecture/architecture-compliance-assessment`) | [x.y] |
| REF-08 | Request for Architecture Work, for re-architecting changes (`architecture/request-for-architecture-work`) | [x.y] |

## Standard and licence note

Structure aligned with The TOGAF Standard, 10th Edition (2025 release with Technical Corrigendum 1),
published by The Open Group: Phase H (Architecture Change Management) of
the Architecture Development Method, with its classification of changes
as simplification, incremental or re-architecting, and links to the
Architecture Definition Document, Architecture Requirements
Specification, Architecture Roadmap and Architecture Contracts. TOGAF and
ArchiMate are registered trademarks of The Open Group. This template uses
only the names of phases, deliverables and change classes; all text is
original. It was written from general professional practice, without
reading, quoting, paraphrasing or summarising the text of the standard,
and it reproduces no definitions, tables or lists from it. The class
descriptions, routes, classification questions and decision outcomes are
suggestions of this template, not requirements of the standard. Check the
current edition and any technical corrigenda at opengroup.org and obtain
the standard for its own guidance.
Template licence: MIT.