AI makes it cheap to produce architecture models. It does not make them true. Whether an AI-assisted landscape becomes an asset or a liability depends almost entirely on what happens between “proposed” and “canonical”. This post is about that step: how humans should review and curate AI-proposed models so trust rises with use. It sits alongside the capstone map of the AI loop and the post on modelling from structured and unstructured sources.
Why does AI-proposed architecture need human curation at all?
Because the failure modes are quiet. A model can hallucinate an integration, merge two similarly named systems, treat a deprecated design as current, or read a roadmap aspiration as fact. None of these look wrong on a diagram. Each one then flows into impact analysis, Enterprise Ask, generated artefacts, and — increasingly — the context that delivery agents act on.
That downstream reuse is the reason curation is not optional overhead. An unreviewed proposal that gets reused becomes a Context Tax bill later: the organisation discovers the error in a production change, not in a review.
What does a human-in-the-loop review queue look like?
A good queue is a work list of proposals, each with the evidence that produced it. For every item a reviewer should be able to answer three questions in seconds: what is being claimed, where did it come from, and what changes if I accept it?
- Accept — the claim is right and sufficiently evidenced; it joins the living map.
- Edit (or enrich) — mostly right; correct a name, relationship, or attribute, or add context the source lacked, then accept.
- Reject — wrong, out of scope, or superseded. Record why, because a rejected claim is knowledge too — it stops the same mistake being re-litigated.
- Defer — plausible but unproven. Park it as an open question rather than guessing.
What should reviewers check first?
Reviewing everything equally is how queues die. Prioritise by blast radius and by evidence strength:
- Relationships over attributes. A wrong integration edge changes impact analysis; a wrong description field rarely does.
- Weakly evidenced claims. A single passing mention is not an integration; a design section with a sequence description is.
- Conflicts between sources. Where two documents disagree, a human must decide which wins, and say so.
- New entities that look like existing ones. Resolve merges before they spread through the map.
- Lifecycle and ownership. Retirement and ownership changes are decisions, not facts to be inferred.
How do trust and governance work in practice?
Three practices make curation sustainable rather than heroic.
- Named stewardship. Someone — an enterprise architect, a domain architect — owns the ratification of a domain. Without an owner, a queue becomes a backlog.
- Evidence stays attached. A year later, “why does the map say this?” should open the original passage. That provenance is what survives audit and leadership challenge.
- Trust is measured. Track the accept/edit/reject ratio, time-to-first-trusted-slice, and how often Ask cites curated entities. A very high accept rate with no edits can mean rubber stamping, not quality.
These are the same evaluation signals used in the working method from automated discovery to durable architecture context.
Should AI ever be allowed to auto-approve?
There is a tempting pitch: unsupervised, near-100% coverage of the estate. We would resist it. Coverage is easy to achieve and hard to trust; a repository filled without review recreates the hollow, untrusted EA tool in a faster timeframe. Where automation helps is around the gate: pre-sorting a queue, grouping similar proposals, surfacing conflicts, and highlighting gaps. The decision to make something canonical remains human.
That position underlies why EA must own enterprise context in the agentic era: the more agents consume the map, the more the ratification step matters.
How does DecisionPen support review and curation?
In DecisionPen, AI output does not write straight to the Context of Record. Proposals — entities, relationships, and enrichment from documents, dialogue, and a spreadsheet import — are queued with their bound evidence. Architects accept, edit, reject, or defer them, and only then do Enterprise Ask answers and generated artefacts draw on them. Gaps stay visible as gaps rather than being papered over. The mechanics are documented in incremental modelling, and the workspace in Architecture Decision Workspace.
Trial DecisionPen on one domain and review the first fifty proposals. Note what you edited and rejected: that is where your organisation’s modelling conventions and local knowledge live, and where curation earns its keep.
When is DecisionPen not the right tool?
If you want unsupervised, fully automated population with no human review, DecisionPen is deliberately not that. It is also not the right primary tool for freeform diagramming (Visio, Lucidchart), BPMN, a Copilot that only drafts text, or a CMDB used purely for operational asset tracking. If no one in your organisation can own curation of a domain, fix that first — any tool will otherwise accumulate drafts, not knowledge.
What to read next
- What does AI actually do inside an Architecture Decision Workspace?
- How do you model enterprise architecture from structured and unstructured sources with AI?
- How does AI accelerate automated enterprise discovery?
- AI enterprise architecture: Copilot vs metamodel agent
- How automated enterprise architecture modelling works
Series index (AI in the Architecture Decision Workspace)
- D7a — The AI loop, mapped
- D7b — Model from structured and unstructured sources
- D7c — This post (human review and curation)