CelinQ Insights · No. 68

AI Architecture Review in Sparx EA: From Model Data to Actionable Findings

A useful architecture review is mostly a checklist run consistently against real model data, with a narrow, clearly labelled AI layer for turning findings into language a stakeholder can act on.

Every organisation that runs formal architecture governance eventually accumulates a review checklist, usually as a document nobody quite remembers writing, revised a little after each project that went badly. Does every application in scope have a documented owner. Does the dependency structure avoid single points of failure. Are the technologies in use on the approved standards list, or are they legacy exceptions that should have been retired. Is lifecycle data present and current. Are security-relevant relationships — the ones that cross a trust boundary, that touch a system holding personal data, that connect to something outside the organisation's own network — properly identified and reviewed. It is a long list, it is tedious to work through by hand, and it is exactly the kind of list that a person doing it for the fortieth time starts to apply inconsistently, not from carelessness but from simple fatigue.

This is the specific, unglamorous problem an architecture review feature ought to solve, and it is worth being precise about what "solving" it actually means before reaching for the word AI. A checklist applied consistently, against complete data, with every finding pointing back to the specific element that triggered it, is more valuable to a governance board than a checklist applied by an exhausted architect at nine in the evening before a review deadline — even if the exhausted architect is, in principle, capable of judgement a rule engine is not. The right design borrows the consistency of the machine for the parts of the review that are genuinely mechanical, and reserves the architect's judgement for the parts that actually need it, rather than pretending either one can do the whole job alone.

Model scope: deciding what a review actually covers

Before any finding can be produced, a review needs a boundary, and getting that boundary wrong is one of the most common ways a review becomes useless. Reviewing "the whole repository" sounds thorough but usually means reviewing a mixture of live production systems, retired pilots nobody remembered to archive, and speculative future-state sketches an architect was using to think out loud — three very different things, each deserving its own level of scrutiny, bundled together into one undifferentiated wall of findings that nobody has the patience to triage. A workable review starts by defining scope deliberately: a package, a set of packages, a workspace, or a filtered subset matching a stereotype or a lifecycle status, so that the findings that come out are about the systems a governance board actually needs to reason about today.

Scope also has to be explicit rather than implied, because an implied scope is the easiest place for a review to quietly miss something important. If a review is meant to cover every production application with an external-facing interface, the scope definition needs to say so directly — production status and external-facing interface, both — rather than relying on an architect to remember which package boundaries happen to align with that intent this quarter. A model changes constantly; a scope definition tied to explicit, queryable properties keeps working correctly even after the package structure has been reorganised twice.

The checklist itself: dependency structure, technology standards, lifecycle data

Once scope is fixed, the actual checks are, for the most part, exactly the kind of deterministic analysis described in the companion piece on private, AI-free model analysis — rule evaluation and graph traversal against the canonical model, not interpretation. Dependency structure checks walk the relationship graph within scope looking for the patterns a review checklist typically names: a component with an unusually high number of inbound dependencies that has quietly become a single point of failure, a cycle between two subsystems that were supposed to be layered cleanly, a chain of dependencies that crosses a boundary the organisation's target architecture says should not be crossed. Technology standards checks compare the technology tags attached to elements in scope against an approved list, flagging anything running on a platform the organisation has deprecated or never actually approved, the same comparison an architect would run manually against a standards register if they had the patience to check every element by hand.

Lifecycle data checks are simpler in mechanism but often the most consequential in practice, because lifecycle fields are exactly the kind of metadata that gets filled in enthusiastically during a project's kickoff and then quietly abandoned. A check that walks every in-scope element and reports which ones carry no lifecycle status, or a status that has not been updated in longer than the organisation's own policy allows, turns an invisible decay into a visible, addressable list. None of these three checks requires judgement about whether a given finding matters — that comes later — only a correct, complete pass over the model data in scope, run the same way every time the review is triggered.

Security-relevant relationships

Some relationships in a model deserve a closer look than others, and identifying which ones is itself a rule that can be applied consistently rather than left to whoever happens to be reviewing that day. A relationship that crosses from an internal system to an external party, that connects to an element handling data the organisation has classified as sensitive, or that grants a component access it did not previously have, is a security-relevant relationship in the sense that a review process should surface it explicitly rather than let it sit undifferentiated among hundreds of ordinary dependency links. Flagging these does not require deciding whether the relationship represents an actual security problem — that is a judgement for a security architect with context the model alone cannot provide — but it does require reliably finding every relationship that meets the criteria, so that the security architect's attention goes to a short, complete list rather than to whatever happened to catch someone's eye during a read-through.

This is a place where the value of a graph-aware, model-native tool is easiest to see, because a security-relevant relationship is not always a single hop. A component that has no direct connection to anything sensitive can still sit two or three hops upstream of one, which matters enormously if that component has weaker controls than the sensitive system it indirectly feeds. A checklist run element by element misses this kind of transitive exposure almost by construction; a checklist run as a graph traversal, following relationships outward from a defined set of sensitive elements, does not.

Missing documentation and inconsistent stereotypes

Two of the least exciting findings a review produces are also two of the most common, and both are entirely mechanical to detect. Missing documentation — an element with no notes, no description field populated, nothing beyond a name and a type — is simply a presence check, run across scope, reported as a list. It rarely feels urgent in the moment a review runs, which is exactly why it accumulates for years until someone inherits a system with no record of why it was built the way it was, at which point the missing documentation stops being a minor governance nag and becomes an active handover risk.

Inconsistent stereotypes are a subtler version of the same decay. A repository maintained by several people over several years develops small dialects: one architect uses "Application Component," another uses "Application," a third invents "App Service" for something that should have used one of the other two. None of these are wrong in isolation, but together they quietly break every query and every rule that assumes a consistent vocabulary, including the very checks described above, which is why catching stereotype drift early is worth a dedicated pass rather than treating it as a footnote. A rule that groups elements by name similarity and flags stereotype variants that look like they are meant to represent the same concept turns an invisible inconsistency into a short, concrete list an architect can resolve in an afternoon, well before it corrupts a quarter's worth of dependency analysis.

Findings with evidence, not verdicts

The shape a finding takes matters as much as its content. A finding that says "this component appears over-coupled" is an opinion dressed as a fact, and it invites exactly the kind of unproductive argument that erodes trust in a review process — someone disagrees, nobody can point to the specific relationships being counted, and the review stalls on a matter of interpretation that should never have been presented as settled. A finding that says "this component has eleven inbound dependencies from other in-scope applications, listed here, against a threshold this workspace's review policy sets at six" is a fact with a pointer to the exact evidence behind it, and it invites the right kind of conversation: is the threshold correct for this component, not whether the count is real.

This is why every finding CelinQ's deterministic checks produce is anchored to the specific elements and relationships that triggered it — the review is not a paragraph of prose summarising a general impression of the model, it is a structured list where each entry can be expanded back to the underlying graph, in the same spirit as the source links back to model entities described in the companion piece on natural-language querying. An architect reading a finding does not have to take the review's word for it; they can click through to the component in question and see exactly what was counted.

Severity and risk classification as a rule, not a vibe

Not every finding deserves the same urgency, and a review that presents forty items with no differentiation is nearly as useless as one with no findings at all, because nobody can tell which three actually need attention before the next release. Severity classification has to be a rule too, applied consistently against defined criteria — a missing owner on a production system with external connectivity is a different order of problem from a missing owner on a retired pilot nobody has touched in two years, and the classification logic should encode that difference explicitly rather than leaving it to whoever happens to be skimming the findings list. A workable approach combines the nature of the check (a security-relevant gap ranks differently from a documentation gap), the lifecycle state of the affected element, and the element's position in the dependency graph (something upstream of half the portfolio earns more attention than something at the edge), into a defined, inspectable severity, not a number that appeared from nowhere.

The discipline here mirrors the one applied to the checks themselves: severity is computed by a rule the organisation can see, adjust, and defend to an auditor, not asserted by a model that read the finding and formed an impression. A governance board that asks "why is this rated high" deserves an answer that traces to a specific, named criterion, in the same way an architect asking why a merge was resolved automatically deserves the rule codes behind a Fusion decision, described in the discussion of proof-carrying merges. Explainability is not a nicety added after the fact; it is the property that makes a rating worth acting on.

Where AI narrates, and where it has to stop

Everything described so far — scope, checks, evidence, severity — is deterministic, and it stays that way whether or not a workspace has AI enabled anywhere. What an optional AI layer adds, when an administrator has explicitly switched it on, is narration: turning a list of forty structured findings into a short paragraph a stakeholder can read in three minutes before a steering committee meeting, or drafting a plain-language explanation of why a particular finding matters in terms a non-architect audience will follow. This is the same pipeline that governs every AI-assisted feature across the product: an architect (or in this case, a review) asks, CelinQ retrieves and computes the relevant model context deterministically, and only then is an AI advisor given that already-correct context to summarise or explain, never asked to produce the findings itself.

The EA add-in's own menu already reflects this separation directly rather than blending it into one opaque button: an Analyze Selected Package command runs against the model itself, and a separate Ask CelinQ AI entry is where the optional advisory layer lives, kept as a distinct action rather than folded silently into analysis so that an architect always knows which kind of output they are looking at. Nothing about a review's findings, their evidence, or their severity changes based on whether that AI entry has ever been used, because none of it depends on AI being present, exactly the design principle worked through in more depth for other features in the piece on private model analysis.

Human architect approval

A review, however well evidenced, is not a decision, and CelinQ never treats it as one. Findings surface issues; they do not close them, downgrade a system, or trigger an automatic change to the model. Every remediation — updating an ownership field, opening a decommissioning ticket for a deprecated technology, escalating a security-relevant relationship to the security team — remains a deliberate action taken by a human architect who reviewed the finding, the evidence behind it, and decided it was correct and worth acting on. This is the same boundary that governs AI-assisted model generation across the product: the pipeline can propose, retrieve, and explain, but a canonical change to the model exists only after a human has approved it, and an ambiguous case is never auto-resolved on the review's authority alone.

This matters especially for severity ratings, which are useful precisely because they are consistent, not because they are infallible. A rule that flags a component as high-severity based on its dependency count and lifecycle state can be technically correct about the count and still be wrong about the urgency, because it does not know that the component is scheduled for retirement next month regardless of what the review says. The rule's job is to make sure that fact does not stay buried; the architect's job is to weigh it. Keeping that division explicit — the review computes and evidences, the human decides — is what keeps an architecture review a tool an architect trusts rather than a black box they have to fight.

A review that could act on its own findings would not need to be trusted, only obeyed. The whole value of keeping a human in that seat is that the review stays something an architect can argue with — and, sometimes, correct.

A worked example: preparing for a portfolio review

It is easier to judge whether this design actually helps by tracing a single review from request to outcome than by reasoning about its parts in the abstract. Picture a mid-sized public-sector portfolio ahead of its annual architecture governance cycle, where the review committee has asked for a report on every production application with an external-facing interface — roughly the kind of scope decision described earlier, expressed as an explicit filter rather than a guess at which packages happen to line up with that intent. Scope defined, the deterministic checks run in sequence: dependency structure surfaces two components sitting on every path between the public-facing gateway and the core case-management system, which the review flags as single points of failure regardless of whether anyone had previously noticed the coupling; technology standards flags a payments-adjacent service still running on a platform version the organisation deprecated eighteen months earlier; lifecycle data flags eleven elements with no status recorded at all, four of them among the externally-facing set the review is specifically meant to scrutinise.

None of those four findings required interpretation to produce — each is a specific, countable fact about specific elements, evidenced by exactly the relationships or fields that triggered it. What happens next is where the severity classification and the human approval step both do real work. The severity rule rates the single-point-of-failure finding highest, because it combines a security-relevant position in the graph with production status; the deprecated-platform finding rates lower, because the technology in question, while flagged, has no direct external exposure. An architect reviewing the report agrees with the first rating without hesitation, but overrides the second: the deprecated platform, it turns out, is scheduled for replacement in a migration already approved and funded for next quarter, a fact the model itself has no way to know because nothing in the repository records project timelines. That override is exactly the kind of judgement the review was never designed to make unilaterally, and recording it — rather than silently suppressing the finding — keeps the review's own history honest about what was flagged, what was investigated, and why a given item was deprioritised rather than ignored.

Only after the deterministic findings and the architect's judgement calls are settled does the optional AI narration layer, where a workspace has one enabled, produce the three-paragraph summary that actually goes in front of the steering committee — and that summary reads noticeably differently once it has real, evidenced findings and real human decisions to draw on, rather than being asked to invent a sense of the portfolio's health from scratch. The report the committee sees names the two single points of failure specifically, explains the deprecated-platform finding alongside the already-funded remediation plan, and lists the eleven lifecycle gaps as an action item with an owner assigned to close them before the next cycle. Every sentence in that summary traces back to a finding, an element, and in one case a human's explicit reason for treating the raw severity rating as incomplete — which is the entire point of keeping computation, evidence, and judgement as three distinct, visible steps rather than collapsing them into a single opaque verdict.

Honest limits

A rule-based, evidence-anchored review is only as good as the rules encoded into it, and no organisation starts with a complete set. Building a checklist that reflects an organisation's actual governance standards, its own technology roadmap, its own definition of "sensitive," and its own dependency thresholds is real, ongoing work, not a one-time configuration step, and a review run with generic defaults will under-perform one that has been tuned over several review cycles against real feedback about which findings mattered and which were noise. Nor does a deterministic review replace an experienced architect's instinct for the kind of structural smell that has not yet been written down as a rule — the sense that something about a design feels wrong even before anyone can articulate exactly which relationship is the problem. That instinct is real, valuable, and not something a checklist, however well built, currently captures.

What the deterministic, evidence-first design does guarantee is narrower and more dependable: whatever a review does check, it checks completely and consistently, every time, against the actual state of the model rather than a stale impression from the last time someone looked closely, and every finding it produces can be traced back to the exact elements responsible for it. That is a smaller promise than "AI reviews your architecture for you," and it is a promise CelinQ can actually keep.