Deliverable Templates & Document Generation¶

Architecture documents go stale the moment the model changes — the Architecture Definition Document written last quarter no longer matches reality, and updating it by hand is nobody's favourite job. If the document were generated from the live model, it would never drift.

Linked.Archi generates them from the knowledge graph. A deliverable template says what a document is for: its sections, the concerns each section answers, and the model questions it asks to answer them. A generator asks those questions of the model and renders the answers as Markdown, HTML or PDF. The document then states what the model holds, what it lacks, and what could not be checked — no hard-coded extraction logic required.

How It Works¶

flowchart LR
    subgraph tpl["Deliverable template (what)"]
        DT["DeliverableTemplate<br/>templateParameter"]
        TS["TemplateSection<br/>sectionViewpoint<br/>sectionAddressesConcern"]
        DT --> TS
    end
    subgraph qs["Question sets"]
        MQ["ModelQuestion<br/>SPARQL · answers · doesNotProve"]
    end
    subgraph gen["Generator (how)"]
        G["pre-bind · ask · render"]
    end
    OUT[".md / .html / .pdf"]

    TS -->|sectionAsks| MQ
    tpl --> G
    qs --> G
    G --> OUT

An arch:DeliverableTemplate defines the document — its title, purposes, the viewpoints it needs, its sections, and the values it is produced for (arch:templateParameter): the model, and for some documents an element or two plateaus.
Each arch:TemplateSection names its viewpoint (arch:sectionViewpoint), the concerns it answers (arch:sectionAddressesConcern) and the questions it asks (arch:sectionAsks, in reading order). A section can instead carry a single inline SPARQL query (arch:sectionQuery).
A generator asks each question of the model with the deliverable's values pre-bound, assembles the answers under the section's arch:sectionResultKey, and renders them through a layout.

Sections That Ask Questions¶

The questions are published arch:ModelQuestions — executable SPARQL, each with what a row means (arch:answers), the conclusion a reader should not draw (arch:doesNotProve) and the concerns it informs. The core set (https://meta.linked.archi/core-questions) works for any model; a language adds its own (ArchiMate 4.0, ArchiMate 3.2). Each is defined once and asked by any number of sections and tools.

Section 2 of the ArchiMate 4.0 Architecture Definition Document:

am4dt:ADD-S2 a arch:TemplateSection ; arch:sectionOrder 2 ;
    skos:prefLabel "2. Process Cooperation"@en ;
    skos:definition "How do processes cooperate, is each performed by someone, and is every service delivered?"@en ;
    arch:sectionViewpoint am4vp:ProcessCooperationViewpoint ;
    arch:sectionAddressesConcern am4vp:ProcessDependencies, am4vp:Responsibilities, am4vp:Completeness ;
    arch:sectionAsks ( am4q:viewpoint-scope am4q:unassigned-behaviour am4q:unrealised-services ) ;
    arch:sectionResultKey "processCooperation" .

For each question, the generator:

pre-binds what the question declares: ?model with the deliverable's model, ?viewpoint with the section's viewpoint, and any other parameter with the template's value for it — as VALUES at the start of the query, exactly as a modelling tool asks the same question;
reports a question it cannot ask, with the reason, instead of leaving it out: a required parameter with no value, a metamodel the question reads that the data does not include (the report names the Turtle to load), or a question that is in none of the loaded question sets;
states "none found" for a finding question (arch:resultIsFinding) with no answers, with the concerns it checks — an empty finding is an answer;
lists the model's views that follow the section's viewpoint, with the elements each shows — in every section that names a viewpoint, including one that asks no question.

Generated from the questions example model of ArchiMate 4.0, the section reads, in part:

## 2. Process Cooperation

How do processes cooperate, is each performed by someone, and is every service delivered?

*Viewpoint:* Process Cooperation Viewpoint · *Concerns:* Completeness, Dependencies between processes, Responsibilities

### Which processes and functions has nobody been assigned to?

Processes and functions that no active structure element is assigned to.

**1 found** (Warning) — Completeness, Responsibilities.

*One row per process or function without a performer.*

| Behaviour | Type |
| --- | --- |
| Register Claim | Process |

> *Does not prove:* That nobody performs it. The performer may be assigned to an enclosing process, or the model may stop above that level of detail.

Template Parameters¶

A template declares what it is produced for as sh:Parameters on arch:templateParameter; the variable each binds is the local name of its sh:path. The ArchiMate Change Impact Assessment is produced for one element under change, and optionally two plateaus:

am4dt:ChangeImpactAssessment a arch:DeliverableTemplate ;
    arch:templateParameter am4dt:ModelParameter,
        [ a sh:Parameter ; sh:path arch:focus ; sh:optional false ;
          sh:description "The element under change."@en ],
        [ a sh:Parameter ; sh:path arch:from ; sh:optional true ;
          sh:description "The baseline plateau. Section 3 asks its question only when both plateaus are given."@en ],
        [ a sh:Parameter ; sh:path arch:to ; sh:optional true ;
          sh:description "The target plateau. Section 3 asks its question only when both plateaus are given."@en ] .

A generator refuses to produce the document without a required value, and uses the data's only arch:Model when the model is not given. A question whose own required parameter stays unbound — the plateau comparison, when no plateaus are given — is reported as not asked; it is never run unbound:

### What changes between these two plateaus?

*Not asked:* it needs ?from (the earlier plateau, such as the baseline) and ?to (the later plateau, such as the target); none was given.

Sections With a Query¶

A section can carry its query inline instead: arch:sectionQuery holds a SPARQL SELECT, and its rows go into the rendering context under the section's result key, for a Handlebars layout to render. A section of a template of your own:

ex:Org-S1 a arch:TemplateSection ;
    arch:sectionOrder     1 ;
    arch:sectionViewpoint amvp:OrganizationViewpoint ;
    arch:sectionResultKey "businessOrganization" ;
    skos:prefLabel        "1. Business Organization"@en ;
    arch:sectionQuery     """
        PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
        PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

        SELECT ?label ?type ?description WHERE {
            ?element a ?type ;
                     skos:prefLabel ?label .
            VALUES ?type { am:BusinessActor am:BusinessRole am:BusinessCollaboration }
            OPTIONAL { ?element skos:definition ?description }
        } ORDER BY ?type ?label
    """ .

The rows become the context's businessOrganization array:

{
  "meta": { "title": "Organisation Overview", "date": "2026-04-24", "status": "Draft", "version": "1.0" },
  "businessOrganization": [
    { "label": "IT Operations", "type": "https://meta.linked.archi/archimate3/onto#BusinessActor",
      "description": "Manages infrastructure and platform services." }
  ]
}

and a layout iterates over them:

## 1. Business Organization

| Element | Description |
|---------|-------------|
{{#each businessOrganization}}
| {{this.label}} | {{this.description}} |
{{/each}}

A query section carries no concerns, findings or caveats of its own; the layout must know its columns. Questions are the form to prefer — the generator renders any template whose sections ask them with no layout of yours.

Available Templates¶

ArchiMate 4.0 and 3.2¶

The same four documents for each version, asking that version's questions: ArchiMate 4.0 templates, ArchiMate 3.2 templates.

Template	Sections	Produced for
Architecture Definition Document	8 — business, process cooperation, application, technology, cross-domain (cross-layer in 3.2), implementation and deployment, realisation roadmap, and an appendix on the quality of the description	the model
Architecture Requirements Specification	3 — stakeholders and drivers, goals and outcomes, requirements and their realisation	the model
Architecture Principles Document	2 — principles, strategy alignment	the model
Change Impact Assessment	3 — what depends on the element, views to update, baseline to target	the model, an element, and optionally two plateaus

Core (Framework-Agnostic)¶

Produced from a model in any language, asking the core questions: core templates. The core questions answer what a model holds, how its elements depend on each other and how sound the description is; a section whose concerns only a language's questions answer presents the model's views of its viewpoint.

Template	Sections	Produced for
Architecture Overview Document	5 — landscape (inventory and architecture states), stakeholders (views), components (definitions and names), dependencies (unconnected elements), standards compliance (unknown viewpoints, elements in no view, relationship integrity)	the model
Solution Design Document	5 — solution context (inventory); process, interface and deployment design and architecture decisions (views)	the model
Change Impact Assessment	4 — impact (what the element is related to, what reaches it in two steps), dependencies (the views that show it), gaps (architecture states), roadmap (views)	the model and an element

Ontology Properties¶

Property	Domain	Range	Description
`arch:templateHasSection`	`DeliverableTemplate`	`TemplateSection`	Links template to its sections
`arch:templateParameter`	`DeliverableTemplate`	`sh:Parameter`	A value the deliverable is produced for, pre-bound into its questions
`arch:sectionOrder`	`TemplateSection`	`xsd:integer`	Sort order within the template
`arch:sectionViewpoint`	`TemplateSection`	`Viewpoint`	The viewpoint this section addresses
`arch:sectionAddressesConcern`	`TemplateSection`	`Consideration`	A concern the section answers
`arch:sectionTargetsStakeholder`	`TemplateSection`	`Stakeholder`	A stakeholder the section is written for, where it differs from its viewpoint's
`arch:sectionAsks`	`TemplateSection`	`rdf:List` of `ModelQuestion`	The questions the section asks, in reading order
`arch:sectionQuery`	`TemplateSection`	`xsd:string`	SPARQL SELECT query for section data — the inline form
`arch:sectionResultKey`	`TemplateSection`	`xsd:string`	Key of the section's results in the rendering context
`arch:templateResource`	`DeliverableTemplate`, `PresentationFormat`	`xsd:anyURI`	Path to a Handlebars layout for the document, or for one format
`arch:templateHasFormat`	`DeliverableTemplate`	`PresentationFormat`	Supported output formats
`arch:templateTargetsPurpose`	`DeliverableTemplate`	`Purpose`	What architecture activity this supports

Writing Custom Templates¶

To create a new deliverable template:

Define an arch:DeliverableTemplate individual with its sections, and declare what it is produced for with arch:templateParameter — at least the model.
Give each section its viewpoint and the concerns it answers.
List the questions each section asks with arch:sectionAsks — from the published question sets, or from a question set of your own (arch:ModelQuestion) — or give it an arch:sectionQuery.
Set arch:sectionResultKey to name the section in the rendering context.
Optionally, point arch:templateResource at a Handlebars layout of your own.

The generator reads everything from the template and the question sets — no code changes needed.

Tool Specification¶

See Deliverable Generator Spec for the full tool specification including CLI interface, processing pipeline, rendering context, and error handling.