# Architecture Contract: [Work package or project name]

> Architecture Contract between the architecture function and one delivery
> party (an internal team or a supplier) for one work package or project,
> issued at the start of Phase G (Implementation Governance) of the
> Architecture Development Method in The TOGAF Standard, 10th Edition
> (2025 release with Technical Corrigendum 1). It names the parties, the scope and the approved
> architecture the delivery must follow, the requirements and standards
> that apply, the deliverables and evidence the party provides, the
> conformance and acceptance criteria, the checkpoints, what may be
> dispensed with and how, the metrics, change and escalation, duration
> and signatures. Replace every `[bracketed]` value and every row marked
> *Example*. This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- The contract turns an approved architecture into commitments a delivery
  party can plan against and an assessor can check. Write each clause so
  that a third party could tell whether it was kept.
- Fill in this order: 2 (parties) -> 3 (scope) -> 4 (baseline) -> 5
  (requirements and standards) -> 6 and 7 (deliverables, conformance) ->
  8 (checkpoints) -> 9 to 11 (dispensations, metrics, change) -> 12 to 15
  -> 16 (signatures). Section 1 is written last.
- For an internal team the contract is a governance agreement. For a
  supplier, attach it to the statement of work (`business/statement-of-work`)
  and have your legal team decide how it is incorporated; this template
  does not replace commercial terms.
- The rules for tiers, outcomes, dispensations and escalation are in the
  Architecture Board Charter (`architecture/architecture-governance-charter`).
  Conformance is checked with the Architecture Compliance Assessment
  (`architecture/architecture-compliance-assessment`) at the checkpoints
  in section 8.
- The worked example follows the fictional insurer used across the TOGAF
  templates: contract AC-02 for work package WP-02 (customer data hub),
  delivered by a vendor together with the internal data team.
-->

## Document control

<!-- Guidance: Identify the contract and its place in the governance record. The contract is versioned like any work product; every variation after signature creates a new version and a variation entry in section 11. -->

| Field | Value |
|---|---|
| Document ID (contract ID) | [AC-nn] |
| Work package or project | [WP-nn, name] |
| Roadmap reference | [Architecture Roadmap version, Transition Architecture name] |
| Delivery party | [Team or supplier name] |
| Related statement of work | [SOW-ID, if a supplier is involved] |
| Version | [0.1] |
| Status | [Draft / In review / Signed / Active / Varied / Closed / Terminated] |
| Owner (contract architect) | [@contract-architect] |
| Approvers / reviewers | [Architecture Board chair, delivery lead, business owner, procurement or legal for suppliers] |
| Effective date | YYYY-MM-DD |
| Planned end | YYYY-MM-DD |
| Classification | [Internal / Confidential / Commercial in confidence] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Conditions | Date |
|---|---|---|---|---|
| Architecture Board chair | [@chair] | [Approved / Approved with conditions / Rejected] | [Conditions] | YYYY-MM-DD |
| Delivery lead (delivery party) | [@delivery-lead] | [Accepted / Accepted with comments] | [Comments] | YYYY-MM-DD |
| Business owner | [@business-owner] | [Approved] | [Conditions] | YYYY-MM-DD |
| Security architect | [@security] | [Reviewed] | [Conditions] | YYYY-MM-DD |
| Procurement or legal (supplier contracts) | [@legal] | [Reviewed] | [Conditions] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from the approved roadmap and requirements specification |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Signed by all parties; status Active |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Variation VAR-01: interim CRM batch export allowed under DSP-2027-02 (outcome record ARB-2027-007) |
| 1.2 | YYYY-MM-DD | [@name] | *Example:* Variation VAR-02 under change request ACR-2027-03 (ARB-2027-011): ARS-INT-04 added, baseline moved to Architecture Requirements Specification 1.1, change request conditions C2, C3 and C6 added as checkpoint evidence |

## Contents

1. [Contract summary](#1-contract-summary)
2. [Parties and representatives](#2-parties-and-representatives)
3. [Scope of the contract](#3-scope-of-the-contract)
4. [Architecture baseline referenced](#4-architecture-baseline-referenced)
5. [Architecture requirements and standards](#5-architecture-requirements-and-standards)
6. [Deliverables and evidence](#6-deliverables-and-evidence)
7. [Conformance and acceptance criteria](#7-conformance-and-acceptance-criteria)
8. [Checkpoints and review schedule](#8-checkpoints-and-review-schedule)
9. [Dispensations and permitted deviations](#9-dispensations-and-permitted-deviations)
10. [Quality and fitness metrics](#10-quality-and-fitness-metrics)
11. [Change control and escalation](#11-change-control-and-escalation)
12. [Roles and responsibilities](#12-roles-and-responsibilities)
13. [Risks, assumptions and dependencies](#13-risks-assumptions-and-dependencies)
14. [Supplier provisions](#14-supplier-provisions)
15. [Duration, termination and closure](#15-duration-termination-and-closure)
16. [Signatures](#16-signatures)
17. [Glossary and references](#17-glossary-and-references)

## 1. Contract summary

<!-- Guidance: Summarise the agreement in a few lines for anyone who will not read the clauses: who commits to what, against which architecture, checked when. Pitfall: a summary that restates the project charter; this contract is about architecture conformance, not project scope in general. -->

| Item | Summary |
|---|---|
| Purpose | *Example:* Bind the delivery of WP-02 Customer data hub to the approved target data and application architecture |
| Parties | *Example:* Architecture Board (represented by the chair) and the WP-02 delivery party (vendor [Supplier name] with the internal data team) |
| Baseline | *Example:* Architecture Definition Document 1.0, Architecture Requirements Specification 1.0 at signature (1.1 after VAR-02), principles catalogue 2.3 |
| Key commitments | *Example:* 10 contracted architecture requirements at signature (11 after VAR-02), 2 mandatory standards and 3 mandatory building blocks |
| Checkpoints | *Example:* 4 (concept, design, pre-production, post-implementation) |
| Pre-agreed deviations | *Example:* None at signature; one dispensation added at the design review by variation VAR-01 |
| Term | *Example:* Signature to closure at the post-implementation review, planned YYYY-MM-DD |

## 2. Parties and representatives

<!-- Guidance: Name the organisations and the individuals who act for them. The architecture side is the function that governs, usually the board through a named contract architect. The delivery side is whoever builds. Add the business owner, who accepts residual risk. Pitfall: signing with a project manager who has no authority over the supplier's design choices. -->

| Party | Organisation | Representative | Authority | Contact |
|---|---|---|---|---|
| Architecture function | *Example:* Group Architecture Board | [@chair]; day-to-day: [@contract-architect] | Approves conformance, grants dispensations within the charter | [e-mail] |
| Delivery party | *Example:* [Supplier name] and internal data team | [@delivery-lead] | Commits design and build of the work package | [e-mail] |
| Business owner | *Example:* Head of Customer Operations | [@business-owner] | Owns the outcome and accepts residual risk | [e-mail] |
| Sponsor (informed) | *Example:* Chief Operating Officer | [@sponsor] | Resolves escalations at level 3 | [e-mail] |
| [Party] | [Organisation] | [@name] | [Authority] | [Contact] |

If the delivery party is a consortium or uses subcontractors, name the
party that is accountable for architecture conformance of all of them.

## 3. Scope of the contract

<!-- Guidance: Describe what is delivered, in architecture terms: which building blocks, capabilities and interfaces, and which Transition Architecture this work package helps reach. State what is out of scope just as clearly. Pitfall: a scope that drifts with the project plan while the contract stays unchanged. -->

### 3.1 In scope

| Scope item | Description | Roadmap link |
|---|---|---|
| SC-01 *(Example)* | Customer data hub: golden record store and stewardship user interface | WP-02, Transition Architecture 1 |
| SC-02 *(Example)* | Matching and survivorship service for three policy systems | WP-02 |
| SC-03 *(Example)* | Customer API on the enterprise API gateway | WP-02 |
| SC-04 *(Example)* | Customer-changed events on the enterprise event platform | WP-02 |
| SC-05 *(Example)* | Initial load and reconciliation of customer data from policy systems A, B and C | WP-02 |
| [SC-nn] | [Item] | [WP, Transition Architecture] |

### 3.2 Out of scope

*Example:* changes to the policy systems beyond their export interfaces;
the handler workspace (WP-04); retirement of the legacy CRM, which is a
separate work package with its own contract; reporting and analytics on
customer data.

### 3.3 Interfaces with other contracts

| Other contract | Shared element | Rule |
|---|---|---|
| AC-01 *(Example)* Cloud and integration foundation | API gateway and event platform | AC-01 provides the platform; AC-02 must use it as delivered and may not deploy its own |
| AC-04 *(Example)* Handler workspace | Customer API | AC-02 owns the API contract; changes need AC-04 consumer sign-off |
| [AC-nn] | [Element] | [Rule] |

## 4. Architecture baseline referenced

<!-- Guidance: List the approved documents, with exact versions, that define the architecture the party must follow, and the precedence when they disagree. Freeze the versions at signature; later versions apply only through a variation. Pitfall: referring to "the current standards", which lets the baseline change under the supplier. -->

| Ref | Document | Version / date | Location | Precedence |
|---|---|---|---|---|
| BL-01 *(Example)* | This Architecture Contract | Current version | [Repository path] | 1 |
| BL-02 *(Example)* | Architecture Requirements Specification | 1.0 (baseline B1) at signature; 1.1 from VAR-02 | `architecture/architecture-requirements-specification` | 2 |
| BL-03 *(Example)* | Architecture Definition Document, data and application parts | 1.0 | `architecture/architecture-definition-document` | 3 |
| BL-04 *(Example)* | Architecture Principles Catalogue | 2.3 | `architecture/architecture-principles` | 4 |
| BL-05 *(Example)* | Technology standards list (radar snapshot) | YYYY-MM-DD | `architecture/tech-radar` | 4 |
| BL-06 *(Example)* | Security architecture | 2.0 | `security/security-architecture` | 4 |
| BL-07 *(Example)* | Integration reference architecture | 1.4 | `architecture/reference-architecture` | 5 |
| [BL-nn] | [Document] | [Version] | [Location] | [Rank] |

The delivery party confirms it has received and read every baseline
document. Where a baseline item is ambiguous, the party raises a
clarification (section 11.1) before acting on its own interpretation.

## 5. Architecture requirements and standards

<!-- Guidance: List the requirements the party must meet, by ID from the Architecture Requirements Specification, plus the principles, standards and building blocks that are mandatory. Mark which are critical: a critical requirement that is not met blocks acceptance. Pitfall: copying the whole requirements specification; list only what applies to this scope. -->

### 5.1 Contracted architecture requirements

| Requirement ID | Requirement (short) | Scope item | Critical | Verification method |
|---|---|---|---|---|
| ARS-DAT-03 *(Example)* | Matching reaches at least 95% precision on a reviewed sample before a source is mastered by the hub | SC-02 | Y | Test on full volume, signed by the data owner |
| ARS-DAT-01 *(Example)* | One golden customer identifier used by all target applications; no local copies writable outside the hub | SC-01 | Y | Data model and access configuration review |
| ARS-DAT-04 *(Example)* | Consent and its history recorded for each customer and purpose | SC-01, SC-05 | Y | Test of consent changes, including migrated records |
| ARS-DAT-05 *(Example)* | Every data entity has a named owner and a retention period, with deletion rules for personal data | SC-01 | Y | Catalogue report, configuration export and deletion test |
| ARS-APP-01 *(Example)* | Functions exposed only through published APIs on the enterprise API gateway, with specifications in the registry | SC-03 | Y | Gateway configuration and specification registry |
| ARS-INT-01 *(Example)* | Customer-changed events on the enterprise event platform carry the golden customer ID and a schema version, in the agreed envelope | SC-04 | N | Event catalogue, contract tests and sample messages |
| ARS-DAT-02 *(Example)* | Customer data stored and processed only in EU regions of the approved landing zone | SC-01 to SC-05 | Y | Infrastructure as code and deployment records |
| ARS-SEC-01 *(Example)* | Staff and service identities authenticate through the enterprise identity provider, with multi-factor authentication for users | SC-01, SC-03 | Y | Identity configuration review |
| ARS-SEC-03 *(Example)* | Hub service has a documented exit plan and a recovery tested against its tier 2 targets | SC-01 to SC-03 | Y | Exit plan and recovery test report |
| ARS-TEC-03 *(Example)* | Logs, metrics and traces sent to central observability, sufficient to measure the agreed service level objectives | SC-01 to SC-03 | N | Observability catalogue, dashboard and SLO document |
| ARS-INT-04 *(Example, added by VAR-02)* | During the interim period, changes captured from policy system A are published as the same customer events as the target API would produce | SC-04, SC-05 | Y | Contract tests passed against both sources (ACR-2027-03 condition C2) |
| [ARS-xxx-nn] | [Requirement] | [SC-nn] | [Y / N] | [Method] |

### 5.2 Principles that apply

| Principle ID | Name | How it applies here |
|---|---|---|
| DP-01 *(Example)* | Data has one accountable owner and one master source | The hub is the only master for customer data |
| AP-01 *(Example)* | Integrate through published interfaces | No new file transfers or direct database links |
| TP-01 *(Example)* | Prefer managed services on approved platforms | Use platform-managed database and messaging |
| SP-01 *(Example)* | Secure by default, least privilege always | Role-based access to stewardship functions |
| [ID] | [Name] | [Application] |

### 5.3 Mandatory standards and building blocks

| Item | Type | Version or ring | Note |
|---|---|---|---|
| *Example:* API specification format | Standard | OpenAPI [version] as listed in BL-05 | Specifications published to the registry |
| *Example:* Event envelope | Standard | CloudEvents [version] as listed in BL-05 | Agreed attributes per the integration reference |
| *Example:* Group identity service | Building block | Production | No local user stores |
| *Example:* Enterprise event platform | Building block | Production, from AC-01 | No project-owned broker |
| *Example:* Central log and security monitoring | Building block | Production | All logs forwarded |
| [Item] | [Standard / Building block] | [Version] | [Note] |

### 5.4 Areas left to the delivery party

State what the party may decide alone, so governance does not creep into
design choices the architecture deliberately leaves open. *Example:*
internal module structure, programming language within the adopt ring,
test framework, user interface layout within the design system, and the
choice of matching algorithm, provided ARS-DAT-03 is met. Record such
decisions as decision records (`architecture/adr-full`) and share them at
the next checkpoint.

## 6. Deliverables and evidence

<!-- Guidance: List the architecture-relevant work products the party provides and when. These are what the compliance assessor reads; no deliverable, no conformance. Pitfall: asking for documents nobody will read; tie each deliverable to a checkpoint and a check. -->

| Deliverable ID | Deliverable | Content expected | Due at checkpoint | Format |
|---|---|---|---|---|
| DEL-01 *(Example)* | Solution design | Components, interfaces, deployment, NFR allocation, traced to ARS IDs | R2 Design | `architecture/high-level-design` |
| DEL-02 *(Example)* | Logical data model and data dictionary | Entities, owners, classification, retention | R2 Design | `architecture/data-dictionary` |
| DEL-03 *(Example)* | Interface specifications | API and event specifications in the registry | R2 Design | Specification files |
| DEL-04 *(Example)* | Threat model | Trust boundaries, threats, controls | R2 Design | `security/threat-model` |
| DEL-05 *(Example)* | Decision records | One per significant design decision | Each checkpoint | `architecture/adr-full` |
| DEL-06 *(Example)* | Test evidence | Matching accuracy, performance, recovery, deletion tests | R3 Pre-production | Test reports |
| DEL-07 *(Example)* | Operational readiness pack | Runbooks, monitoring, support model, SLOs | R3 Pre-production | `dev/service-readiness` |
| DEL-08 *(Example)* | As-built architecture | Realised models published to the repository | R4 Post-implementation | Repository models |
| [DEL-nn] | [Deliverable] | [Content] | [Rn] | [Format or template] |

The architecture function returns comments on each deliverable within
[5] working days of receipt. Silence after that period does not count as
acceptance.

## 7. Conformance and acceptance criteria

<!-- Guidance: Define what counts as conforming, how ratings are given and what must be true for the board to accept the work package at closure. Use the same rating scale as the compliance assessment so the two documents line up. Pitfall: acceptance criteria that measure delivery ("system live") rather than architecture conformance. -->

### 7.1 Conformance rule

Conformance is assessed at each checkpoint with the Architecture
Compliance Assessment, using its per-check rating scale (conformant,
conformant with conditions, partially conformant, non-conformant, not
evidenced, not applicable) and its roll-up rules. The board outcome
follows the board charter: compliant, compliant with conditions,
dispensation or non-compliant.

### 7.2 Acceptance criteria at closure

| ID | Criterion | Evidence |
|---|---|---|
| ACC-01 *(Example)* | Every critical requirement in section 5.1 is rated conformant | Pre-production and post-implementation assessments |
| ACC-02 *(Example)* | Every non-critical requirement is conformant or covered by a closed condition | Condition log |
| ACC-03 *(Example)* | No dispensation is active, or each active one has an owner, expiry and funded exit plan | Dispensation register |
| ACC-04 *(Example)* | As-built models are in the repository and match production | Repository check against deployment records |
| ACC-05 *(Example)* | Architecture debt incurred is recorded in the tech debt register with an owner | `architecture/tech-debt-register` |
| [ACC-nn] | [Criterion] | [Evidence] |

### 7.3 Consequences of non-conformance

*Example:* A non-compliant outcome at R2 stops build of the affected
scope items until a reworked design is assessed. A non-compliant outcome
at R3 prevents go-live. For a supplier, the consequences in the statement
of work apply (section 14). Neither party may treat a missed checkpoint
as an implied pass.

## 8. Checkpoints and review schedule

<!-- Guidance: Fix the review points at signature, with dates, the evidence due and who reviews. Align them with project stage gates so governance does not add separate waiting time. Pitfall: a single review just before go-live, when the only possible answers are "accept" or "expensive rework". -->

```mermaid
gantt
  title Checkpoints for AC-02 (Example)
  dateFormat YYYY-MM-DD
  section Design
  Design work            :d1, 2027-03-01, 6w
  R2 Design review       :milestone, r2, after d1, 0d
  section Build
  Build and test         :b1, after d1, 14w
  R3 Pre-production      :milestone, r3, after b1, 0d
  section Run
  Go-live and hypercare  :h1, after b1, 6w
  Steady operation       :o1, after h1, 20w
  R4 Post-implementation :milestone, r4, after o1, 0d
```

| Checkpoint | When | Evidence due | Assessed by | Tier |
|---|---|---|---|---|
| R1 Concept *(Example)* | Before funding of detailed design (completed, ARB-2027-004) | Options and fit with roadmap | Delegated architect | 2 |
| R2 Design *(Example)* | End of design, before build (2027-04-12; decided under ARB-2027-007) | DEL-01 to DEL-05 | Full board | 1 |
| R3 Pre-production *(Example)* | Before go-live (2027-07-19) | DEL-06, DEL-07, closure of R2 conditions | Full board | 1 |
| R4 Post-implementation *(Example)* | About 6 months after go-live (2028-01-17) | DEL-08, operational data | Delegated architect | 2 |
| [Rn] | [When] | [DEL-nn] | [Who] | [Tier] |

Ad hoc reviews may be called by either party when a material change
(section 11) or a serious incident affects the architecture.

## 9. Dispensations and permitted deviations

<!-- Guidance: Say which deviations are allowed in advance, which the board chair can grant alone on the contract architect's recommendation, and which need the full board or the executive, exactly as the board charter delegates them. Every dispensation is time-limited with an exit plan and is entered in the charter's register. Pitfall: open-ended permission ("deviations may be agreed as needed"), which empties the contract. -->

### 9.1 Pre-agreed deviations

| Deviation ID | Requirement or principle | Permitted deviation | Limit | Expiry |
|---|---|---|---|---|
| *Example:* None at signature | Not applicable | Not applicable | Not applicable | Not applicable |
| [DEV-nn] | [ID] | [Deviation] | [Limit] | YYYY-MM-DD |

### 9.2 Who may grant what

| Type of deviation | Decided by | Maximum term |
|---|---|---|
| Non-critical requirement, no security or personal data impact | Board chair alone, on the contract architect's recommendation, reported to the board | Up to [6] months |
| Critical requirement, any security or personal data impact, or a term over 6 months | Full Architecture Board; the security member must agree where security risk rises, and the data protection officer is consulted where personal data is affected | Up to [12] months, per the charter |
| Second renewal of any dispensation | Executive, on the board's recommendation | Per the charter |
| Change to scope, baseline version or checkpoint dates | Contract variation (section 11.2) | Not applicable |

### 9.3 Dispensations granted under this contract

| Dispensation ID | Requirement or principle | Reason | Granted | Expires | Exit plan | Status |
|---|---|---|---|---|---|---|
| DSP-2027-02 *(Example)* | AP-01 | Interim nightly batch export to the legacy CRM until its retirement; decided by the full board because the term exceeds 6 months and personal data is copied outside the hub; security member agreed, data protection officer consulted | 2027-04-19 | 2028-01-18 (9 months) | Delete the job when the CRM retires in WP-07; one renewal expected | Active |
| [DSP-YYYY-NN] | [ID] | [Reason] | YYYY-MM-DD | YYYY-MM-DD | [Plan] | [Active / Expired / Closed] |

## 10. Quality and fitness metrics

<!-- Guidance: Choose a few measures that show whether the delivered architecture stays fit, and agree how they are collected. Prefer automated fitness functions over manual reports. Pitfall: metrics nobody can measure until after the contract has closed. -->

| Metric ID | Measure | Target *(Example)* | Source | Frequency | Linked requirement |
|---|---|---|---|---|---|
| MET-01 *(Example)* | Share of customer records with one golden ID | At least 98% | Hub data quality dashboard | Weekly from go-live | ARS-DAT-01, ARS-DAT-03 |
| MET-02 *(Example)* | Interfaces not passing through the API gateway | 0 | Gateway inventory versus network flow logs | Each release | ARS-APP-01 |
| MET-03 *(Example)* | Resources holding customer data deployed outside the approved landing zone or EU regions | 0 | Cloud audit logs and policy compliance report | Monthly | ARS-DAT-02 |
| MET-04 *(Example)* | Personal data records past retention date | 0 | Retention job report | Monthly | ARS-DAT-05 |
| MET-05 *(Example)* | Customer API availability against SLO | At least 99.9% per month | Monitoring | Monthly | ARS-TEC-03 |
| [MET-nn] | [Measure] | [Target] | [Source] | [Frequency] | [ARS ID] |

Where possible, implement these as automated checks in the delivery
pipeline (`architecture/fitness-functions`) so conformance is visible
between checkpoints.

## 11. Change control and escalation

<!-- Guidance: Separate three things: clarifications (no change to the contract), variations (the contract changes) and disputes (parties disagree). Give each a route and a time limit. Pitfall: design changes agreed in a meeting and never written into the contract, which then cannot be enforced. -->

### 11.1 Clarifications

Either party may ask for a clarification of a baseline item. The
contract architect answers within [3] working days and records the answer
in the clarification log; a clarification that changes a requirement is
a variation instead.

| Clarification ID | Question | Answer | Date |
|---|---|---|---|
| CLR-01 *(Example)* | Does ARS-APP-01 cover internal batch reconciliation jobs? | Yes, if they read hub data from outside the hub's own runtime | YYYY-MM-DD |
| [CLR-nn] | [Question] | [Answer] | YYYY-MM-DD |

### 11.2 Variations

A variation changes the scope, baseline version, requirements,
checkpoints or term. The requesting party raises an architecture change
request (`architecture/architecture-change-request`); the board assesses
the impact and either approves a variation to this contract or directs
a new architecture cycle when the change is larger than this work
package. For a supplier, the commercial change procedure in the statement
of work runs in parallel (`project/change-control`).

| Variation ID | Change | Reason | Approved by | Date | Contract version |
|---|---|---|---|---|---|
| VAR-01 *(Example)* | Interim CRM batch export permitted under DSP-2027-02 | CRM has no API and is retired only in WP-07 | Architecture Board (ARB-2027-007) | 2027-04-19 | 1.1 |
| VAR-02 *(Example)* | ARS-INT-04 added for the interim policy system A feed; baseline moved to ARS 1.1 | Change request ACR-2027-03 | Architecture Board (ARB-2027-011) | 2027-06-07 | 1.2 |
| [VAR-nn] | [Change] | [Reason] | [Approver] | YYYY-MM-DD | [x.y] |

### 11.3 Escalation

| Level | Who | Trigger | Time limit |
|---|---|---|---|
| 1 | Contract architect and delivery lead | Disagreement on a rating, finding or clarification | [5] working days |
| 2 | Architecture Board | Level 1 unresolved, or a request to overturn an outcome | Next board meeting |
| 3 | Sponsor | Board cannot decide, or business impact above [threshold] | [10] working days |

Escalation follows the board charter. Work continues during escalation
unless the dispute concerns a critical requirement, in which case the
affected scope item pauses until level 2 decides.

## 12. Roles and responsibilities

<!-- Guidance: Show who does what across the contract life, so nothing falls between the architecture function and the delivery party. Use one accountable role per activity. Pitfall: the architecture function becoming responsible for the supplier's design work. -->

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

| Activity | Contract architect | Architecture Board | Delivery lead | Business owner | Security architect |
|---|---|---|---|---|---|
| Draft and maintain the contract | R | A | C | C | C |
| Provide deliverables and evidence | I | I | A, R | I | C |
| Assess conformance at checkpoints | R | A | C | I | R (security checks) |
| Recommend and grant dispensations within the charter | R (recommends) | A (chair or board decides) | C | C (risk acceptance) | C |
| Approve variations | C | A | C | C | C |
| Track metrics and conditions | R | I | R | I | C |
| Accept residual architecture risk | C | C | I | A | C |
| Close the contract | R | A | C | C | I |

For organisation-wide decision rights, see the RACI template
(`business/raci`).

## 13. Risks, assumptions and dependencies

<!-- Guidance: Record only what affects architecture conformance; project delivery risks stay in the project RAID log. Pitfall: listing assumptions with no owner or date by which they will be checked. -->

| ID | Type | Description | Owner | Validate by or mitigation | Status |
|---|---|---|---|---|---|
| RSK-01 *(Example)* | Risk | Policy system C data quality too poor to meet ARS-DAT-03 | [@data-owner] | Profiling before R2; cleansing budget held in reserve | Open |
| RSK-02 *(Example)* | Risk | Supplier product release changes its integration model | [@contract-architect] | Product roadmap review at each checkpoint | Open |
| ASM-01 *(Example)* | Assumption | API gateway and event platform from AC-01 are in production before build starts | [@platform-lead] | YYYY-MM-DD | Open |
| DEP-01 *(Example)* | Dependency | Legacy CRM retirement date agreed by its owner | [@crm-owner] | YYYY-MM-DD; needed to set DSP-2027-02 exit | Open |
| [ID] | [Risk / Assumption / Dependency] | [Description] | [@owner] | [Date or mitigation] | [Status] |

Carry project-level items into the RAID log (`project/raid-log`).

## 14. Supplier provisions

<!-- Guidance: Complete this section only when the delivery party is external. It lists what the commercial agreement should cover so architecture obligations are enforceable; legal and procurement decide the actual wording. Delete the section for internal teams. Pitfall: architecture obligations that exist only in this document and are not referenced by the signed commercial agreement. -->

| Topic | What to agree | Where it lives |
|---|---|---|
| Incorporation | The commercial agreement references this contract and its version, or attaches it | Statement of work, [clause] |
| Evidence and audit rights | Access to designs, configuration, test results and environments for assessment | [Clause] |
| Remedies | What happens on a non-compliant outcome: rework at whose cost, withheld acceptance, service credits | [Clause] |
| Intellectual property | Ownership of models, specifications and decision records produced | [Clause] |
| Subcontractors | Flow-down of architecture obligations | [Clause] |
| Security and privacy | Supplier security assessment and data processing terms | `compliance/supplier-security-assessment`, [DPA reference] |
| Exit and handover | Transfer of as-built documentation, code and configuration at the end | [Clause] |

This section is a checklist for the people who draft commercial terms,
not a substitute for them. This is a documentation format, not legal
advice.

## 15. Duration, termination and closure

<!-- Guidance: State when the contract starts and ends, what ends it early, and what has to be true to close it. Closure is a governance act with evidence, not the project end date. Pitfall: contracts left "active" for years after go-live, so nobody knows whether the obligations still apply. -->

```mermaid
stateDiagram-v2
  [*] --> Draft
  Draft --> Signed: all parties sign
  Signed --> Active: effective date
  Active --> Varied: variation approved
  Varied --> Active: new version in force
  Active --> Closed: acceptance criteria met at R4
  Active --> Terminated: scope cancelled or party replaced
  Closed --> [*]
  Terminated --> [*]
```

| Item | Rule |
|---|---|
| Start | *Example:* On signature by all parties in section 16 |
| Normal end | *Example:* When the board confirms ACC-01 to ACC-05 at checkpoint R4 |
| Early termination | *Example:* Work package cancelled by the portfolio board; delivery party replaced; the board decides a new architecture cycle supersedes this scope |
| Obligations that survive | *Example:* Active dispensations and their exit plans transfer to the service owner; recorded debt remains in the register |
| Closure record | Board outcome record ID, date, and links to the final assessment and post-implementation review (`project/post-implementation-review`) |

After closure, the operating service is reviewed through the periodic
architecture health check (`architecture/architecture-health-check`).

## 16. Signatures

<!-- Guidance: Sign with people who hold the authority named in section 2. Record the version signed. Electronic approval in a workflow tool is fine if it records identity, date and version. -->

| Party | Name | Role | Version signed | Signature | Date |
|---|---|---|---|---|---|
| Architecture function | [@chair] | Architecture Board chair | [1.0] | [Signature or approval record] | YYYY-MM-DD |
| Delivery party | [@delivery-lead] | [Delivery lead, supplier representative] | [1.0] | [Signature] | YYYY-MM-DD |
| Business owner | [@business-owner] | [Role] | [1.0] | [Signature] | YYYY-MM-DD |
| Contract architect (witness) | [@contract-architect] | Architect | [1.0] | [Signature] | YYYY-MM-DD |

## 17. Glossary and references

<!-- Guidance: Define the governance terms a delivery party may not know and list the documents this contract depends on. -->

### 17.1 Glossary

| Term | Meaning in this document |
|---|---|
| Architecture Contract | The agreement between the architecture function and a delivery party on what is built, which architecture applies and how conformance is checked |
| Architecture function | The board and architects who govern conformance for the organisation |
| Delivery party | The internal team or supplier that designs and builds the work package |
| Baseline (contract) | The approved documents and versions frozen at signature that the delivery must follow |
| Checkpoint | A scheduled review at which conformance is assessed |
| Clarification | An interpretation of a baseline item that does not change the contract |
| Variation | A formal change to the contract that creates a new version |
| Dispensation | A time-limited, risk-accepted permission to depart from a requirement or principle |
| Fitness function | An automated measure that shows whether an architecture characteristic still holds |
| [Term] | [Meaning] |

### 17.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 Compliance Assessment (`architecture/architecture-compliance-assessment`) | [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 | Statement of Architecture Work (`architecture/statement-of-architecture-work`) | [x.y] |
| REF-07 | Statement of work with the supplier (`business/statement-of-work`) | [x.y] |
| REF-08 | Architecture Change Request (`architecture/architecture-change-request`) | [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: the Architecture Contract issued in Phase G
(Implementation Governance) of the Architecture Development Method, with
the Architecture Board, compliance review and Phase H (Architecture Change
Management). TOGAF and ArchiMate are registered trademarks of The Open
Group. This template uses only the names of phases and deliverables; all
text is original, including the clauses, rating references, delegation
limits, metrics and supplier checklist, and no definitions, tables or
other text from the standard are reproduced. This is a documentation
format, not legal advice. Check the current edition at opengroup.org and
obtain the standard for its full guidance. Template licence: MIT.