Extensions Guide — Add Cross-Cutting Capabilities to Any Metamodel¶

Enterprise architecture isn't just elements and relationships. You also need to track why decisions were made, who governs what process, which quality attributes matter, and what it all costs. These concerns cut across every modelling language — they're not ArchiMate-specific or C4-specific.

Extensions are composable modules that add these cross-cutting capabilities to any metamodel. Unlike modelling languages (which define complete element/relationship palettes for a specific notation), extensions provide vocabulary for concerns that span multiple languages — decision tracking, process governance, reference architectures, quality attributes, and architectural tactics.

Every extension imports arch:core. Most define classes that subclass arch:Element, making them usable in architecture views alongside elements from any modelling language. Some extensions (architecture processes, financial architecture) define standalone class hierarchies that relate to architecture elements via linking properties rather than inheritance — reflecting the categorical distinction between architectural constituents and governance/operational infrastructure.

Overview¶

flowchart TD
    core["arch:core"]
    ad["ad:arch-decision<br/>Decisions, forces, options, rationale"]
    ap["ap:arch-processes<br/>Governance processes, activities, milestones"]
    refa["refa:ref-arch<br/>Patterns, tactics, reference models, building blocks"]
    qa["qa:quality-attributes<br/>Quality attribute individuals (ISO 25010 aligned)"]
    tac["tac:tactics<br/>Architectural tactics by quality attribute"]
    mlsys["mlsys:ml-systems<br/>ML-enabled system elements, stakeholders, viewpoints"]
    aigov["aigov:ai-governance<br/>AI ethics, risk classification, conformity assessment"]
    fina["fina:financial-architecture<br/>TCO, investment cases, CBA, FinOps"]
    easvc["easvc:ea-service<br/>Service catalog, engagements, satisfaction, maturity"]

    core --> ad & ap & refa & qa & tac & mlsys & aigov & fina & easvc

Extension	Prefix	Namespace	Key Classes
Architecture Decisions	`ad:`	`https://meta.linked.archi/arch-decision#`	Decision, DecisionState, Issue, Option, Force, Requirement, QualityAttributeRequirement
Architecture Processes	`ap:`	`https://meta.linked.archi/arch-processes#`	ArchitectureProcess, ProcessActivity, ProcessTask, ProcessDeliverable, ProcessRole, LifecycleStage, LifecycleModel
Reference Architecture	`refa:`	`https://meta.linked.archi/ref-arch#`	ReferenceArchitecture, ReferenceModel, Pattern, Tactic, ABB, SBB
Quality Attributes	`qa:`	`https://meta.linked.archi/quality-attributes#`	Quality attribute individuals
Tactics	`tac:`	`https://meta.linked.archi/tactics#`	Tactic individuals organized by quality attribute
ML-Enabled Systems	`mlsys:`	`https://meta.linked.archi/ml-systems/onto#`	MLModel, Dataset, TrainingPipeline, ServingInfrastructure, FeatureStore
AI Ethics & Governance	`aigov:`	`https://meta.linked.archi/ai-governance/onto#`	AISystem, RiskClassification, ConformityAssessment, BiasAssessment, HumanOversightPlan
Financial Architecture	`fina:`	`https://meta.linked.archi/financial-architecture/onto#`	CostModel, CostItem, InvestmentCase, CostBenefitAnalysis, Budget
EA-as-a-Service	`easvc:`	`https://meta.linked.archi/ea-service/onto#`	EAService, ServiceCatalog, ServiceEngagement, SatisfactionAssessment, EAMaturityAssessment

How Extensions Compose — Declaring Multi-Module Metamodels¶

Extensions can be imported individually or in combination. Paste this into a metamodel manifest to declare which extensions your metamodel uses:

ex:MyMetamodel a arch:Metamodel ;
    arch:modelConcepts
        <https://meta.linked.archi/archimate3/onto#>,
        <https://meta.linked.archi/arch-decision#>,
        <https://meta.linked.archi/arch-processes#>,
        <https://meta.linked.archi/ref-arch#> .

Extensions also compose with each other. This is where the real power lies — each extension addresses a different facet of architecture work, and together they form a complete picture:

Decisions + Quality Attributes — ad:QualityAttributeRequirement references quality attribute individuals via ad:onQualityAttribute. This connects "we need 99.95% availability" to the formal ISO 25010 definition of Availability.
Decisions + Reference Architecture — ad:Option can include patterns and tactics via ad:includesConcept. This connects "we chose the Circuit Breaker pattern" to the formal pattern definition with its quality attribute trade-offs.
Processes + Decisions — Process outputs include ad:Decision; process inputs include ad:Force. This connects "the Architecture Review Board produced ADR-042" to the governance workflow that led to it.
Reference Architecture + Tactics — refa:Tactic addresses quality attributes via refa:addressedQA; patterns contain tactics via refa:appliedTactic. This connects "the Microservices pattern uses Circuit Breaker and Retry tactics" to the quality attributes they address.
ML Systems + AI Governance — aigov:AISystem wraps mlsys:MLModel and mlsys:ServingInfrastructure via aigov:wrapsMLModel and aigov:wrapsServingInfra. This connects "the fraud detection model is classified as High Risk under the EU AI Act" to the technical ML components it governs. See the AI Governance Practice Guide.
AI Governance + Decisions — ad:Decision can reference aigov:AISystem via arch:refines. This connects "ADR-051: Adopt EU AI Act compliance framework" to the AI systems it affects.
Financial Architecture + Decisions — fina:hasCostBenefitAnalysis links ad:Option to fina:CostBenefitAnalysis. This connects "Option A costs EUR 450K with NPV of EUR 220K" to the decision it informs. See the Financial Architecture Practice Guide.
Financial Architecture + TIME — fina:hasCostModel on timefw:Application enables cost-aware portfolio rationalization. "What is the total migration cost for all Migrate-classified applications?" becomes a single SPARQL query.
ML Systems + Decisions — ad:QualityAttributeRequirement can reference ML quality attributes (mlqa:Explainability, mlqa:Fairness). This connects "the model must be explainable" to the formal quality attribute definition. See the ML Systems Practice Guide.

1. Architecture Decisions (`ad:arch-decision`)¶

Why This Extension Exists¶

Architecture decisions are the most important artifacts an architect produces — more important than diagrams, more durable than models. Yet in most organizations, decisions live in Confluence pages, email threads, or people's heads. When someone asks "why did we choose Kafka over RabbitMQ?", the answer is often "ask Sarah, she was here when we decided that."

The architecture decisions extension solves this by making decisions, the forces that drove them, the options that were considered, and the rationale that justified the choice into first-class elements in the knowledge graph. Every decision is traceable to the requirements it addresses, the elements it affects, and the stakeholders who influenced it.

The extension is grounded in academic research on architecture decision documentation (Jansen & Bosch, Kruchten, Zimmermann) and aligned with the MADR (Markdown Any Decision Records) template structure. It implements the Attribute-Driven Design (ADD) methodology's concept of iterative, quality-driven decision making.

When to Use¶

Import this extension when your metamodel needs to:

Capture architecture decision records (ADRs) as queryable, linked data
Trace decisions to the forces (requirements, constraints, quality attributes, trends) that influenced them
Evaluate candidate options with their trade-offs, risks, and element impact
Link decisions to affected model elements for impact analysis
Model quality attribute scenarios (QAS) with the full stimulus-response structure

The Decision Lifecycle¶

The core flow is: Issue → Forces → Options → Decision → Impact

An Issue is a problem that needs a decision. It might come from a stakeholder concern, a technical limitation, or a change in requirements. Issues are linked to the forces that influence them and the elements that caused them.

Forces are everything that influences the decision — requirements, constraints, principles, trends, even personal preferences. The extension provides a rich hierarchy of force types because different forces have different characteristics: a budget constraint is non-negotiable, a technology trend is directional, a personal preference is subjective but real.

Options are candidate solutions. Each option addresses specific forces and has a concrete impact on the architecture — it adds, removes, modifies, or reuses model elements. Options can include patterns and tactics from the reference architecture extension.

A Decision records the chosen option, the alternatives that were rejected, the forces that drove the choice, and the justification. Decisions link to the affected elements, enabling impact analysis.

A DecisionState says where the record sits in that flow — whether it is still open for deliberation or settled. Without it, a proposal under discussion looks identical to a binding decision.

Example: Database Scaling Decision¶

This example models a real-world scenario: an e-commerce platform's Orders database can't handle Black Friday traffic. The architecture team needs to decide how to scale it.

@prefix ad:       <https://meta.linked.archi/arch-decision#> .
@prefix am:       <https://meta.linked.archi/archimate3/onto#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .
@prefix skos:     <http://www.w3.org/2004/02/skos/core#> .
@prefix arch:     <https://meta.linked.archi/core#> .
@prefix ex:       <https://model.example.com/ecommerce#> .

Step 1 — The elements under discussion. These already exist in the architecture model. The decision will affect them.

ex:OrderService a am:ApplicationComponent ;
    skos:prefLabel "Order Service"@en .

ex:OrdersDB a am:ApplicationComponent ;
    skos:prefLabel "Orders Database"@en .

ex:OrderService am:accesses ex:OrdersDB .

Step 2 — The issue. Something triggered the need for a decision. Note how the issue links to the element that caused it, the stakeholder who owns it, and the forces that influence it.

ex:DBScalabilityIssue a ad:Issue ;
    skos:prefLabel "Orders DB cannot handle peak load"@en ;
    ad:problemStatement
        """The Orders Database reaches 95% CPU utilization during Black Friday
        sales events (10x normal traffic). Response times degrade from 50ms
        to 3 seconds, causing order timeouts and revenue loss."""@en ;
    ad:issueOwner ex:SolutionArchitect ;
    ad:issueCausedBy ex:OrdersDB ;
    ad:influencingForce ex:AvailabilityReq, ex:PerformanceReq, ex:BudgetConstraint .

Step 3 — The forces. Each force has a type, importance, and stakeholder. Quality attribute requirements use the full QAS (Quality Attribute Scenario) structure from Bass, Clements, Kazman — source of stimulus, stimulus, environment, artifact, response, response measure.

# A quality attribute requirement with full QAS structure
ex:AvailabilityReq a ad:QualityAttributeRequirement ;
    skos:prefLabel "Order Service Availability Under Peak Load"@en ;
    ad:onQualityAttribute iso25010:Availability ;
    ad:qasSourceOfStimulus ex:Customer ;
    ad:qasStimulus "Black Friday peak load — 10x normal traffic"@en ;
    ad:qasEnvironment "Normal operation, all regions active"@en ;
    ad:qasArtifact ex:OrderService ;
    ad:qasResponse "Service continues processing orders without errors"@en ;
    ad:qasResponseMeasure "99.95% uptime, zero order loss"@en ;
    ad:requestedByStakeholder ex:ProductOwner ;
    ad:hasImportanceMeasure "critical"^^xsd:string .

# A business constraint — non-negotiable budget limit
ex:BudgetConstraint a ad:BusinessConstraint ;
    skos:prefLabel "Infrastructure Budget Limit"@en ;
    skos:definition "Monthly infrastructure cost must not exceed EUR 15,000."@en ;
    ad:supportedByStakeholder ex:PlatformTeamLead .

Step 4 — The options. Each option specifies which forces it addresses and how it impacts the architecture. The addsConcept, modifiesConcept, removesConcept, and makesUseConcept properties make the impact explicit and queryable.

ex:VerticalScaling a ad:Option ;
    skos:prefLabel "Option A — Vertical Scaling"@en ;
    skos:definition "Upgrade PostgreSQL to a larger instance."@en ;
    ad:addressesForce ex:PerformanceReq ;
    ad:modifiesConcept ex:OrdersDB ;
    ad:hasRisk [ skos:prefLabel "Single point of failure — no redundancy"@en ] .

ex:ReadReplicas a ad:Option ;
    skos:prefLabel "Option B — Read Replicas"@en ;
    skos:definition "Add two read replicas behind a connection proxy."@en ;
    ad:addressesForce ex:PerformanceReq, ex:AvailabilityReq ;
    ad:makesUseConcept ex:OrdersDB ;
    ad:addsConcept ex:ReadReplica1, ex:ReadReplica2, ex:ConnectionProxy .

ex:CQRSOption a ad:Option ;
    skos:prefLabel "Option C — CQRS + Event Sourcing"@en ;
    skos:definition "Separate read and write models with an event store."@en ;
    ad:addressesForce ex:PerformanceReq, ex:AvailabilityReq ;
    ad:removesConcept ex:OrdersDB ;
    ad:addsConcept ex:EventStore, ex:ReadModel ;
    ad:hasRisk [ skos:prefLabel "Team has no event sourcing experience"@en ] .

Step 5 — The decision. Links everything together: the issue it resolves, the option selected, the alternatives rejected, the forces that drove it, the elements affected, and the justification.

ex:ADR-042 a ad:Decision ;
    skos:prefLabel "ADR-042: Use read replicas for Orders DB scaling"@en ;
    ad:decisionState ad:Accepted ;
    ad:hasIssue ex:DBScalabilityIssue ;
    ad:hasSelectedOption ex:ReadReplicas ;
    ad:hasAlternative ex:VerticalScaling, ex:CQRSOption ;
    ad:influencedByForce ex:AvailabilityReq, ex:PerformanceReq, ex:BudgetConstraint ;
    ad:relatedConcept ex:OrdersDB, ex:OrderService ;
    ad:justification
        """Read replicas provide horizontal read scaling without application changes.
        Cost is ~EUR 3,000/month for two replicas, within budget. Vertical scaling
        was rejected because it doesn't address availability. CQRS was rejected
        due to team skill gap and timeline constraints."""@en .

Decision State — Open Deliberation vs Settled Decision¶

ad:decisionState links a decision to one of five enumerated individuals of ad:DecisionState. The vocabulary follows the MADR status values:

Individual	Meaning	Reading of `hasSelectedOption`
`ad:Proposed`	Raised, not yet settled. Options remain open.	Absent, or provisional and still under review
`ad:Accepted`	Settled and binding.	The chosen option; `hasAlternative` retains the rejected ones
`ad:Rejected`	Deliberated and closed without adopting any option.	Absent
`ad:Deprecated`	Was accepted, no longer applies, no replacement.	Historical
`ad:Superseded`	Was accepted, replaced by a later decision.	Historical; name the replacement with `ad:supersededBy`

State classifies the decision record, not the architecture it describes. A decision can be ad:Accepted while the change it mandates is still absent from the baseline — that distinction belongs to arch:architectureState on the affected model or element.

# Open — options still live, nothing selected
ex:ADR-051 a ad:Decision ;
    skos:prefLabel "ADR-051: Cache strategy for order lookups"@en ;
    ad:decisionState ad:Proposed ;
    ad:hasIssue ex:DBScalabilityIssue ;
    ad:hasAlternative ex:ReadThroughCache, ex:WriteThroughCache ;
    ad:dependsOn ex:ADR-042 .

# Retired — the decision ADR-042 replaced
ex:ADR-017 a ad:Decision ;
    skos:prefLabel "ADR-017: Vertically scale Orders DB on demand"@en ;
    ad:decisionState ad:Superseded ;
    ad:supersededBy ex:ADR-042 ;
    ad:hasSelectedOption ex:VerticalScaling .

ad:supersededBy is the inverse of ad:replaces, so asserting either direction is enough. MADR packs the replacement into the status line ("superseded by ADR-0005"); here the status and the link are separate assertions, which keeps both queryable.

A decision carries at most one current state. That cardinality is not asserted in OWL — a functional property would make a reasoner infer owl:sameAs between two state individuals on any data error, merging them instead of flagging the error. Enforce it in SHACL instead:

@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:DecisionShape a sh:NodeShape ;
    sh:targetClass ad:Decision ;
    sh:property [
        sh:path     ad:decisionState ;
        sh:maxCount 1 ;
        sh:in       ( ad:Proposed ad:Accepted ad:Rejected ad:Deprecated ad:Superseded ) ;
        sh:message  "A decision must carry at most one state from the DecisionState vocabulary."@en ;
    ] .

This is the repository-wide pattern for closed state vocabularies, including the alternatives that were rejected and why — see DD-23.

Querying Decisions¶

Once decisions are in the knowledge graph, you can answer questions that are impossible with document-based ADRs:

# Which elements are affected by decisions driven by availability concerns?
PREFIX ad:       <https://meta.linked.archi/arch-decision#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?decision ?decisionLabel ?element ?elementLabel WHERE {
    ?decision a ad:Decision ;
              skos:prefLabel ?decisionLabel ;
              ad:influencedByForce ?force ;
              ad:relatedConcept ?element .
    ?element skos:prefLabel ?elementLabel .
    ?force ad:onQualityAttribute iso25010:Availability .
}

# Which options were rejected and why?
PREFIX ad: <https://meta.linked.archi/arch-decision#>

SELECT ?decision ?rejected ?rejectedLabel WHERE {
    ?decision a ad:Decision ;
              ad:hasAlternative ?rejected .
    ?rejected skos:prefLabel ?rejectedLabel .
    FILTER NOT EXISTS { ?decision ad:hasSelectedOption ?rejected }
}

# Which decisions are in force, and which are still being deliberated?
PREFIX ad:   <https://meta.linked.archi/arch-decision#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?stateLabel ?decisionLabel ?selectedLabel WHERE {
    ?decision a ad:Decision ;
              ad:decisionState ?state ;
              skos:prefLabel ?decisionLabel .
    ?state skos:prefLabel ?stateLabel .
    OPTIONAL {
        ?decision ad:hasSelectedOption ?selected .
        ?selected skos:prefLabel ?selectedLabel .
    }
    VALUES ?state { ad:Proposed ad:Accepted }
}
ORDER BY ?stateLabel

Proposed decisions come back with no selected option — the options are still open. Accepted ones name the chosen option, with the rest retained as alternatives.

Force Hierarchy¶

Forces are organized in a class hierarchy under ad:Force. This matters because different force types have different characteristics — a constraint is non-negotiable, a trend is directional, a preference is subjective:

flowchart TD
    Force["ad:Force"]
    Principle["ad:Principle<br/>Qualitative statements of intent"]
    Requirement["ad:Requirement"]
    FR["ad:FunctionalRequirement"]
    QAR["ad:QualityAttributeRequirement<br/>(with full QAS properties)"]
    Constraint["ad:Constraint"]
    TC["ad:TechnicalConstraint"]
    BC["ad:BusinessConstraint"]
    Trend["ad:Trend<br/>Technology or domain trends"]
    PP["ad:PersonalPreference<br/>Stakeholder preferences (real but subjective)"]
    Policy["ad:Policy<br/>Organizational policies"]

    Force --> Principle & Requirement & Trend & PP & Policy
    Requirement --> FR & QAR & Constraint
    Constraint --> TC & BC

The name "Force" was chosen over "Driver" or "Motivation" because it is more generic and avoids collision with ArchiMate's Driver concept. See DD-19.

Validating Decision Records¶

The ontology keeps OWL minimal, so the rules that would silently corrupt data if expressed as OWL axioms live in SHACL instead — https://meta.linked.archi/arch-decision-shapes# (prefix adsh:).

The state vocabulary is the clearest case. ad:decisionState is a plain owl:ObjectProperty: declaring it owl:FunctionalProperty would make a reasoner infer owl:sameAs between two states on one decision and silently merge Proposed with Accepted, and owl:oneOf on ad:DecisionState would stop your organization adding a state its governance process needs. The shape closes the set instead, where you can replace it:

adsh:DecisionShape
    a               sh:NodeShape ;
    sh:targetClass  ad:Decision ;
    sh:property [
        sh:path     ad:decisionState ;
        sh:maxCount 1 ;
        sh:in       ( ad:Proposed ad:Accepted ad:Rejected ad:Deprecated ad:Superseded ) ;
    ] ;
.

Because state determines what a record owes you, the obligations are state-dependent rather than blanket. A Proposed decision may carry several live options and no selection; an Accepted one must name the option it chose and the rationale behind it; a Superseded one must name its replacement, or it should have been Deprecated. These are written as SHACL Core implications — sh:or ( [ sh:not A ] [ B ] ) — so they work on any engine:

Shape	Fires when	Requires
`adsh:AcceptedDecisionSelectionShape`	`ad:decisionState` is `ad:Accepted`	`ad:hasSelectedOption`
`adsh:AcceptedDecisionRationaleShape`	`ad:decisionState` is `ad:Accepted`	`ad:justification` or `ad:justificationDocument`
`adsh:SupersededDecisionShape`	`ad:decisionState` is `ad:Superseded`	`ad:supersededBy`

adsh:QualityAttributeRequirementShape checks the other common gap: a quality attribute requirement that names no quality attribute, or a scenario missing part of the six-tuple. A scenario without ad:qasResponseMeasure is not testable, which is the failure mode worth catching early.

.scripts/validate.sh --shacl arch-decision

Constraints that mark incompleteness rather than malformity carry sh:severity sh:Warning. Engines that ignore severity — including the RDF4J ShaclSail this repository validates with — treat them as failures, so expect advisories on partially populated models.

2. Architecture Processes (`ap:arch-processes`)¶

Full guide: Processes Modelling Guide — detailed usage with ISO standard integration, lifecycle stages, and architecture state.

Why This Extension Exists¶

Architecture governance is often informal — review boards meet, decisions are made, but the process itself is not captured. When a new architect joins, they don't know what the governance workflow looks like, who approves what, or what deliverables are expected. When an audit asks "what process led to this architecture?", nobody can answer without manual research.

The architecture processes extension describes governance workflows as a separate concept layer. A process has activities, tasks, roles, milestones, inputs, and outputs — all queryable, all traceable. You can describe your Architecture Review Board process, your ADD iterations, your TOGAF ADM phases, or any custom governance workflow.

Process concepts are not subclasses of arch:Element — they are governance infrastructure that acts upon architecture elements from the outside. Architecture elements relate to processes via linking properties (ap:governs, ap:governedBy, ap:input, ap:output, ap:consumedBy). This separation reflects the categorical distinction: an architecture review board governs systems; it is not itself a system component.

The extension is aligned with ISO/IEC/IEEE 42020 (architecture governance), 12207 (software lifecycle), and 15288 (system lifecycle). But it's not a copy of those standards — the standards live in standards/ as reference vocabularies. This extension provides the descriptive vocabulary for architecture governance work.

When to Use¶

Import this extension when your metamodel needs to:

Describe architecture governance workflows (review boards, design authorities)
Capture the decomposition of processes into activities and tasks
Assign roles and responsibilities to process steps
Track milestones and governance gates
Trace which processes produce which deliverables and decisions
Link architecture elements to the processes that govern them
Integrate with TOGAF ADM phases or ISO 42020 process areas

The Process Decomposition¶

The core structure is: Process → Activity → Task

An ArchitectureProcess is the top-level workflow. It has activities, inputs, outputs, milestones, and a responsible role. Processes can also have sub-processes for hierarchical decomposition.

A ProcessActivity is a cohesive set of tasks within a process. Activities are ordered (via precedes/follows) and assigned to roles (via performedBy).

A ProcessTask is the finest-grained unit of work — something a person actually does. Tasks belong to activities and can also be assigned to roles.

Supporting concepts:

ProcessDeliverable — a tangible output (document, model, report) that must be formally delivered
InformationItem — a body of information that flows between processes (a subclass of ProcessDeliverable)
ProcessMilestone — a governance checkpoint or phase gate
ProcessRole — a role that a stakeholder plays within a process (subclass of arch:Stakeholder)

Lifecycle Stages¶

Complementary to processes, the extension also defines lifecycle stage concepts. A lifecycle stage is a distinct phase that an entity (application, system, service) passes through over time. Stages answer "where is it now?" while processes answer "what happens during that phase?"

LifecycleStage — abstract class for any lifecycle stage (subClassOf skos:Concept)
LifecycleModel — a named collection of stages defining a complete lifecycle progression

Key properties: - ap:partOfLifecycle / ap:hasStage — links stages to their model - ap:stageOrder — numeric ordering within a model - ap:nextStage / ap:previousStage — explicit sequencing between stages

Domain ontologies define their own stage sets as subclasses or instances: - timefw:LifecycleState (Plan, Build, Run, Retire) — application portfolio lifecycle - iso12207:SoftwareLifecycleModel (Concept, Development, Production, Utilization, Support, Retirement) — ISO standard stages

@prefix ap:      <https://meta.linked.archi/arch-processes#> .
@prefix iso12207: <https://meta.linked.archi/iso12207#> .

# ISO 12207 stages are instances of ap:LifecycleStage
iso12207:DevelopmentStage a ap:LifecycleStage ;
    skos:prefLabel "Development"@en ;
    ap:partOfLifecycle iso12207:SoftwareLifecycleModel ;
    ap:stageOrder 2 .

# TIME lifecycle states are a subclass
timefw:LifecycleState rdfs:subClassOf ap:LifecycleStage .

Example: Architecture Review Board¶

This example models a formal architecture review process — the kind of governance workflow that organizations use to evaluate architecture proposals before implementation.

@prefix ap:   <https://meta.linked.archi/arch-processes#> .
@prefix ad:   <https://meta.linked.archi/arch-decision#> .
@prefix arch: <https://meta.linked.archi/core#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:   <https://model.example.com/governance#> .

The roles. Who participates in this process and what are their responsibilities?

ex:ChiefArchitect a ap:ProcessRole ;
    skos:prefLabel "Chief Architect"@en ;
    skos:definition "Senior architect responsible for architecture governance."@en ;
    ap:responsibleFor ex:ArchReviewProcess .

ex:SolutionArchitect a ap:ProcessRole ;
    skos:prefLabel "Solution Architect"@en ;
    skos:definition "Architect responsible for a specific solution domain."@en .

ex:SecurityArchitect a ap:ProcessRole ;
    skos:prefLabel "Security Architect"@en ;
    skos:definition "Specialist reviewing security aspects of proposals."@en .

The process. The top-level workflow with its activities and standards alignment.

ex:ArchReviewProcess a ap:ArchitectureProcess ;
    skos:prefLabel "Architecture Review Board Process"@en ;
    skos:definition """Formal governance process for evaluating architecture proposals
    against enterprise standards, quality attributes, and strategic alignment.
    Triggered when a project proposes significant architectural changes."""@en ;
    ap:hasActivity ex:RequestSubmission, ex:ReviewPreparation,
                   ex:ReviewExecution, ex:ReviewFollowUp ;
    rdfs:seeAlso <https://meta.linked.archi/iso42020#ArchitectureGovernance> .

The activities and tasks. Each activity decomposes into concrete tasks. Note the sequencing (precedes/follows) and role assignments (performedBy).

# Activity 1: The solution architect submits a proposal
ex:RequestSubmission a ap:ProcessActivity ;
    skos:prefLabel "1. Request Submission"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:performedBy ex:SolutionArchitect ;
    ap:precedes ex:ReviewPreparation ;
    ap:hasTask ex:PrepareProposal, ex:SubmitRequest .

ex:PrepareProposal a ap:ProcessTask ;
    skos:prefLabel "Prepare architecture proposal"@en ;
    skos:definition """Document the proposed architecture including context,
    requirements, options considered, and quality attribute analysis."""@en ;
    ap:taskOfActivity ex:RequestSubmission .

# Activity 2: The chief architect triages and assigns reviewers
ex:ReviewPreparation a ap:ProcessActivity ;
    skos:prefLabel "2. Review Preparation"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:performedBy ex:ChiefArchitect ;
    ap:follows ex:RequestSubmission ;
    ap:precedes ex:ReviewExecution ;
    ap:hasTask ex:TriageRequest, ex:AssignReviewers .

# Activity 3: The board evaluates the proposal
ex:ReviewExecution a ap:ProcessActivity ;
    skos:prefLabel "3. Review Execution"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:follows ex:ReviewPreparation ;
    ap:precedes ex:ReviewFollowUp ;
    ap:hasTask ex:IndividualReview, ex:BoardDiscussion, ex:RecordFindings .

ex:IndividualReview a ap:ProcessTask ;
    skos:prefLabel "Individual review by domain experts"@en ;
    ap:taskOfActivity ex:ReviewExecution ;
    ap:performedBy ex:SecurityArchitect .

# Activity 4: Follow-up and remediation tracking
ex:ReviewFollowUp a ap:ProcessActivity ;
    skos:prefLabel "4. Review Follow-Up"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:follows ex:ReviewExecution ;
    ap:hasTask ex:PublishReport, ex:TrackRemediation .

Milestones. Governance gates that must be passed before implementation can proceed.

ex:ReviewGate a ap:ProcessMilestone ;
    skos:prefLabel "Architecture Review Gate"@en ;
    skos:definition "Implementation may not proceed without board approval."@en ;
    ap:milestoneOfProcess ex:ArchReviewProcess ;
    ap:approvedBy ex:ChiefArchitect .

Inputs and outputs. What flows into and out of the process.

# Input: the proposal document
ex:ArchProposal a ap:InformationItem ;
    skos:prefLabel "Architecture Proposal Document"@en ;
    ap:consumedBy ex:ArchReviewProcess .

# Output: the review report
ex:ReviewReport a ap:ProcessDeliverable ;
    skos:prefLabel "Architecture Review Report"@en ;
    skos:definition "Formal report with findings, conditions, and the board decision."@en ;
    ap:producedBy ex:ArchReviewProcess ;
    ap:approvedBy ex:ChiefArchitect .

# Output: the formal decision (links to the decisions extension)
ex:ReviewDecision a ad:Decision ;
    skos:prefLabel "Architecture Review Board Decision"@en .

Standards vs Extension¶

A common question: why do we need both standards/iso42020/ and extensions/processes/?

The extension (ap:) provides the generic governance vocabulary — ap:ArchitectureProcess, ap:ProcessActivity, ap:ProcessTask, and the linking properties (ap:governs, ap:input, ap:output). It defines no standard-specific process areas.

The standards (iso42020:, iso12207:, iso15288:) subclass the extension's generic classes and add the normative process areas from each ISO standard. iso42020:Process rdfs:subClassOf ap:ArchitectureProcess, so ISO 42020 process individuals inherit the full AP vocabulary — ap:governs, ap:hasActivity, ap:input/ap:output, etc.

# ISO 42020 grounds in arch-processes
iso42020:Process rdfs:subClassOf ap:ArchitectureProcess .

# Use ISO 42020 processes directly with AP properties
iso42020:ArchitectureElaboration a iso42020:Process ;
    ap:governs ex:PaymentPlatform ;
    ap:hasActivity ex:ElaborateContracts ;
    ap:output ex:DetailedArchModel .

Querying Processes¶

# What deliverables does each process produce?
PREFIX ap: <https://meta.linked.archi/arch-processes#>

SELECT ?process ?processLabel ?deliverable ?deliverableLabel WHERE {
    ?deliverable ap:producedBy ?process .
    ?process skos:prefLabel ?processLabel .
    ?deliverable skos:prefLabel ?deliverableLabel .
}

# Which activities have no assigned performer? (governance gap)
PREFIX ap: <https://meta.linked.archi/arch-processes#>

SELECT ?activity ?label WHERE {
    ?activity a ap:ProcessActivity ;
              skos:prefLabel ?label .
    FILTER NOT EXISTS { ?activity ap:performedBy ?_ }
}

3. Reference Architecture (`refa:ref-arch`)¶

Why This Extension Exists¶

Architects don't design from scratch — they apply patterns, tactics, and reference architectures that encode proven solutions. But this reusable knowledge is usually trapped in books, wiki pages, and architects' heads. When someone asks "which patterns do we use for event processing?" or "what quality attributes does the Circuit Breaker tactic address?", the answer requires human memory.

The reference architecture extension makes reusable architectural knowledge into queryable, linked data. Patterns are connected to the tactics they contain. Tactics are connected to the quality attributes they address. Building blocks are connected to the patterns they implement. And all of this connects to the decisions extension — when an architect selects a pattern as part of a decision, the quality attribute trade-offs come along for free.

The extension is grounded in the academic work of Bass, Clements, Kazman ("Software Architecture in Practice"), Harrison & Avgeriou ("How do architecture patterns and tactics interact?"), and Farshidi et al. ("Capturing software architecture knowledge for pattern-driven design").

When to Use¶

Import this extension when your metamodel needs to:

Capture architectural patterns with their context, problem, and solution
Model tactics and their quality attribute trade-offs (addressed vs impacted)
Define reference architectures with applicable tactics
Classify building blocks as abstract (ABB) or concrete (SBB)
Analyze pattern-tactic interactions and compatibility
Connect decision options to the patterns and tactics they include

Key Concepts¶

A ReferenceArchitecture models abstract architectural elements independent of specific technologies. It defines what capabilities are needed without specifying how to implement them. Reference architectures have applicable tactics.

A Pattern is a general, reusable solution to a commonly occurring problem. Patterns are composed of context, problem, and solution descriptions. They contain tactics (appliedTactic), can be based on other patterns (basedOnPattern), and can contain sub-patterns (containsPattern). Patterns are categorized as Integration, Module, Allocation, or Deployment patterns.

A Tactic is a primitive design technique that addresses a specific quality attribute. Tactics are simpler than patterns — they use a single mechanism. The key properties are addressedQA (the quality attribute the tactic is designed to improve) and impactedQA (quality attributes affected as a side effect, positively or negatively).

ABB (Architecture Building Block) is an abstract capability — "we need an API Gateway." SBB (Solution Building Block) is a concrete implementation — "we'll use Kong." ABBs are refined into SBBs during solution design.

Example: Microservices Resilience Patterns¶

This example models a set of resilience patterns and tactics for a microservices architecture, showing how patterns contain tactics, tactics address quality attributes, and building blocks implement patterns.

@prefix refa:     <https://meta.linked.archi/ref-arch#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .
@prefix am:       <https://meta.linked.archi/archimate3/onto#> .
@prefix skos:     <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:       <https://model.example.com/refarch#> .

Tactics. Each tactic addresses specific quality attributes and may impact others as a side effect. The appliedWithTactic property captures tactics that are commonly used together.

ex:CircuitBreakerTactic a refa:Tactic ;
    skos:prefLabel "Circuit Breaker"@en ;
    skos:definition """Detect failures and prevent cascading by failing fast
    when a downstream service is unavailable."""@en ;
    refa:addressedQA iso25010:Availability, iso25010:FaultTolerance ;
    refa:impactedQA iso25010:TimeBehaviour .

ex:RetryTactic a refa:Tactic ;
    skos:prefLabel "Retry with Exponential Backoff"@en ;
    skos:definition "Retry failed requests with increasing delays and jitter."@en ;
    refa:addressedQA iso25010:FaultTolerance ;
    refa:impactedQA iso25010:TimeBehaviour ;
    refa:appliedWithTactic ex:CircuitBreakerTactic .

ex:BulkheadTactic a refa:Tactic ;
    skos:prefLabel "Bulkhead Isolation"@en ;
    skos:definition "Isolate resource pools per dependency to prevent cascading exhaustion."@en ;
    refa:addressedQA iso25010:Availability ;
    refa:impactedQA iso25010:ResourceUtilization ;
    refa:relatedTactic ex:CircuitBreakerTactic .

ex:LoadBalancingTactic a refa:Tactic ;
    skos:prefLabel "Load Balancing"@en ;
    refa:addressedQA iso25010:Availability, iso25010:Capacity ;
    refa:broaderTactic ex:RedundancyTactic .

Patterns. Patterns contain tactics and can be composed hierarchically. The realizesTactic property means the pattern's primary purpose is to implement that tactic. The appliedTactic property means the tactic is used within the pattern but isn't its primary purpose.

ex:CircuitBreakerPattern a refa:IntegrationPattern ;
    skos:prefLabel "Circuit Breaker"@en ;
    skos:definition """Prevents cascading failures by wrapping remote calls in a
    circuit that opens (fails fast) when error rates exceed a threshold."""@en ;
    refa:patternContext "Distributed system with synchronous inter-service calls."@en ;
    refa:patternProblemOverview
        "A failing downstream service causes cascading timeouts."@en ;
    refa:patternSolutionOverview
        "A state machine (closed/open/half-open) that short-circuits failing calls."@en ;
    refa:realizesTactic ex:CircuitBreakerTactic ;
    refa:appliedTactic ex:RetryTactic .

ex:APIGatewayPattern a refa:IntegrationPattern ;
    skos:prefLabel "API Gateway"@en ;
    skos:definition """Single entry point for all client requests. Routes, authenticates,
    rate-limits, and aggregates responses."""@en ;
    refa:appliedTactic ex:LoadBalancingTactic, ex:RateLimitingTactic ;
    refa:containsPattern ex:BackendForFrontendPattern .

ex:BackendForFrontendPattern a refa:IntegrationPattern ;
    skos:prefLabel "Backend for Frontend (BFF)"@en ;
    refa:basedOnPattern ex:APIGatewayPattern ;
    refa:partOfPattern ex:APIGatewayPattern .

Reference architecture. Ties patterns and tactics together into a coherent architectural approach.

ex:MicroservicesRefArch a refa:ReferenceArchitecture ;
    skos:prefLabel "Microservices Reference Architecture"@en ;
    skos:definition """Reference architecture for distributed systems as independently
    deployable services communicating via APIs and messaging."""@en ;
    refa:applicableTactic ex:CircuitBreakerTactic, ex:RetryTactic,
                          ex:BulkheadTactic, ex:LoadBalancingTactic .

Building blocks. ABBs define what capability is needed; SBBs define what product implements it.

# Abstract: what capability do we need?
ex:APIGatewayABB a refa:ABB ;
    skos:prefLabel "API Gateway"@en ;
    skos:definition "Unified API entry point with routing, auth, and rate limiting."@en ;
    refa:implementsPattern ex:APIGatewayPattern .

ex:ServiceMeshABB a refa:ABB ;
    skos:prefLabel "Service Mesh"@en ;
    skos:definition "Transparent inter-service communication with observability."@en ;
    refa:implementsTactic ex:CircuitBreakerTactic, ex:RetryTactic .

# Concrete: what product implements it?
ex:KongGateway a refa:SBB ;
    skos:prefLabel "Kong API Gateway"@en ;
    refa:implementsPattern ex:APIGatewayPattern .

ex:IstioMesh a refa:SBB ;
    skos:prefLabel "Istio Service Mesh"@en ;
    refa:implementsTactic ex:CircuitBreakerTactic, ex:RetryTactic .

Tactic impact analysis. How does applying a tactic affect a specific pattern? The ImpactOfTactic class captures this with precision — which elements are already covered, which need to be added, which need modification.

ex:CircuitBreakerImpactOnGateway a refa:ImpactOfTactic ;
    skos:prefLabel "Circuit Breaker impact on API Gateway"@en ;
    refa:impactOfTactic ex:CircuitBreakerTactic ;
    refa:impactMeasure "medium"^^xsd:string ;
    refa:implementedAlreadyInElement ex:KongGateway ;
    refa:addsNewElement ex:CircuitBreakerSidecar .

ex:APIGatewayPattern refa:hasImpactOfTactic ex:CircuitBreakerImpactOnGateway .

Querying Patterns and Tactics¶

# Which tactics address availability? What patterns use them?
PREFIX refa:     <https://meta.linked.archi/ref-arch#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?tactic ?tacticLabel ?pattern ?patternLabel WHERE {
    ?tactic refa:addressedQA iso25010:Availability ;
            skos:prefLabel ?tacticLabel .
    { ?pattern refa:appliedTactic ?tactic }
    UNION
    { ?pattern refa:realizesTactic ?tactic }
    ?pattern skos:prefLabel ?patternLabel .
}

# For each ABB, which SBBs implement the same pattern?
PREFIX refa: <https://meta.linked.archi/ref-arch#>

SELECT ?abb ?abbLabel ?sbb ?sbbLabel ?pattern WHERE {
    ?abb a refa:ABB ;
         skos:prefLabel ?abbLabel ;
         refa:implementsPattern ?pattern .
    ?sbb a refa:SBB ;
         skos:prefLabel ?sbbLabel ;
         refa:implementsPattern ?pattern .
}

Pattern Hierarchy¶

flowchart TD
    Pattern["refa:Pattern"]
    AP["refa:ArchitecturalPattern"]
    IP["refa:IntegrationPattern<br/>(component-and-connector: Circuit Breaker, API Gateway)"]
    MP["refa:ModulePattern<br/>(code-time: Layered, Hexagonal)"]
    AlP["refa:AllocationPattern<br/>(software-to-hardware: Active-Passive, Leader-Follower)"]
    DP["refa:DeploymentPattern<br/>(infrastructure: Blue-Green, Canary, Rolling)"]

    Pattern --> AP & DP
    AP --> IP & MP & AlP

4. Composing Extensions — A Complete Scenario¶

The real power of extensions emerges when they work together. This section walks through a complete scenario: an ADD (Attribute-Driven Design) iteration where a governance process produces a decision that selects a pattern with tactics addressing quality requirements.

Scenario: Payment Service Resilience¶

The Payment Service is experiencing cascading failures when the downstream payment gateway becomes unreachable. The architecture team needs to select a resilience strategy through a formal governance process.

Step 1 — The Governance Process (ap:)¶

The ADD iteration is modelled as a process with activities, a responsible role, and outputs.

@prefix ap:   <https://meta.linked.archi/arch-processes#> .
@prefix ad:   <https://meta.linked.archi/arch-decision#> .
@prefix refa: <https://meta.linked.archi/ref-arch#> .
@prefix am:   <https://meta.linked.archi/archimate3/onto#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .
@prefix ex:   <https://model.example.com/combined#> .

ex:ADDIteration1 a ap:ArchitectureProcess ;
    skos:prefLabel "ADD Iteration 1 — Establish Resilience Strategy"@en ;
    ap:hasActivity ex:IdentifyDrivers, ex:SelectPattern, ex:RecordDecision ;
    ap:output ex:ADR-101 .

ex:LeadArchitect a ap:ProcessRole ;
    skos:prefLabel "Lead Architect"@en ;
    ap:responsibleFor ex:ADDIteration1 .

ex:IdentifyDrivers a ap:ProcessActivity ;
    skos:prefLabel "Identify Architectural Drivers"@en ;
    ap:activityOfProcess ex:ADDIteration1 ;
    ap:performedBy ex:LeadArchitect ;
    ap:precedes ex:SelectPattern .

ex:SelectPattern a ap:ProcessActivity ;
    skos:prefLabel "Select Pattern and Tactics"@en ;
    ap:activityOfProcess ex:ADDIteration1 ;
    ap:follows ex:IdentifyDrivers ;
    ap:precedes ex:RecordDecision .

ex:RecordDecision a ap:ProcessActivity ;
    skos:prefLabel "Record Architecture Decision"@en ;
    ap:activityOfProcess ex:ADDIteration1 ;
    ap:follows ex:SelectPattern .

ex:ResilienceGate a ap:ProcessMilestone ;
    skos:prefLabel "Resilience Design Gate"@en ;
    skos:definition "Implementation may not proceed without approved resilience design."@en ;
    ap:milestoneOfProcess ex:ADDIteration1 .

Step 2 — The Forces (ad:)¶

The "Identify Drivers" activity produces the forces that will influence the decision. Quality attribute requirements use the full QAS structure.

ex:AvailabilityReq a ad:QualityAttributeRequirement ;
    skos:prefLabel "Payment Service 99.99% Availability"@en ;
    ad:onQualityAttribute iso25010:Availability ;
    ad:qasStimulus "Downstream payment gateway becomes unreachable"@en ;
    ad:qasEnvironment "Normal operation, peak transaction volume"@en ;
    ad:qasArtifact ex:PaymentService ;
    ad:qasResponse "Service queues transactions and retries when gateway recovers"@en ;
    ad:qasResponseMeasure "99.99% uptime, zero lost transactions"@en .

ex:FaultToleranceReq a ad:QualityAttributeRequirement ;
    skos:prefLabel "Graceful Degradation Under Partial Failure"@en ;
    ad:onQualityAttribute iso25010:FaultTolerance ;
    ad:qasStimulus "One of three payment gateway providers fails"@en ;
    ad:qasResponse "Service routes to remaining providers without user impact"@en ;
    ad:qasResponseMeasure "Failover within 5 seconds, no transaction loss"@en .

ex:LatencyConstraint a ad:TechnicalConstraint ;
    skos:prefLabel "Payment Latency SLA"@en ;
    skos:definition "Payment confirmation must complete within 2 seconds."@en .

Step 3 — The Options with Patterns (ad: + refa:)¶

The "Select Pattern" activity evaluates options. Each option includes patterns and tactics from the reference architecture extension. This is where the extensions compose — the decision's option includes a pattern, and that pattern contains tactics that address quality attributes.

# Option A includes the Circuit Breaker pattern
ex:CircuitBreakerOption a ad:Option ;
    skos:prefLabel "Option A — Circuit Breaker with Retry"@en ;
    skos:definition """Wrap payment gateway calls in a circuit breaker with
    exponential backoff retry."""@en ;
    ad:addressesForce ex:AvailabilityReq, ex:FaultToleranceReq ;
    ad:includesConcept ex:CircuitBreakerPattern ;
    ad:addsConcept ex:RetryQueue, ex:DeadLetterQueue .

# The pattern and its tactics (from the ref-arch extension)
ex:CircuitBreakerPattern a refa:IntegrationPattern ;
    skos:prefLabel "Circuit Breaker"@en ;
    refa:realizesTactic ex:CircuitBreakerTactic ;
    refa:appliedTactic ex:RetryTactic .

ex:CircuitBreakerTactic a refa:Tactic ;
    skos:prefLabel "Circuit Breaker"@en ;
    refa:addressedQA iso25010:Availability, iso25010:FaultTolerance ;
    refa:impactedQA iso25010:TimeBehaviour .

ex:RetryTactic a refa:Tactic ;
    skos:prefLabel "Retry with Exponential Backoff"@en ;
    refa:addressedQA iso25010:FaultTolerance ;
    refa:appliedWithTactic ex:CircuitBreakerTactic .

# Option B — a different approach
ex:MultiProviderOption a ad:Option ;
    skos:prefLabel "Option B — Active-Active Multi-Provider"@en ;
    ad:addressesForce ex:AvailabilityReq, ex:FaultToleranceReq ;
    ad:addsConcept ex:ProviderRouter, ex:HealthChecker ;
    ad:hasRisk [ skos:prefLabel "Inconsistent behavior across providers"@en ] .

Step 4 — The Decision (ad:) — Output of the Process¶

The "Record Decision" activity produces the formal decision. It links back to the process that produced it, the issue it resolves, the forces that drove it, and the elements it affects.

ex:PaymentResilienceIssue a ad:Issue ;
    skos:prefLabel "Payment gateway failures cause cascading timeouts"@en ;
    ad:problemStatement """When the primary payment gateway becomes unreachable,
    the Payment Service blocks on connection timeouts, exhausting the thread
    pool and halting all payment processing."""@en ;
    ad:influencingForce ex:AvailabilityReq, ex:FaultToleranceReq .

ex:ADR-101 a ad:Decision ;
    skos:prefLabel "ADR-101: Use Circuit Breaker for payment resilience"@en ;
    ad:hasIssue ex:PaymentResilienceIssue ;
    ad:hasSelectedOption ex:CircuitBreakerOption ;
    ad:hasAlternative ex:MultiProviderOption ;
    ad:influencedByForce ex:AvailabilityReq, ex:FaultToleranceReq, ex:LatencyConstraint ;
    ad:relatedConcept ex:PaymentService ;
    ad:justification """Circuit Breaker with retry provides the required fault tolerance
    with minimal latency overhead. The multi-provider option was rejected because
    it introduces provider-specific logic. The circuit breaker pattern is supported
    by the existing Istio service mesh."""@en .

ex:PaymentService a am:ApplicationComponent ;
    skos:prefLabel "Payment Service"@en .

The Full Trace¶

With all three extensions composed, you can trace the complete chain:

flowchart LR
    subgraph ap["Governance Process (ap:)"]
        ADD["ADDIteration1"]
        ID["IdentifyDrivers"]
        SP["SelectPattern"]
        RD["RecordDecision"]
        ADD --> ID & SP & RD
    end

    subgraph ad["Decision (ad:)"]
        ADR["ADR-101"]
        Issue["hasIssue"]
        Opt["hasSelectedOption"]
        Force["influencedByForce"]
        RC["relatedConcept"]
        ADR --> Issue & Opt & Force & RC
    end

    subgraph refa["Pattern (refa:)"]
        CBP["CircuitBreakerPattern"]
        CBT["CircuitBreakerTactic<br/>addressedQA → Availability<br/>impactedQA → TimeBehaviour"]
        RT["RetryTactic<br/>addressedQA → FaultTolerance"]
        CBP -->|"realizesTactic"| CBT
        CBP -->|"appliedTactic"| RT
    end

    RD -->|"output"| ADR
    Opt -->|"includesConcept"| CBP
    Force --> AvReq["AvailabilityReq<br/>onQualityAttribute → iso25010:Availability"]
    RC --> PS["PaymentService<br/>(am:ApplicationComponent)"]

Cross-Extension SPARQL¶

This query traverses all three extensions to answer: "For each decision, what quality attributes were addressed, through which patterns and tactics?"

PREFIX ad:       <https://meta.linked.archi/arch-decision#>
PREFIX refa:     <https://meta.linked.archi/ref-arch#>
PREFIX ap:       <https://meta.linked.archi/arch-processes#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?process ?decision ?pattern ?tactic ?qualityAttribute WHERE {
    # Process produced the decision
    ?process a ap:ArchitectureProcess ;
             ap:output ?decision .

    # Decision selected an option that includes a pattern
    ?decision a ad:Decision ;
              ad:hasSelectedOption ?option .
    ?option ad:includesConcept ?pattern .

    # Pattern contains tactics that address quality attributes
    ?pattern a refa:Pattern .
    { ?pattern refa:realizesTactic ?tactic }
    UNION
    { ?pattern refa:appliedTactic ?tactic }
    ?tactic refa:addressedQA ?qualityAttribute .
}

Topic	Document
Working examples	`examples/extensions/` — Complete Turtle files for each extension
Core ontology classes	Ontology Reference
Design rationale	Design Decisions — DD-19 (Force naming), DD-18 (ReferenceModel)
Standards alignment	Standards Alignment — How standards relate to extensions
Real-world scenarios	Use Cases — UC-3 (decisions), UC-4 (governance), UC-10 (processes)
Creating a metamodel	Quick Start Guide

Extensions Guide — Add Cross-Cutting Capabilities to Any Metamodel¶

Overview¶

How Extensions Compose — Declaring Multi-Module Metamodels¶

1. Architecture Decisions (ad:arch-decision)¶

Why This Extension Exists¶

When to Use¶

The Decision Lifecycle¶

Example: Database Scaling Decision¶

Decision State — Open Deliberation vs Settled Decision¶

Querying Decisions¶

Force Hierarchy¶

Validating Decision Records¶

2. Architecture Processes (ap:arch-processes)¶

Why This Extension Exists¶

When to Use¶

The Process Decomposition¶

Lifecycle Stages¶

Example: Architecture Review Board¶

Standards vs Extension¶

Querying Processes¶

3. Reference Architecture (refa:ref-arch)¶

Why This Extension Exists¶

When to Use¶

Key Concepts¶

Example: Microservices Resilience Patterns¶

Querying Patterns and Tactics¶

Pattern Hierarchy¶

4. Composing Extensions — A Complete Scenario¶

Scenario: Payment Service Resilience¶

Step 1 — The Governance Process (ap:)¶

Step 2 — The Forces (ad:)¶

Step 3 — The Options with Patterns (ad: + refa:)¶

Step 4 — The Decision (ad:) — Output of the Process¶

The Full Trace¶

Cross-Extension SPARQL¶

Further Reading¶

1. Architecture Decisions (`ad:arch-decision`)¶

2. Architecture Processes (`ap:arch-processes`)¶

3. Reference Architecture (`refa:ref-arch`)¶