How do you generate ADRs, blueprints, and diagrams from living architecture context?

You can generate ADRs, blueprints, and diagrams from living architecture context when the artefact is a view of a curated map rather than a document someone redraws by hand. The map holds the entities, relationships, and How/Why evidence; generation selects a slice, renders it in the format a reader needs, and cites what it used. This post extends generating architecture docs from living context into decision records, solution blueprints, and generated diagram images — and into why solution architects have a reason to keep the map healthy.

What changes when artefacts are outputs of the map?

In most organisations the artefact is the work: an HLD, an ADR in a wiki, a diagram exported from a drawing tool. Each one restates the landscape from memory, and each one starts ageing the day it is published. When the map is the source and the artefact is the output, three things shift:

• Authority moves upstream. Corrections land once, in the curated model, and every future artefact inherits them.
• Drafting gets cheaper. The architect spends time on the decision and its trade-offs, not on re-listing neighbouring systems.
• Provenance survives. Statements in the output trace back to entities and evidence, so a reviewer can challenge a claim instead of arguing about whose document is newer.

How do you generate an ADR from the map?

An architecture decision record has a stable shape: context, options, decision, consequences. Most of the context and much of the consequences are facts about the estate — which applications are affected, which integrations touch them, which standards apply, what was decided or rejected before. Those are exactly what a curated map already holds.

1. Scope the decision — pick the entities in play (an application, a capability, a technology choice).
2. Pull the slice — neighbours, integrations, owners, prior decisions, and bound evidence for those entities.
3. Draft the record — context and consequences are assembled from the slice; options and the decision itself remain the architect’s judgement.
4. Review and ratify — a human edits, approves, and the accepted decision becomes part of the map for the next question.

The last step matters. An ADR that is generated and then lives only in a folder recreates the problem; an ADR whose outcome is written back is evidence the next generation can cite.

What is a blueprint generated from living context?

A blueprint is a target-state or solution view for a bounded change: the applications involved, the integrations to add or retire, the capabilities affected, and the constraints inherited from standards. A generated blueprint starts from the current-state slice of the map and overlays the proposed change, so reviewers see what exists and what is proposed against the same baseline.

• Current-state slice — drawn from accepted entities and relationships, not from a diagram last exported a year ago.
• Proposed delta — new or changed entities flagged as proposals until curated.
• Constraints and rationale — standards, prior decisions, and risks pulled with their evidence.

This is the practical form of the enterprise architecture context idea: one Context of Record, many outputs.

How are diagram images generated without a canvas?

A diagram is a visual projection of a graph slice. If the slice is already structured — entities, types, relationships — an image can be produced from it: a landscape view around one application, an integration map for a programme, a capability-to-application overview. The reader gets a diagram; the architect does not drag boxes.

Two consequences are worth stating plainly. First, when the underlying model changes, the diagram can be regenerated and will not silently disagree with the ADR next to it. Second, anything that is wrong in the picture is wrong in the map, so the fix goes to the right place. If you need bespoke layout or presentation styling, treat the generated image as the factual baseline and finish it in a drawing tool.

Why do solution architects keep the map healthy?

Governance asks for artefacts; architects deliver them under time pressure. If the only way to produce an HLD is to rediscover the landscape ( the rediscovery problem), the map is someone else’s chore. When the same map drafts the ADR, the blueprint, and the diagram, correcting it becomes the fastest route to a deliverable.

1. An architect needs an artefact for a change.
2. Generation reveals a stale or missing relationship in the slice.
3. Fixing it takes a minute, and it improves the draft immediately.
4. Accepted artefacts and decisions flow back, so the next architect starts from a better map.

That is the flywheel: use creates curation, curation improves the next use. It is the opposite of a modelling project that asks people to feed a repository for its own sake (why architects hate manual EA modelling).

What makes a generated artefact trustworthy?

• Curated inputs — only accepted entities and relationships are stated as fact; proposals are labelled as such.
• Citations — claims link to evidence a reviewer can open.
• Human sign-off — the architect owns the decision and the published artefact.
• Reproducibility — regenerating from the same map state gives the same facts, and a changed map gives a visibly changed artefact.

How does DecisionPen solve this?

DecisionPen is an Architecture Decision Workspace: it keeps the metamodel-aware map, binds How/Why evidence, and generates artefacts as views of that Context of Record.

• ADR drafts assembled from the affected slice, with the decision left to the architect and the outcome written back.
• Blueprints that overlay a proposed change on the curated current state.
• Generated diagram images rendered from the map — not drawn on a canvas.
• Citations and curation so output is explainable and governed (Enterprise Ask reads from the same map).

Trial DecisionPen on one in-flight change: generate the ADR, the blueprint slice, and the diagram, and note which corrections you made to the map along the way — that count is your flywheel measure.

When is DecisionPen not the right tool?

If your primary need is a freeform drawing canvas, pixel-perfect presentation diagrams, BPMN modelling, or a general writing Copilot. DecisionPen generates artefacts and diagram images from curated architecture context; it does not replace dedicated drawing tools, and it is not useful if nobody will curate the underlying map.

What to read next

• How do you generate architecture docs from living context?
• What is enterprise architecture context?
• Why do solution architects rediscover the landscape?
• How do AI agents interrogate and deep-reason over an EA map?
• Architecture Decision Workspace

Series index (AI in the Architecture Decision Workspace)

• D7a — What AI does inside an Architecture Decision Workspace
• D7b — Model EA from structured and unstructured sources with AI
• D7c — Review and curate AI-proposed architecture models
• D7d — This post (ADRs, blueprints, diagrams)
• D7e — Agents interrogate and deep-reason over the map
• D7f — Keep factsheets current with AI descriptions and relations