# Architecture Board Charter: [Organisation or domain]

> Charter and governance framework for an Architecture Board: purpose,
> authority and decision rights, membership and quorum, cadence, how
> architecture review requests come in, the compliance review process and
> its four outcomes, dispensations, Architecture Contracts, escalation, the
> architecture repository, metrics and the review of this charter. The
> structure follows the architecture governance and Architecture Board
> guidance of The TOGAF Standard, 10th Edition (2025 Update), with Phase G
> (Implementation Governance) and Phase H (Architecture Change Management)
> of the Architecture Development Method. Replace every `[bracketed]` value
> and every row marked *Example*.

<!--
Guidance: How to use this template
- A board without written authority becomes an advisory club that teams
  route around. Agree section 2 (authority and decision rights) with the
  executive sponsor before anything else, and get it signed.
- Keep the process proportionate: most changes should be reviewed by
  delegated architects in days, with only high-impact items reaching the
  full board. Section 5 sets the tiers.
- The four outcomes in section 7 and the dispensation register in section
  8 are what teams experience. Make them predictable, time-boxed and
  published.
- Related templates: requests arrive as an architecture review request
  (`architecture/architecture-review-request`), decisions are recorded as
  ADRs (`architecture/adr-full`), and principles come from
  `architecture/architecture-principles`.
-->

## Document control

<!-- Guidance: The charter is a governance instrument. Record who authorised it, when it takes effect and when it must be reviewed. -->

| Field | Value |
|---|---|
| Document ID | [ARB-CHARTER-001] |
| Board name | [Enterprise Architecture Board / Domain Architecture Board] |
| Scope of authority | [Whole enterprise / business unit / domain] |
| Authorised by | [Executive sponsor, for example the CIO or COO] |
| Effective date | YYYY-MM-DD |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (board chair) | [@chair] |
| Secretary | [@secretary] |
| Approvers / reviewers | [Executive committee, CIO, CISO, CFO delegate] |
| Classification | [Internal] |
| Next scheduled review | YYYY-MM-DD |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@sponsor] | [Approved / Approved with changes / Rejected] | YYYY-MM-DD |
| Chief Information Officer | [@cio] | [Decision] | YYYY-MM-DD |
| Chief Information Security Officer | [@ciso] | [Decision] | YYYY-MM-DD |
| Board chair | [@chair] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for executive review |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by executive committee (minutes EXCO-2026-09) |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Tier thresholds raised after first annual review; dispensation maximum term set to 12 months |

## Contents

1. [Purpose and scope](#1-purpose-and-scope)
2. [Authority and decision rights](#2-authority-and-decision-rights)
3. [Membership, roles and quorum](#3-membership-roles-and-quorum)
4. [Meetings and cadence](#4-meetings-and-cadence)
5. [Inputs and review tiers](#5-inputs-and-review-tiers)
6. [Compliance review process](#6-compliance-review-process)
7. [Review outcomes](#7-review-outcomes)
8. [Dispensations](#8-dispensations)
9. [Architecture Contracts](#9-architecture-contracts)
10. [Escalation and appeals](#10-escalation-and-appeals)
11. [Architecture repository and records](#11-architecture-repository-and-records)
12. [Metrics and reporting](#12-metrics-and-reporting)
13. [Conduct and conflicts of interest](#13-conduct-and-conflicts-of-interest)
14. [Review of this charter](#14-review-of-this-charter)
15. [Glossary and references](#15-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: Say why the board exists in business terms and what it governs. Name what it does not govern, so it is not used as a general escalation point. Pitfall: a purpose statement about "ensuring quality" that gives no basis for saying no. -->

### 1.1 Purpose

The Architecture Board exists to keep change in [Organisation] consistent
with the agreed target architecture, principles and standards, so that
investments add up to a coherent, secure and affordable landscape rather
than a collection of local optimisations. It does this by approving
architecture work products, reviewing solutions for compliance, granting
or refusing dispensations, and steering changes to the architecture
itself.

### 1.2 Objectives

| ID | Objective | Measured by (section 12) |
|---|---|---|
| OBJ-01 *(Example)* | Decisions are timely and predictable for delivery teams | Review lead time |
| OBJ-02 *(Example)* | Solutions conform to principles and standards, or deviate knowingly and temporarily | Compliance rate; dispensations overdue |
| OBJ-03 *(Example)* | The landscape simplifies over time | Applications retired versus added |
| OBJ-04 *(Example)* | Architecture knowledge is reusable | Reuse of approved building blocks |
| [OBJ-nn] | [Objective] | [Metric] |

### 1.3 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Architecture work products from the Architecture Development Method (vision, definition, roadmap) | Project budget approval (portfolio board) |
| *Example:* Solutions that add, replace or retire an application, platform or integration | Operational change approval (change advisory board) |
| *Example:* Changes to principles, standards and reference architectures | Individual security exceptions for end-user devices (security office) |
| *Example:* Dispensations from principles and standards | Vendor commercial negotiations |
| [In scope item] | [Out of scope item] |

## 2. Authority and decision rights

<!-- Guidance: Write down what the board may decide, what it recommends, and what it must be told. Name the source of the authority. Use a decision rights table so nobody argues later. Pitfall: claiming decision rights the executive never granted. -->

### 2.1 Source of authority

The board acts under the authority delegated by [executive sponsor or
committee] on YYYY-MM-DD. Its decisions bind all [business units,
programmes, projects and suppliers] within the scope in section 1.3.
Funding bodies will not release [stage 2] funding to an initiative that
has not passed the review required by its tier in section 5.

### 2.2 Decision rights

| Decision | Board | Chair alone | Delegated architect | Portfolio board | Executive |
|---|---|---|---|---|---|
| *Example:* Approve Architecture Vision and Statement of Architecture Work | Decides | | | Informed | Informed |
| *Example:* Approve Architecture Definition Document and Roadmap | Decides | | | Consulted | Informed |
| *Example:* Compliance review outcome, tier 1 | Decides | | | Informed | |
| *Example:* Compliance review outcome, tier 2 | Informed | | Decides | | |
| *Example:* Grant dispensation up to 6 months | | Decides | Recommends | | |
| *Example:* Grant dispensation over 6 months or with high risk | Decides | | Recommends | | Informed |
| *Example:* Renew a dispensation a second time | Recommends | | | | Decides |
| *Example:* Change an architecture principle | Recommends | | | | Decides |
| *Example:* Add or retire a technology standard | Decides | | Recommends | | |
| *Example:* Stop an initiative for non-compliance | Recommends | | | Decides | Informed |
| [Decision] | [Role] | [Role] | [Role] | [Role] | [Role] |

### 2.3 Standards the board applies

| Source | Reference |
|---|---|
| Architecture principles | Architecture Principles Catalogue (`architecture/architecture-principles`) |
| Technology standards | Technology radar (`architecture/tech-radar`) |
| Reference architectures | Reference architecture set (`architecture/reference-architecture`) |
| Security architecture | Security architecture (`security/security-architecture`) |
| Approved target architectures | [Repository location of approved definitions and roadmaps] |

## 3. Membership, roles and quorum

<!-- Guidance: Name roles, not people, so the charter survives reorganisation; list current holders separately. Balance architecture expertise with business authority. Pitfall: a board of architects only, whose decisions the business does not feel bound by. -->

### 3.1 Members

| Role on the board | Held by (role) | Voting | Current holder |
|---|---|---|---|
| Chair | Chief or enterprise architect | Yes (casting vote) | [@name] |
| Business representative | Head of [business unit] or delegate | Yes | [@name] |
| Business architecture | Lead business architect | Yes | [@name] |
| Data architecture | Lead data architect | Yes | [@name] |
| Application architecture | Lead application architect | Yes | [@name] |
| Technology and platforms | Head of platforms or lead technology architect | Yes | [@name] |
| Security | CISO delegate or lead security architect | Yes (veto on security matters, see 3.3) | [@name] |
| Operations | Head of IT operations or SRE lead | Yes | [@name] |
| Data protection | Data protection officer or delegate | Advisory | [@name] |
| Finance | Finance business partner | Advisory | [@name] |
| Secretary | Architecture office | No | [@name] |

### 3.2 Responsibilities

| Role | Responsibilities |
|---|---|
| Chair | Sets the agenda, runs meetings, signs outcomes, decides dispensations of up to 6 months within delegation, reports to the executive |
| Members | Read submissions before the meeting, give a reasoned position, declare conflicts, follow up assigned actions |
| Delegated architects | Run tier 2 reviews, prepare tier 1 submissions, monitor conditions and dispensations in their domain |
| Secretary | Triages requests, keeps the registers in sections 8 and 9, publishes minutes within [2] working days |
| Submitter | Provides a complete request, attends the review, implements conditions |

### 3.3 Quorum and voting

- Quorum is [the chair or a nominated deputy plus at least four voting
  members, including the security member].
- Decisions are by consensus; if consensus is not reached, by simple
  majority of voting members present, with the chair holding a casting
  vote.
- The security member may block approval on a security ground; a block
  is resolved by escalation (section 10), not by vote.
- Members may name one standing deputy each; deputies count toward quorum.
- Decisions taken without quorum are provisional and must be confirmed at
  the next quorate meeting or by written procedure within [5] working days.

## 4. Meetings and cadence

<!-- Guidance: Fix the rhythm so teams can plan around it, and provide a fast path for urgent items. Publish deadlines for submissions. Pitfall: monthly meetings only, which makes the board the bottleneck in every delivery plan. -->

| Forum | Frequency | Duration | Purpose | Submission deadline |
|---|---|---|---|---|
| *Example:* Board meeting | Every two weeks | 90 minutes | Tier 1 reviews, dispensations over 6 months, standards | [5] working days before |
| *Example:* Delegated review | Weekly | 30 minutes per item | Tier 2 reviews | [2] working days before |
| *Example:* Written procedure | As needed | Not applicable | Urgent items; confirmation of provisional decisions | Any time |
| *Example:* Strategy session | Quarterly | Half day | Roadmap progress, principle and standard changes, metrics | [10] working days before |
| [Forum] | [Frequency] | [Duration] | [Purpose] | [Deadline] |

Standard agenda: declarations of interest, actions from last meeting,
reviews in order of tier and urgency, dispensations due for renewal,
standards changes, metrics, any other business.

## 5. Inputs and review tiers

<!-- Guidance: Define what triggers a review, what must be submitted and which tier the item falls into. Triage criteria must be objective enough that the secretary can apply them. Pitfall: reviewing everything at the same depth. -->

### 5.1 Triggers

A review is required when an initiative [adds, replaces or retires an
application or platform; introduces a new integration with an external
party; processes a new category of personal or regulated data; proposes a
technology not on the adopted list; or requests a deviation from a
principle or standard]. Architecture work products from an ADM cycle are
reviewed at the gates set in their Statement of Architecture Work.

### 5.2 Submission

Submit an architecture review request
(`architecture/architecture-review-request`) with the attachments listed
for the tier. Incomplete requests are returned within [2] working days.

### 5.3 Tiers

| Tier | Criteria (any one applies) | Reviewed by | Target lead time | Required attachments |
|---|---|---|---|---|
| Tier 1 *(Example)* | Capital cost above USD [500,000]; new platform or vendor for a critical service; personal data of more than [100,000] people; deviation from a principle | Full board | 15 working days | Review request, solution architecture or definition document, threat model, cost estimate |
| Tier 2 *(Example)* | New application or integration below tier 1 thresholds; technology on the trial list | Delegated architect | 5 working days | Review request, design document |
| Tier 3 *(Example)* | Change within an approved design and standards | Self-assessment, sampled | Not applicable | Completed checklist in the repository |
| [Tier] | [Criteria] | [Reviewer] | [Lead time] | [Attachments] |

Useful attachments include the solution architecture
(`architecture/solution-architecture`), a threat model
(`security/threat-model`) and the cloud architecture review
(`architecture/cloud-architecture-review`).

## 6. Compliance review process

<!-- Guidance: Describe the steps from request to outcome, with owners and time limits for each, and the evidence reviewers look at. A review checks conformance to the approved architecture, principles and standards; it is not a redesign session. Pitfall: reviews scheduled after build, when only "compliant" or a costly rework are realistic answers. -->

```mermaid
flowchart TD
  A["Request submitted"] --> B{"Complete?"}
  B -->|no| A
  B -->|yes| C["Secretary assigns tier and reviewers"]
  C --> D["Reviewers assess against principles, standards and target architecture"]
  D --> E{"Tier 1?"}
  E -->|yes| F["Board meeting"]
  E -->|no| G["Delegated review"]
  F --> H["Outcome recorded"]
  G --> H
  H --> I{"Outcome"}
  I -->|Compliant| J["Proceed"]
  I -->|Compliant with conditions| K["Proceed; conditions tracked"]
  I -->|Dispensation| L["Proceed under dispensation; register entry"]
  I -->|Non-compliant| M["Rework and resubmit, or escalate"]
```

### 6.1 Review points in the delivery lifecycle

| Review point | When | Focus |
|---|---|---|
| Concept review *(Example)* | Before funding stage 2 | Fit with target architecture and roadmap; options considered |
| Design review *(Example)* | Before build starts | Conformance to principles, standards, Architecture Contract terms |
| Pre-production review *(Example)* | Before go-live | Implementation matches approved design; conditions closed; operational readiness |
| Post-implementation review *(Example)* | [3] months after go-live | Realised architecture, debt incurred, lessons |
| [Point] | [When] | [Focus] |

### 6.2 What reviewers assess

| Area | Question | Evidence |
|---|---|---|
| Strategic fit | Does the solution move the landscape toward the approved target or a Transition Architecture? | Roadmap reference |
| Principles | Which principles apply and is each met? | Principles compliance table in the request |
| Standards | Are all technologies adopted or approved for trial? | Technology list versus the radar |
| Security and privacy | Are threats identified and controls designed? Is personal data handled lawfully? | Threat model, privacy assessment |
| Data | Is every data entity mastered once and owned? | Data model, data dictionary |
| Operations | Can it be run, monitored and recovered? | Operability checklist, recovery targets |
| Cost | Is the run cost known and accepted by an owner? | TCO estimate |
| Reuse | Could an existing building block have been used? | Search of the repository |

TOGAF also describes graded levels of conformance for a compliance
assessment; if you use them, map them to the four outcomes in section 7.

## 7. Review outcomes

<!-- Guidance: Every review ends in exactly one of four outcomes, written down with reasons. State what each outcome allows the team to do next. Pitfall: vague outcomes such as "noted" that leave the team unsure whether it may proceed. -->

| Outcome | Meaning | Team may proceed? | Follow-up |
|---|---|---|---|
| Compliant | Meets the approved architecture, principles and standards | Yes | None beyond normal review points |
| Compliant with conditions | Acceptable once named conditions are met by stated dates | Yes, at risk until conditions close | Conditions tracked in the outcome record; checked at next review point |
| Dispensation | Deviates knowingly from a principle or standard; deviation accepted for a limited time with mitigation | Yes, within the terms of the dispensation | Entry in the dispensation register (section 8) |
| Non-compliant | Does not meet requirements and no dispensation is granted | No | Rework and resubmit, or escalate (section 10) |

### 7.1 Outcome record

| Field | Content |
|---|---|
| Review ID | [ARB-YYYY-NNN] |
| Request | [Request ID and title] |
| Tier and forum | [Tier 1, board meeting YYYY-MM-DD] |
| Outcome | [Compliant / Compliant with conditions / Dispensation / Non-compliant] |
| Reasons | [Short reasoned statement referring to principles and standards] |
| Conditions | [ID, condition, owner, due date] |
| Dispensation reference | [DSP-YYYY-NN, if any] |
| Signed by | [@chair or delegated architect], YYYY-MM-DD |

### 7.2 Example outcomes

| Review ID | Initiative | Outcome | Summary |
|---|---|---|---|
| ARB-2026-031 *(Example)* | Customer data hub | Compliant with conditions | C1: matching accuracy report before go-live; C2: retention rules configured per data dictionary |
| ARB-2026-034 *(Example)* | Claims package hosting | Dispensation | Vendor-hosted outside the approved platform for 12 months; DSP-2026-07 |
| ARB-2026-036 *(Example)* | Marketing file export to agency | Non-compliant | Bulk personal data by e-mail; must use the approved transfer service |
| [ARB-YYYY-NNN] | [Initiative] | [Outcome] | [Summary] |

## 8. Dispensations

<!-- Guidance: A dispensation is a time-limited, risk-accepted exception. It needs an owner, a reason, a mitigation, an expiry and an exit plan. Review the register at every board meeting. Pitfall: dispensations without expiry, which turn into permanent undocumented standards. -->

### 8.1 Rules

- A dispensation names the principle or standard it departs from, the
  reason, the risk, the mitigation, the business owner who accepts the
  risk, the expiry date and the plan to reach compliance.
- Maximum term: [12] months; renewal once, with a new risk assessment.
  Further renewal requires an executive decision (section 2.2).
- The security member must agree any dispensation that raises security
  risk; the data protection officer is consulted on any that affects
  personal data.
- Expired dispensations are reported to the executive sponsor at the next
  quarterly session.
- Accepted architecture debt is also recorded in the tech debt register
  (`architecture/tech-debt-register`).

### 8.2 Dispensation register

| Dispensation ID | Initiative | Principle or standard | Reason | Risk and mitigation | Risk owner | Granted | Expires | Exit plan | Status |
|---|---|---|---|---|---|---|---|---|---|
| DSP-2026-07 *(Example)* | Claims package hosting | TP-01 Prefer managed services on approved platforms | Vendor cannot yet deploy on the company cloud platform | Third-party access risk; contractual audit rights, SSO, monthly log review | [@head-of-claims] | 2026-09-15 | 2027-09-14 | Move to company platform in the vendor release planned for [quarter] | Active |
| DSP-2026-04 *(Example)* | Finance reporting | AP-01 Integrate through published interfaces | Legacy ledger has no API | Data latency and fragility; file checksums and alerts | [@finance-lead] | 2026-03-01 | 2027-02-28 | Replace with events when ledger upgrade lands | Active, renewal due |
| [DSP-YYYY-NN] | [Initiative] | [Principle or standard] | [Reason] | [Risk and mitigation] | [@owner] | YYYY-MM-DD | YYYY-MM-DD | [Plan] | [Active / Expired / Closed] |

The principles catalogue keeps its own waiver register
(`architecture/architecture-principles`); use this register as the single
record and link to it from there.

## 9. Architecture Contracts

<!-- Guidance: An Architecture Contract is the agreement between the architecture function and a delivery party (internal team or supplier) on what will be built, which requirements and standards apply and how compliance will be checked. Issue one per work package or major project at the start of delivery. Pitfall: contracts signed and never looked at again; tie them to the review points. -->

### 9.1 Contract contents

| Section | Content |
|---|---|
| Parties | Architecture Board (represented by the chair) and the delivery party |
| Scope | Work package or project, with reference to the roadmap |
| Architecture baseline | Approved definition document, version and relevant views |
| Requirements | Architecture requirements that apply (ARS IDs), standards and principles |
| Deliverables | Design documents, models and evidence the party will provide |
| Review points | Which reviews from section 6.1 apply and when |
| Change procedure | How the party requests a change to the contract or a dispensation |
| Acceptance | Criteria for closing the contract at the post-implementation review |
| Signatures | Chair, delivery lead, business owner |

### 9.2 Contract register

| Contract ID | Work package or project | Delivery party | Requirements | Next review point | Status |
|---|---|---|---|---|---|
| AC-01 *(Example)* | WP-01 Cloud and integration foundation | Platform team | ARS-TEC-01, ARS-DAT-02 | Pre-production, YYYY-MM-DD | Active |
| AC-02 *(Example)* | WP-02 Customer data hub | Vendor and data team | ARS-DAT-01, ARS-INT-01 | Design, YYYY-MM-DD | Active |
| [AC-nn] | [Work package] | [Party] | [ARS IDs] | [Point and date] | [Draft / Active / Closed] |

Contracts for engagement work packages are listed in the roadmap
(`architecture/architecture-roadmap-transition`).

## 10. Escalation and appeals

<!-- Guidance: Give teams a fair, fast route to challenge an outcome, and give the board a route when it cannot resolve a conflict. Time-box every step. Pitfall: no appeal route, so disagreements go around the board informally. -->

| Level | Who | When | Time limit |
|---|---|---|---|
| 1 | Chair and submitter meet | Submitter disputes an outcome or a condition | [5] working days from outcome |
| 2 | Full board reconsiders with new evidence | Level 1 does not resolve | Next board meeting |
| 3 | Executive sponsor decides | Board cannot reach a decision, security block, or level 2 does not resolve | [10] working days |

Escalations and their results are minuted and reported in the quarterly
metrics. An appeal does not suspend a non-compliant outcome unless the
chair says so in writing.

## 11. Architecture repository and records

<!-- Guidance: Say where every governance record lives, who maintains it and how long it is kept. The repository is what makes the board's decisions reusable and auditable. Pitfall: decisions living only in meeting slides. -->

| Record | Location | Maintained by | Retention |
|---|---|---|---|
| Review requests and outcome records | [Repository path] | Secretary | [7] years |
| Minutes | [Repository path] | Secretary | [7] years |
| Dispensation register | [Repository path] | Secretary | Life of dispensation plus [3] years |
| Architecture Contracts | [Repository path] | Delegated architects | Contract close plus [3] years |
| Approved architecture work products | [Repository path] | Lead architects | Until superseded plus [3] years |
| Architecture decision records | [Repository path] | Decision owners | Permanent |
| Principles, standards, reference architectures | [Repository path] | Chair | Current and previous version |

Records are readable by [all staff / all architects and delivery leads]
unless classified otherwise. Changes to approved work products follow
change management in Phase H: the requester submits a change request, the
board assesses its impact and decides whether it is handled within the
current architecture or needs a new ADM cycle.

## 12. Metrics and reporting

<!-- Guidance: Measure whether the board helps or hinders. Publish the numbers quarterly, including the unflattering ones. Pitfall: measuring only activity (number of reviews) and never outcomes. -->

| Metric ID | Metric | Definition | Target *(Example)* | Objective |
|---|---|---|---|---|
| MET-01 | Review lead time | Working days from complete request to outcome, by tier | Tier 1 at most 15, tier 2 at most 5 | OBJ-01 |
| MET-02 | First-time compliance rate | Share of reviews ending compliant or compliant with conditions | At least 80% | OBJ-02 |
| MET-03 | Conditions closed on time | Share of conditions closed by their due date | At least 90% | OBJ-02 |
| MET-04 | Dispensations overdue | Active dispensations past expiry | 0 | OBJ-02 |
| MET-05 | Landscape simplification | Applications retired minus applications added, per year | Positive | OBJ-03 |
| MET-06 | Building block reuse | Share of tier 1 solutions reusing at least one approved building block | At least 60% | OBJ-04 |
| MET-07 | Submitter satisfaction | Average score from a short survey after each review | At least 4 of 5 | OBJ-01 |
| [MET-nn] | [Metric] | [Definition] | [Target] | [OBJ-nn] |

Report quarterly to [executive committee] with the trend, the open
dispensations and the main architecture risks.

## 13. Conduct and conflicts of interest

<!-- Guidance: Set expectations for how members behave so outcomes are trusted. Pitfall: a member reviewing their own team's submission. -->

- Members declare any interest in an item (their own team, a supplier
  relationship, a personal stake) at the start of the meeting; the
  declaration is minuted and the member does not vote on that item.
- Reviews judge the submission against published criteria. Members give
  reasons, cite principles or standards, and avoid redesigning the
  solution in the meeting.
- Submissions may contain confidential commercial or security
  information; members do not share them outside the board.
- Members who miss [three] consecutive meetings without a deputy are
  replaced at the request of the chair.

## 14. Review of this charter

<!-- Guidance: Plan how the charter itself is kept current. Use the metrics to decide changes. Pitfall: thresholds set once and never adjusted as the organisation grows. -->

The chair reviews this charter every [12] months, and earlier after a
major reorganisation, a change in executive sponsorship, or a quarter in
which two or more metrics miss their target. The review considers the
tier thresholds, decision rights, membership, dispensation terms and the
metrics themselves. Changes to sections 2 and 3 require the executive
sponsor's approval; other changes are approved by the board and recorded
in the revision history.

| Review date | Trigger | Changes made | Approved by |
|---|---|---|---|
| YYYY-MM-DD *(Example)* | Annual review | Tier 1 cost threshold raised; MET-07 added | Executive sponsor |
| [YYYY-MM-DD] | [Trigger] | [Changes] | [Approver] |

## 15. Glossary and references

<!-- Guidance: Define governance terms in plain language and list the sources and related documents. -->

### 15.1 Glossary

| Term | Meaning in this charter |
|---|---|
| Architecture Board | The body accountable for architecture governance within the scope of this charter |
| Architecture governance | The practice of directing and controlling architecture work and its implementation |
| Compliance review | An assessment of whether a solution or work product conforms to the approved architecture, principles and standards |
| Dispensation | A time-limited, risk-accepted permission to depart from a principle or standard |
| Architecture Contract | An agreement between the architecture function and a delivery party on what is built and how compliance is checked |
| Architecture repository | The managed store of architecture work products, decisions and governance records |
| Tier | The review depth assigned to a request by objective criteria |
| [Term] | [Meaning] |

### 15.2 References

| ID | Reference | Version / date |
|---|---|---|
| REF-01 | The TOGAF Standard, 10th Edition (The Open Group), 2025 Update | June 2025 |
| REF-02 | Architecture Principles Catalogue (`architecture/architecture-principles`) | [x.y] |
| REF-03 | Architecture Review Request (`architecture/architecture-review-request`) | [x.y] |
| REF-04 | Architecture Vision (`architecture/togaf-architecture-vision`) | [x.y] |
| REF-05 | Architecture Roadmap and Transition Architectures (`architecture/architecture-roadmap-transition`) | [x.y] |
| REF-06 | Technology radar (`architecture/tech-radar`) | [Date] |
| REF-07 | Decision rights matrix for the wider organisation (`business/raci`) | [x.y] |

## Standard and licence note

Structure aligned with The TOGAF Standard, 10th Edition (2025 Update),
published by The Open Group: architecture governance, the Architecture
Board, Architecture Contracts, compliance review and Compliance
Assessment, with Phase G (Implementation Governance) and Phase H
(Architecture Change Management) of the Architecture Development Method.
The four review outcomes, tiers, metrics and all text are original to this
template, which reproduces no definitions, tables or other text from the
standard. TOGAF is a registered trademark of The Open Group. Check the
current edition at opengroup.org and obtain the standard for its full
guidance. Template licence: MIT.