# UAF Architecture Description: [Enterprise, mission or system of systems name]

> Architecture description organised by the OMG Unified Architecture Framework (UAF) version 1.3
> grid: Architecture Management, Summary and Overview, Strategic, Operational, Services, Personnel,
> Resources, Security, Projects, Standards and Actual Resources viewpoints, read across the aspects
> (Motivation, Taxonomy, Structure, Connectivity, Processes, States, Sequences, Information,
> Parameters, Constraints, Roadmap, Traceability). It records stakeholders and concerns, the grid
> cells selected, the content of each viewpoint, cross-cutting requirements, information,
> measures and risks, traceability and correspondence rules, the mapping to DoDAF 2.02 and NAF v4,
> and model management. Conformance is claimed against ISO/IEC/IEEE 42010:2022. Replace every
> `[bracketed]` value and every row marked *Example*; the worked example is a regional wildfire
> response system of systems.

<!--
Guidance: How to use this template
- This document is the readable front end of a UAF model, not a replacement for it. Keep the
  model (UAFML in a SysML 1.6 tool) as the source of truth and use this file for the summary,
  the decisions about which grid cells to use, and the views that reviewers sign off.
- Select cells, do not fill the whole grid. Section 4 lists the stakeholders and their concerns;
  every selected cell must answer at least one concern and every concern must be answered by at
  least one cell. Empty or decorative views are the most common failure of framework-based work.
- Work top down: Strategic (capabilities) before Operational (logical, solution independent)
  before Services and Resources (solution). Projects and Roadmap cells show how the solution
  arrives over time.
- Use view specification names as the UAF publishes them, and refer to the official traceability
  appendix for the normative mapping to other frameworks.
- Related: Architecture Description (ISO/IEC/IEEE 42010) (`architecture/architecture-description-42010`),
  Concept of Operations (`requirements/conops`), System Requirements Specification
  (`requirements/system-requirements`), Interface Control Document
  (`architecture/interface-control-document`), Business Capability Map
  (`architecture/business-capability-map`), Architecture Roadmap and Transition Plan
  (`architecture/architecture-roadmap-transition`).
-->

## Document control

<!-- Guidance: Identify the architecture, its model and the framework version. A new UAF version, a change of scope or a new architecture phase (as-is, to-be, transition) is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [UAF-AD-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@chief-architect] |
| Approvers/reviewers | [@capability-owner], [@systems-engineer], [@security-accreditor], [@programme-manager] |
| Last updated | YYYY-MM-DD |
| Classification | [Official / Internal / Restricted] |
| Architecture name and identifier | [Name], [ARCH-ID] |
| Architecture type | [Enterprise / Capability / Solution / System of systems] |
| Time frame | [As-is YYYY / To-be YYYY / Transition steps] |
| Framework and version | OMG UAF 1.3 (DMM formal/25-10-01, UAFML formal/25-10-03) |
| Modelling tool and model location | [Tool and version], [repository path or model server URL] |
| Conformance claimed | ISO/IEC/IEEE 42010:2022 architecture description |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Architecture owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Capability owner | [@name] | [Decision] | YYYY-MM-DD |
| Security accreditor | [@name] | [Decision] | YYYY-MM-DD |
| Programme manager | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft: scope, stakeholders, selected grid cells |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved to-be architecture for increment 1 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added Security Constraints and Parameters: Risk views after accreditation review |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose, scope and conformance](#1-purpose-scope-and-conformance)
2. [Architecture management](#2-architecture-management)
3. [Summary and overview](#3-summary-and-overview)
4. [Stakeholders, concerns and grid selection](#4-stakeholders-concerns-and-grid-selection)
5. [Strategic viewpoint](#5-strategic-viewpoint)
6. [Operational viewpoint](#6-operational-viewpoint)
7. [Services viewpoint](#7-services-viewpoint)
8. [Personnel viewpoint](#8-personnel-viewpoint)
9. [Resources viewpoint](#9-resources-viewpoint)
10. [Security viewpoint](#10-security-viewpoint)
11. [Projects viewpoint](#11-projects-viewpoint)
12. [Standards viewpoint](#12-standards-viewpoint)
13. [Actual resources viewpoint](#13-actual-resources-viewpoint)
14. [Requirements, information and parameters](#14-requirements-information-and-parameters)
15. [Traceability and correspondence rules](#15-traceability-and-correspondence-rules)
16. [Mapping to other frameworks](#16-mapping-to-other-frameworks)
17. [Model management and tool conformance](#17-model-management-and-tool-conformance)
18. [Issues, decisions and review record](#18-issues-decisions-and-review-record)
19. [Glossary and references](#19-glossary-and-references)

## 1. Purpose, scope and conformance

<!-- Guidance: Say what decision this architecture supports and how it conforms. Questions: who commissioned it, which phase of the life cycle does it serve, what is the boundary of the system of interest? Pitfall: an architecture that describes everything and informs no decision. -->

### 1.1 Purpose

[State the decision or activity this description supports.] *Example:* This architecture
description supports the investment decision for a regional wildfire response capability that
joins fire services, the forestry agency, emergency medical services and two municipalities into
one system of systems. It defines the target capability for 2029, the operational concept, the
services and resources needed, the security posture and the three projects that deliver it.

### 1.2 Scope and boundary

| Item | Value |
|---|---|
| Enterprise or system of interest | *Example:* Regional Wildfire Response (RWR) system of systems |
| Participating organisations | *Example:* Regional fire service, forestry agency, ambulance trust, two municipalities, national weather service (external) |
| In scope | *Example:* Detection, alerting, incident command, resource dispatch, public warning, after-action review |
| Out of scope | *Example:* Long-term forest management; aircraft maintenance |
| Architecture states described | *Example:* As-is 2026, to-be 2029, transition steps 2027 and 2028 |
| Level of detail | *Example:* Capability and logical levels complete; resource level for new systems only |

### 1.3 Conformance

UAF states that it conforms to the architecture description terms of ISO/IEC/IEEE 42010, citing
the 2011 edition. This description claims conformance to the 2022 edition, which uses the same core
ideas (stakeholders, concerns, viewpoints, views, model kinds, correspondences) with an updated
vocabulary. Record how each 42010 element is satisfied here.

| ISO/IEC/IEEE 42010:2022 element | Where satisfied in this document |
|---|---|
| Identification of the entity of interest and its environment | Section 1.2 |
| Stakeholders and their concerns | Section 4.1 |
| Architecture viewpoints used, with the concerns they frame | Section 4.2 (UAF grid selection) |
| Architecture views and models | Sections 5 to 14 and the referenced model |
| Correspondences and correspondence rules | Section 15 |
| Architecture decisions and rationale | Section 18 |
| Known issues and inconsistencies | Section 18 |

The companion Architecture Description (ISO/IEC/IEEE 42010) template
(`architecture/architecture-description-42010`) gives the generic structure; this template
specialises it for UAF.

## 2. Architecture management

<!-- Guidance: The Architecture Management viewpoint holds information about the architecture itself rather than about the enterprise. Questions: which principles guide it, which views does it contain, how is it developed, what is its status? Pitfall: skipping this viewpoint, so nobody can tell which version of the model a view came from. -->

UAF 1.3 places metadata about the architecture in the Architecture Management viewpoint (prefix
Am). Record the content of the cells you use.

| Grid cell | View specification | Content in this architecture |
|---|---|---|
| Am-Mv | Architecture Principles | *Example:* AP-01 Capability before solution; AP-02 Reuse national services first; AP-03 Every exchange is secured at the classification of its most sensitive element |
| Am-Sr | Architecture Views | The selected grid cells and their stakeholders (section 4.2) |
| Am-Cn | Architecture References | *Example:* References to the national emergency services architecture and the forestry agency's IT architecture |
| Am-Pr | Architecture Development Method | *Example:* Iterative: capability baseline, operational concept workshop, solution options, review, increment planning |
| Am-St | Architecture Status | *Example:* Strategic and Operational views approved; Resources views in review |
| Am-If | Dictionary | Section 19.1 and the model dictionary |
| Am-Pm | Architecture Parameters | *Example:* Measures used to compare options: time to alert, coverage, cost |
| Am-Ct | Architecture Constraints | *Example:* Must reuse the national emergency radio network; no new classified enclave |
| Am-Rm | Architecture Roadmap | *Example:* Releases of this architecture: v1.0 investment decision, v2.0 design authority baseline |
| Am-Tr | Architecture Traceability | *Example:* Links from this description to the investment case and the CONOPS |

## 3. Summary and overview

<!-- Guidance: Write the executive summary that UAF expects in the Summary and Overview view: what the architecture is for, the main findings, and the assumptions, constraints and limits that affect decisions. Write it last, keep it to a page. Pitfall: a summary that lists views instead of findings. -->

| Item | Content |
|---|---|
| Purpose and decision | *Example:* Approve investment of [amount] for RWR increment 1 |
| Key findings | *Example:* Detection-to-alert time is limited by manual hand-offs between three control rooms, not by sensors; a shared common operating picture service removes two hand-offs |
| Recommended option | *Example:* Option B: shared incident data service on the regional cloud, integrated with existing dispatch systems |
| Assumptions | *Example:* The national weather service keeps providing fire weather indices through its public interface |
| Constraints | *Example:* Existing radio network retained until 2031 |
| Limitations of this description | *Example:* Actual Resources analysed for the summer peak only |
| Analysis performed | *Example:* Coverage simulation, cost comparison of three options, security risk assessment |

## 4. Stakeholders, concerns and grid selection

<!-- Guidance: Select grid cells from concerns, not from habit. Questions: who will use this architecture and for what? Which concern does each cell answer? Pitfall: copying a standard set of views from a previous project. -->

### 4.1 Stakeholders and concerns

| ID | Stakeholder | Concern | Answered by cells |
|---|---|---|---|
| CON-01 *(Example)* | Regional fire chief (capability owner) | Which capabilities are needed by 2029 and in what order? | St-Tx, St-Rm, Pj-Rm |
| CON-02 *(Example)* | Incident commanders | How will incidents be run across agencies? | Op-Sr, Op-Pr, Op-Sq, Ps-Sr |
| CON-03 *(Example)* | Systems engineers | Which systems and interfaces are new or changed? | Rs-Sr, Rs-Cn, Sv-Cn |
| CON-04 *(Example)* | Security accreditor | What information is exchanged at which classification and how is it protected? | Sc-Tx, Sc-Cn, Sc-Ct, Sc-Mv |
| CON-05 *(Example)* | Programme manager | Which projects deliver what, with which dependencies? | Pj-Sr, Pj-Cn, Pj-Rm |
| CON-06 *(Example)* | Finance board | What does each option cost and what does it achieve? | Am-Pm, Ar-Sr, Parameters (section 14.3) |
| [CON-NN] | [Stakeholder] | [Concern] | [Cells] |

### 4.2 Grid selection

Rows are viewpoints, columns are aspects. Mark each cell **S** (selected), **R** (referenced from
another architecture) or leave it blank. Abbreviations follow the UAF acronyms.

| Viewpoint | Mv | Tx | Sr | Cn | Pr | St | Sq | If | Pm | Ct | Rm | Tr |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Architecture Management (Am) | S | | S | S | S | S | | S | S | S | S | S |
| Strategic (St) | S | S | S | S | | | | | | S | S | S |
| Operational (Op) | | S | S | S | S | S | S | S | | S | | S |
| Services (Sv) | | S | S | S | S | | | | | S | S | S |
| Personnel (Ps) | | S | S | S | | | | | | S | | S |
| Resources (Rs) | | S | S | S | S | | S | S | | S | S | S |
| Security (Sc) | S | S | S | S | | | | | | S | | S |
| Projects (Pj) | | S | S | S | | | | | | | S | S |
| Standards (Sd) | | S | S | | | | | | | | S | S |
| Actual Resources (Ar) | | | S | S | | | | | | | | S |

*Example* selection shown. Cells exist in the published grid only where UAF defines a view
specification; check the grid in the DMM before selecting a cell. Requirements (Motivation),
Information and Parameters content that spans viewpoints is summarised in section 14.

## 5. Strategic viewpoint

<!-- Guidance: Describe capabilities, not systems. Questions: what must the enterprise be able to do, how do capabilities break down and depend on each other, how do they evolve, what measures define them? Pitfall: naming capabilities after products ("Use System X"). -->

### 5.1 Strategic Motivation and Taxonomy

| ID | Capability | Definition (outcome, solution independent) | Parent | Measure |
|---|---|---|---|---|
| CAP-01 *(Example)* | Detect wildfire | Identify a new fire and its location | None | Time from ignition to confirmed detection |
| CAP-01.1 *(Example)* | Remote sensing detection | Detect fires from sensors and imagery | CAP-01 | Area covered, false alarm rate |
| CAP-02 *(Example)* | Alert and warn | Inform responders and the public of a confirmed fire | None | Time from detection to first responder alert |
| CAP-03 *(Example)* | Command multi-agency incident | Coordinate all agencies on one incident picture | None | Number of manual hand-offs |
| CAP-04 *(Example)* | Dispatch resources | Assign and track crews, vehicles and aircraft | CAP-03 | Time to dispatch |
| CAP-05 *(Example)* | Learn after action | Capture data and lessons from each incident | None | Share of incidents with completed review |
| [CAP-NN] | [Capability] | [Definition] | [Parent] | [Measure] |

Record challenges and opportunities that motivate the change in the Strategic Motivation view, for
example the rise in fire season length reported by the regional climate assessment.

### 5.2 Strategic Structure, Connectivity and Constraints

Show capability composition and dependencies. *Example:* CAP-03 depends on CAP-02 for alerts and
on CAP-04 for resource status; CAP-05 depends on data retained by CAP-03.

```mermaid
flowchart LR
  CAP01[CAP-01 Detect wildfire] --> CAP02[CAP-02 Alert and warn]
  CAP02 --> CAP03[CAP-03 Command multi-agency incident]
  CAP04[CAP-04 Dispatch resources] --> CAP03
  CAP03 --> CAP05[CAP-05 Learn after action]
```

| Constraint ID | Capability | Constraint | Source |
|---|---|---|---|
| ST-CT-01 *(Example)* | CAP-02 | First responder alert within 5 minutes of confirmed detection | Regional emergency plan |
| [ST-CT-NN] | [Capability] | [Constraint] | [Source] |

### 5.3 Strategic Roadmap: Deployment and Phasing

| Capability | 2026 as-is | 2027 | 2028 | 2029 to-be | Delivered by |
|---|---|---|---|---|---|
| CAP-01.1 *(Example)* | Lookout towers and public calls | Pilot camera network | Camera network region-wide | Camera and satellite fusion | PRJ-01 |
| CAP-03 *(Example)* | Three separate control rooms | Shared incident data service in build | Shared incident data service live (fire season 2028-05); joint command procedures | Single common operating picture | PRJ-02 |
| [CAP-NN] | [State] | [State] | [State] | [State] | [Project] |

Strategic Traceability links each capability to the operational activities that exhibit it
(section 15).

## 6. Operational viewpoint

<!-- Guidance: Describe the logical architecture: who does what and exchanges what, independent of any system. Questions: which operational performers exist, which activities do they carry out, what information flows between them, which scenarios matter most? Pitfall: drawing systems in operational views, which fixes the solution before options are compared. -->

### 6.1 Operational Taxonomy and Structure

| ID | Operational performer | Role in the concept | Capabilities exhibited |
|---|---|---|---|
| OP-01 *(Example)* | Detection cell | Receives and confirms fire reports | CAP-01 |
| OP-02 *(Example)* | Joint incident command | Leads the response to a confirmed incident | CAP-03 |
| OP-03 *(Example)* | Resource dispatch | Assigns crews and assets | CAP-04 |
| OP-04 *(Example)* | Public warning authority | Issues warnings to the public | CAP-02 |
| OP-05 *(Example)* | Field crew | Fights fire and reports status | CAP-03, CAP-04 |
| [OP-NN] | [Performer] | [Role] | [Capabilities] |

### 6.2 Operational Connectivity

| Exchange ID | From | To | Information | Trigger | Timeliness |
|---|---|---|---|---|---|
| OX-01 *(Example)* | OP-01 | OP-02 | Confirmed fire location and size | Detection confirmed | Within 2 minutes |
| OX-02 *(Example)* | OP-02 | OP-04 | Warning area and message | Command decision | Within 5 minutes |
| OX-03 *(Example)* | OP-05 | OP-02 | Crew position and fire line status | Every 10 minutes and on change | Near real time |
| [OX-NN] | [From] | [To] | [Information] | [Trigger] | [Timeliness] |

### 6.3 Operational Processes, States and Sequences

Describe the main operational activities, the states of a key element and one or two time-ordered
scenarios. The CONOPS (`requirements/conops`) holds the narrative; this section holds the model.

```mermaid
sequenceDiagram
  participant D as OP-01 Detection cell
  participant C as OP-02 Joint incident command
  participant R as OP-03 Resource dispatch
  participant W as OP-04 Public warning
  D->>C: OX-01 Confirmed fire location
  C->>R: Request initial attack resources
  R-->>C: Resources assigned
  C->>W: OX-02 Warning area and message
  W-->>C: Warning issued
```

```mermaid
stateDiagram-v2
  [*] --> Reported
  Reported --> Confirmed: verification
  Reported --> Closed: false alarm
  Confirmed --> Active: resources dispatched
  Active --> Contained: fire line holds
  Contained --> Closed: after-action review opened
```

### 6.4 Operational Information and Constraints

| ID | Information element | Description | Classification | Constraint |
|---|---|---|---|---|
| OI-01 *(Example)* | Incident record | Location, perimeter, status, assigned resources | Official | Retained 7 years for inquiries |
| OI-02 *(Example)* | Casualty information | Persons injured or missing | Personal, sensitive | Shared with ambulance service only |
| [OI-NN] | [Element] | [Description] | [Classification] | [Constraint] |

## 7. Services viewpoint

<!-- Guidance: Specify the services the operational concept needs, as contracts between consumers and providers, still without choosing products. Pitfall: services that mirror one existing system's API instead of an operational need. -->

| ID | Service | Consumers | Provider (to be decided in Resources) | Supports activities | Policy and level |
|---|---|---|---|---|---|
| SV-01 *(Example)* | Incident data service | OP-02, OP-03, OP-04 | Shared regional service | Command, dispatch, warning | 99.9 percent during fire season |
| SV-02 *(Example)* | Sensor alert service | OP-01 | Camera network operator | Detection | Alert within 60 seconds of image analysis |
| SV-03 *(Example)* | Public warning service | OP-04 | National warning platform | Public warning | Message delivered to area within 3 minutes |
| [SV-NN] | [Service] | [Consumers] | [Provider] | [Activities] | [Level] |

Services Connectivity, Processes and States show how services interact and behave; Services
Roadmap shows when each service version becomes available. Interfaces at resource level go into
the Interface Control Document (`architecture/interface-control-document`).

## 8. Personnel viewpoint

<!-- Guidance: Describe the organisational resources: posts, roles, organisations, competences and how they change over time. Questions: who staffs each operational performer, with which competences, and is the staffing available? Pitfall: ignoring people in a technology-led programme, so the new system has no trained operators. -->

| ID | Post or role | Organisation | Fills performer | Competences required | Number in 2029 *(Example)* |
|---|---|---|---|---|---|
| PS-01 *(Example)* | Joint incident commander | Fire service | OP-02 | Multi-agency command, common operating picture use | 12 |
| PS-02 *(Example)* | Detection analyst | Forestry agency | OP-01 | Imagery interpretation | 8 |
| PS-03 *(Example)* | Warning officer | Municipalities | OP-04 | Warning procedures | 6 |
| [PS-NN] | [Post] | [Organisation] | [Performer] | [Competences] | [Number] |

Use Personnel Connectivity for command and reporting lines, Personnel Sequences for hand-overs,
Personnel Constraints for rules such as shift length, and Personnel Roadmap for recruitment and
training over time.

## 9. Resources viewpoint

<!-- Guidance: Describe the solution: systems, software, capability configurations and natural resources that perform the operational activities and provide the services. Questions: which resources exist, which are new, how do they connect, what do they do? Pitfall: detailing internal design here; leave that to SysML block and activity models or the system specification. -->

| ID | Resource | Type | New or existing | Implements | Owner |
|---|---|---|---|---|---|
| RS-01 *(Example)* | Camera detection network | Capability configuration | New | SV-02 | Forestry agency |
| RS-02 *(Example)* | Shared incident data platform | Software system | New | SV-01 | Regional IT shared service |
| RS-03 *(Example)* | Fire service dispatch system | Software system | Existing, changed | Part of SV-01 consumers | Fire service |
| RS-04 *(Example)* | Emergency radio network | Communications system | Existing | Voice exchanges | National operator |
| [RS-NN] | [Resource] | [Type] | [New / Existing] | [Service or function] | [Owner] |

| Resource exchange | From | To | Realises operational exchange | Protocol or medium |
|---|---|---|---|---|
| RX-01 *(Example)* | RS-01 | RS-02 | OX-01 | Event message over secured interface |
| RX-02 *(Example)* | RS-02 | RS-03 | Dispatch request | Integration interface |
| [RX-NN] | [From] | [To] | [OX-NN] | [Medium] |

Resources Processes, States and Sequences describe functions and behaviour; Resources Roadmap
records versions and retirements; Resources Information gives the logical data model.
Detailed requirements go into the System Requirements Specification
(`requirements/system-requirements`).

## 10. Security viewpoint

<!-- Guidance: Identify security assets, their owners, the enclaves where they sit and the controls that protect them. Questions: which information and resources need protection, at which classification, across which boundaries? Pitfall: treating security as a single "secure" label on every exchange. -->

| ID | Security asset | Owner | Enclave | Classification | Controls applied (Security Controls view) |
|---|---|---|---|---|---|
| SC-01 *(Example)* | Incident record (OI-01) | Fire service | Regional shared enclave | Official | Access by role, encryption in transit and at rest, audit |
| SC-02 *(Example)* | Casualty information (OI-02) | Ambulance trust | Health enclave | Personal, sensitive | Separate store, need-to-know access, data protection impact assessment |
| SC-03 *(Example)* | Camera feeds | Forestry agency | Sensor enclave | Official | One-way transfer to shared enclave |
| [SC-NN] | [Asset] | [Owner] | [Enclave] | [Classification] | [Controls] |

Security Connectivity shows exchanges that cross enclave boundaries; Security Constraints records
policy, law and guidance; Security Processes shows security activities such as access approval.
Reference the control catalogue you use (for example ISO/IEC 27001 Annex A or NIST SP 800-53) by
control identifier and keep the accreditation evidence in the security case.

## 11. Projects viewpoint

<!-- Guidance: Show the projects that deliver the architecture, their milestones and dependencies, and which capability increments they deliver. Pitfall: a project roadmap that does not trace to capabilities, so nobody can see what is lost if a project slips. -->

| ID | Project | Delivers | Start | Key milestone | Depends on |
|---|---|---|---|---|---|
| PRJ-01 *(Example)* | Camera detection network | RS-01, CAP-01.1 increment | 2027-01 | Region-wide coverage 2028-06 | None |
| PRJ-02 *(Example)* | Shared incident data platform | RS-02, SV-01, CAP-03 increment | 2027-03 | Live for fire season 2028-05 | PRJ-03 interface changes |
| PRJ-03 *(Example)* | Dispatch system integration | RS-03 change | 2027-06 | Integration accepted 2028-03 | None |
| [PRJ-NN] | [Project] | [Deliverables] | [Start] | [Milestone] | [Dependencies] |

```mermaid
gantt
  title Projects Roadmap (Example)
  dateFormat YYYY-MM
  section Detection
  PRJ-01 Camera network :p1, 2027-01, 2028-06
  section Command
  PRJ-03 Dispatch integration :p3, 2027-06, 2028-03
  PRJ-02 Incident data platform :p2, 2027-03, 2028-05
```

Link this to the Architecture Roadmap and Transition Plan
(`architecture/architecture-roadmap-transition`) for the programme view.

## 12. Standards viewpoint

<!-- Guidance: List the technical and non-technical standards that constrain the architecture and when they change. Pitfall: listing every standard the organisation has, instead of those that bind this architecture. -->

| ID | Standard or protocol | Version | Applies to | Status over time |
|---|---|---|---|---|
| SD-01 *(Example)* | Common Alerting Protocol (OASIS) | [Version] | SV-03 public warning messages | Mandated |
| SD-02 *(Example)* | Emergency services data exchange standard | [Version] | RX-02 | Current; next version expected [year] |
| SD-03 *(Example)* | Regional cloud security baseline | [Version] | RS-02 | Mandated |
| [SD-NN] | [Standard] | [Version] | [Element] | [Status] |

Standards Roadmap records when standards are adopted, mandated, or retired.

## 13. Actual resources viewpoint

<!-- Guidance: Describe actual (instance-level) configurations to analyse options, what-if cases and verification results. Questions: which configurations were compared, under which scenario, with what result? Pitfall: claiming option results without recording the configuration and scenario they came from. -->

| Configuration | Description | Scenario | Measure | Result *(Example)* |
|---|---|---|---|---|
| AR-01 Option A *(Example)* | Existing three control rooms, cameras added | Peak day with 5 simultaneous fires | Confirmed detection to first responder alert, 95th percentile | 14 minutes |
| AR-02 Option B *(Example)* | Shared incident data platform plus cameras | Same | Same | 4.5 minutes |
| AR-03 Option C *(Example)* | Single merged control room | Same | Same | 4 minutes, with high organisational cost |
| [AR-NN] | [Configuration] | [Scenario] | [Measure] | [Result] |

Actual Resources Connectivity shows the actual links in each configuration; Actual Resources
Traceability links actual resources to the resource types in section 9.

## 14. Requirements, information and parameters

<!-- Guidance: Bring together content that UAF treats as cross-cutting: requirements (Motivation), information models and parameters (environment, measurements, mission vignettes and scenarios, risk). Pitfall: storing requirements only in a separate tool with no link to model elements. -->

### 14.1 Requirements

| ID | Requirement | Type | Traces to | Verification |
|---|---|---|---|---|
| REQ-01 *(Example)* | Alert first responders within 5 minutes of confirmed detection in 95 percent of incidents | Operational | CAP-02, OX-02, ST-CT-01 | Exercise and simulation AR-02 |
| REQ-02 *(Example)* | Incident data service available 99.9 percent from 1 May to 30 September | Service | SV-01, RS-02 | Monitoring during first season |
| [REQ-NN] | [Requirement] | [Type] | [Elements] | [Method] |

### 14.2 Information

Summarise the conceptual or logical information model (Operational Information and Resources
Information views) and link to the Data Dictionary (`architecture/data-dictionary`) where one
exists.

### 14.3 Parameters

| Parameter type | Content in this architecture |
|---|---|
| Environment | *Example:* Fire season conditions: temperature above 30 C, wind above 40 km/h, low connectivity in valleys |
| Measurements | *Example:* Detection time, alert time, coverage percentage, cost per year |
| Mission vignette and scenario | *Example:* V-01 Five simultaneous fires on a red flag day; V-02 Fire crossing municipal boundary at night |
| Risk | *Example:* RSK-01 Camera network coverage gaps in valleys; RSK-02 Dispatch vendor delays interface changes |

## 15. Traceability and correspondence rules

<!-- Guidance: State the rules that keep views consistent and the traceability you check. Questions: which elements must trace to which, and how is completeness checked? Pitfall: traceability created once and never maintained. -->

| Rule ID | Correspondence rule | Check |
|---|---|---|
| CR-01 *(Example)* | Every capability is exhibited by at least one operational activity | Strategic Traceability query; no unlinked capability |
| CR-02 *(Example)* | Every operational exchange is realised by at least one resource exchange or recorded as manual | Operational to Resources traceability |
| CR-03 *(Example)* | Every service has a provider resource in the to-be state | Services Traceability |
| CR-04 *(Example)* | Every security asset has an owner and an enclave | Security Traceability |
| CR-05 *(Example)* | Every new resource is delivered by a project milestone | Project Traceability |
| [CR-NN] | [Rule] | [Check] |

| Capability | Operational activity | Service | Resource | Project | Requirement |
|---|---|---|---|---|---|
| CAP-01.1 *(Example)* | Confirm fire report | SV-02 | RS-01 | PRJ-01 | [REQ-NN] |
| CAP-02 *(Example)* | Issue warning | SV-03 | National warning platform | Not applicable (existing) | REQ-01 |
| CAP-03 *(Example)* | Lead joint response | SV-01 | RS-02, RS-03 | PRJ-02, PRJ-03 | REQ-02 |

## 16. Mapping to other frameworks

<!-- Guidance: Many defence and government sponsors still ask for DoDAF or NAF views. Show which UAF content answers them. The official mapping is in the UAF traceability appendix; this table is a reader's guide only. Pitfall: producing a second set of views by hand instead of generating them from the same model. -->

UAF grew out of the Unified Profile for DoDAF and MODAF (UPDM) and states that UAFML can be used to
develop architectures compliant with DoDAF 2.02, MODAF 1.3 and NAF 3.1 and v4. MODAF guidance was
withdrawn by the UK government in January 2021 and replaced by NAF v4; record MODAF only for
legacy architectures.

| Requested framework view group | UAF viewpoint that supplies it | Notes |
|---|---|---|
| DoDAF All Viewpoint | Architecture Management, Summary and Overview | Overview and dictionary content |
| DoDAF Capability Viewpoint | Strategic | Capability taxonomy, dependencies, phasing |
| DoDAF Operational Viewpoint | Operational | Performers, activities, exchanges |
| DoDAF Services Viewpoint | Services | Service specifications |
| DoDAF Systems Viewpoint | Resources | Systems and resource exchanges |
| DoDAF Data and Information Viewpoint | Information aspect | Conceptual and logical data |
| DoDAF Project Viewpoint | Projects | Projects and milestones |
| DoDAF Standards Viewpoint | Standards | Standards profile and forecast |
| NAF v4 views | Matching UAF viewpoint and aspect | Check UAF Appendix A, Traceability, for the cell by cell mapping |

## 17. Model management and tool conformance

<!-- Guidance: Record how the model is held, versioned and exchanged, and what the tool supports. Pitfall: a model that only one person can open, in a tool version nobody else has. -->

| Item | Value |
|---|---|
| Modelling language | UAFML (UAF Modeling Language), a profile of SysML 1.6 |
| Tool and version | [Tool], [version] |
| Tool conformance level | [Type 1 view specification / Type 2 conceptual syntax / Type 3 formal syntax / Type 4 model interchange], as the vendor declares |
| Model exchange | *Example:* XMI export at each baseline; stored with this document |
| Configuration management | *Example:* Model baselined at each document version; changes through the design authority |
| Model conventions | *Example:* Element names in singular nouns; IDs as in this document; one package per viewpoint |
| Review method | *Example:* Model walkthrough with stakeholders of each selected cell; correspondence rule queries run before each baseline |

UAF 1.3 defines four conformance types for tools, each building on the one before: view
specification conformance, conceptual syntax conformance, formal syntax conformance and model
interchange conformance. Ask the tool vendor which type their implementation claims.

## 18. Issues, decisions and review record

<!-- Guidance: Keep decisions and open issues next to the architecture they affect. Record rationale and rejected options. Pitfall: decisions made in meetings and never written into the description. -->

| ID | Type | Description | Rationale or resolution | Owner | Status |
|---|---|---|---|---|---|
| UAF-DEC-001 *(Example)* | Decision | Choose Option B (shared incident data platform) | Meets REQ-01 at lower organisational cost than Option C (section 13) | @chief-architect | Approved |
| UAF-ISS-001 *(Example)* | Issue | Personnel numbers for 2029 depend on the municipal budget | Re-check after budget approval | @capability-owner | Open |
| UAF-ISS-002 *(Example)* | Inconsistency | RX-02 protocol not yet agreed with dispatch vendor | Resolve in PRJ-03 design | @systems-engineer | Open |
| [UAF-XXX-NNN] | [Type] | [Description] | [Rationale] | [@owner] | [Status] |

Record full decisions in the Architecture Decision Log (`architecture/architecture-decision-log`).

## 19. Glossary and references

<!-- Guidance: Define the UAF terms your readers may not know and list the specification documents and versions used. -->

### 19.1 Glossary

| Term | Meaning in this document |
|---|---|
| Viewpoint (UAF grid row) | A group of view specifications addressing related stakeholder concerns, such as Strategic or Operational; UAF 1.3 calls these viewpoints, earlier versions called them domains |
| Aspect (UAF grid column) | A way of looking at elements, such as Taxonomy or Connectivity; earlier versions called these model kinds |
| View specification | A grid cell: the rules for one kind of view |
| Capability | What the enterprise must be able to achieve, independent of how |
| Operational performer | A logical role that carries out operational activities |
| Resource | A system, software, organisational or natural element that performs work |
| Actual resource | A specific configuration of resources used for analysis or verification |
| System of systems | A set of independently owned systems working together for a shared outcome |

### 19.2 References

| Reference | Version or date | Use |
|---|---|---|
| OMG Unified Architecture Framework (UAF), Domain Metamodel (DMM) | Version 1.3, formal/25-10-01, formal version adopted April 2026, omg.org/spec/UAF | Grid, viewpoints, aspects, view specification names |
| OMG UAF Modeling Language (UAFML) | Version 1.3, formal/25-10-03 | Modelling language profile |
| OMG UAF Appendix A Traceability, Appendix B Sample Problem, Appendix C Enterprise Architecture Guide | Version 1.3 (informative) | Framework mapping and method guidance |
| ISO/IEC/IEEE 42010, Software, systems and enterprise: Architecture description | 2022 (Edition 2) | Conformance (section 1.3) |
| DoD Architecture Framework | Version 2.02 | Mapping (section 16) |
| NATO Architecture Framework | Version 4 | Mapping (section 16) |
| UK MOD Architecture Framework (MODAF) | Withdrawn 15 January 2021, replaced by NAF v4 | Legacy note only |
| [Sponsor architecture standard] | [Version] | [Use] |

## Standard and licence note

Based on the OMG Unified Architecture Framework (UAF) version 1.3 (Domain Metamodel formal/25-10-01
and UAF Modeling Language formal/25-10-03, formal version April 2026), with conformance mapped to
ISO/IEC/IEEE 42010:2022. Viewpoint, aspect and view specification names are used as published by
OMG for reference; no specification text, figures or tables are reproduced, and all explanations,
selections and the worked example are original. ISO/IEC/IEEE 42010 is copyrighted: only its
element names are used. Check the current OMG specification at omg.org/spec/UAF and the current
edition of each referenced framework before use. UAF, UML and SysML are trademarks of the Object
Management Group; this template is not affiliated with or endorsed by OMG. Template licence: MIT.