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.
Document control
| 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
| 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
| 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
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
| 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
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
| 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
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
| 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
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
| 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
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
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
| 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
| 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
| 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
| 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
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.