Introduction

A Rationale provides the logical reasoning behind a strategic or operational response. It is triggered by a specific condition (Trigger), and it guides the alignment of actions across one or more business architecture domains. Rationales are formalised objects in the Strategic Response Model and are central to decision transparency and traceability. See: Strategic Response Model

Rationales help ensure that every action taken by the organisation is grounded in strategic intent.

Every Rationale must reference the Trigger that prompted it. This is represented either by linking to a triggerID or embedding the full Trigger object (via schema reference). This linkage ensures traceability from external condition through to internal response.

Rationales may arise from performance insights, stakeholder needs, risk exposures, compliance obligations, or strategic opportunities.

Usage in business architecture

In the Orthogramic Metamodel, rationales serve to:

• Justify why an initiative, policy, or change exists.

• Link strategic drivers to responses in a structured way.

• Support transparency and traceability from high-level drivers to operational change.

Rationales may be connected to multiple elements across the business architecture, including:

• Initiatives and Strategies that require justification.

• Policies, Capabilities, and Value Streams being introduced or adjusted.

• Performance goals or KPIs in the Performance domain.

Rationale object

Each response includes a rationale object that captures the justification for action. It replaces previous references to rationaleId and allows richer traceability and reasoning.

Relationship to strategic response model

Each rationale is categorised by a Driver Type, which is derived from the Strategic Response Model. This provides a consistent basis for understanding and classifying business responses across the organisation.

Strategic Response Model drivers

The Strategic Response Model defines the following categories of drivers:

Implementation guidance

• Classification: Each rationale must include a driver type. Multiple drivers may be selected if appropriate.

• Traceability: Rationales should link to the relevant strategy, initiative, or performance goal.

• Consistency: Use the https://orthogramic.atlassian.net/wiki/spaces/OM/pages/290914315/Triggers#Trigger-Catalogue to guide classification.

Relationship to Triggers

Every rationale originates in response to a defined Trigger—an external event, internal insight, or strategic condition that prompts consideration or action. The Rationale captures the logical reasoning for why a specific response is necessary, based on that triggering context. This link is formalised via the trigger field, which connects each rationale directly to its source condition using the

For further details on how triggers are defined, classified, and managed, see: Triggers and the associated https://orthogramic.atlassian.net/wiki/spaces/OM/pages/290914315/Triggers#Trigger-Catalogue, which outlines recognised types such as Regulatory, Risk, Opportunity, and Performance Insight.

How rationales are formed in response to specific triggers

Rationales are formed by analysing the implications of a specific trigger—whether external (e.g. regulatory change, market shift) or internal (e.g. performance trend, operational failure)—and articulating the reasoning behind a proposed strategic response. Each rationale provides the logical and contextual justification for why a response is appropriate, necessary, or valuable. This step bridges the gap between situational awareness (the trigger) and deliberate action (the response), ensuring decisions are traceable, defensible, and aligned with organisational goals.

By linking a rationale to its originating trigger, organisations can ensure transparency in decision-making, assess the consistency of responses over time, and identify patterns that inform future strategic planning. Rationales also provide auditability for governance, especially when responses involve major investments or policy changes.

Linked domains and rationale classification

A rationale may influence multiple business architecture domains. These are listed under the linkedDomains property and allow downstream actions to be traced back to justifying logic. The classification field allows rationales to be categorised according to:

• Risk

• Compliance

• Opportunity

• Mandate

• Performance Insight

• Stakeholder Need

• Other

Schema reference

The trigger property in the Rationale schema is now defined using a JSON Schema $ref to the Trigger schema, which includes details such as:

• triggerID

• title

• triggerType (e.g. Regulatory, Risk, Opportunity, Performance Insight)

Rationale JSON schema

{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Rationale Schema",
"description": "Schema for a Rationale object used in the Strategic Response Model to explain the reasoning behind strategic responses",
"type": "object",
"properties": {
"rationaleTitle": {
"type": "string",
"description": "Title or summary of the rationale"
},
"description": {
"type": "string",
"description": "A detailed explanation of the rationale supporting a strategic response"
},
"trigger": {
"$ref": "https://orthogramic.com/schemas/trigger.schema.json ",
"description": "Trigger object that prompted this rationale, defined according to the Trigger schema"
},
"linkedDomains": {
"type": "array",
"description": "List of business architecture domains influenced or justified by this rationale",
"items": {
"type": "string",
"enum": [
"Strategy",
"Capabilities",
"Initiatives",
"Policy",
"Information",
"Performance",
"Products",
"Services",
"Stakeholder",
"Value Stream"
]
}
},
"classification": {
"type": "string",
"description": "Optional category for the rationale (e.g. risk mitigation, compliance, opportunity, mandate)",
"enum": [
"Risk",
"Compliance",
"Opportunity",
"Mandate",
"Performance Insight",
"Stakeholder Need",
"Other"
]
},
"dateCreated": {
"type": "string",
"format": "date",
"description": "The date the rationale was first recorded"
},
"author": {
"type": "string",
"description": "The person or team who documented the rationale"
},
"orgUnitTitle": {
"type": "string",
"description": "The organisational unit that owns or authored the rationale"
}
},
"required": [
"rationaleTitle",
"description",
"trigger"
]
}