CelinQ Insights · No. 66

How CelinQ Analyses an Enterprise Architect Repository Without Sending It to an External AI

Most of what makes a model analysis useful is arithmetic and graph traversal, not a call to an external AI — and CelinQ is built so that layer never has to leave your own infrastructure.

Ask an architect what they actually want from "AI analysis" of their model, and the answer is rarely mystical. They want to know which applications have no listed owner. They want a count of elements without a lifecycle status. They want the dependency chains that fan out from a retiring platform, and they want to know whether two packages that look suspiciously similar are, in fact, duplicates. None of that requires a language model. It requires a program that can walk a graph, count things accurately, and apply a rule consistently every time it is run. The interesting question is not whether AI can do this — a sufficiently capable model probably can, in the same rough way it can do long division if you ask it nicely — but whether it should have to, and whether routing a repository's contents through a third-party service is a price worth paying for something a deterministic program does faster, more cheaply, and without ever touching the network.

This matters more than it might first appear, because the reflex in a lot of AI-adjacent product marketing is to treat every analytical task as an AI task by default, as though intelligence were a single dial you turn up until the software becomes useful. For an enterprise architecture repository — often the single most complete map of an organisation's systems, integrations, and dependencies that exists anywhere — that reflex has a cost. Sending the model, or even fragments of it, to an external service means trusting that service's retention policy, its jurisdiction, its breach history, and its incentives, none of which are things a public-sector architect or a regulated enterprise can simply wave away. CelinQ's position is that the overwhelming majority of useful analysis does not require that trust to be extended at all, and the product is architected so that the deterministic layer is not a fallback for when AI is unavailable. It is the default, capable engine, and AI is the optional layer bolted alongside it.

What "analysis" actually means for a model repository

It helps to separate three things that get bundled together under the word "analysis" and that behave very differently once you start building software around them. The first is retrieval: finding the elements, relationships, and attributes that match some criterion — every application classified as a system of record, every interface with no documented consumer, every element tagged with a particular technology. The second is computation: turning retrieved facts into numbers — counts, ratios, distributions, coverage percentages. The third is judgement: deciding whether a particular pattern of facts constitutes a problem worth an architect's attention, and how urgently. Retrieval and computation are mechanical. Given the same model and the same query, they produce the same answer every time, and that answer is either correct or it is a bug. Judgement is where interpretation genuinely enters, because "is this coupling excessive" or "is this documentation gap serious" depends on context that a rule can only approximate.

The mistake many analysis tools make is collapsing all three into a single opaque step, usually by handing the whole problem to a language model and hoping it gets the retrieval and the computation right along the way. It often does not, not reliably, and the failure mode is quiet: a model that miscounts elements, or invents a dependency that is not actually in the repository, produces an answer that reads exactly as confidently as a correct one. CelinQ keeps the three steps separate on purpose. Retrieval and computation happen in code that touches the canonical model directly — the same domain layer that underlies synchronisation and semantic history — and produces results that are, by construction, traceable to specific entities. Judgement, where it is offered at all, is layered on top as an optional, clearly labelled interpretation of numbers that were already correct before any AI was involved.

The deterministic core: rules, graphs, and statistics

The foundation of private analysis in CelinQ is the same canonical model that already underlies synchronisation and conflict resolution. Every element, relationship, attribute, and tagged value that flows through a workspace is represented as typed, addressable data, not as an opaque blob of proprietary file format. That representation is what makes deterministic analysis practical in the first place: a rule engine does not need to parse a `.eap` file or reverse-engineer Sparx's internal schema, because the model is already available as structured data through CelinQ's own typed model and query surface — the REST and gRPC ModelService that expose workspaces, revisions, and model content in a form built for exactly this kind of programmatic access.

On top of that structure, several distinct kinds of deterministic analysis fall out naturally. A rule engine evaluates fixed conditions — an element of a given type must have an owner, an interface must have at least one consumer, a technology tag must appear on an approved list — and reports every violation with the specific element it belongs to. A graph analysis walks relationships to answer structural questions: which elements are reachable from a given starting point, where do cycles exist, which nodes sit on every path between two subsystems and therefore represent a single point of failure. And a statistics layer aggregates the results of the first two into counts, percentages, and distributions — how many applications have no lifecycle status, what fraction of interfaces are undocumented, how coupling is distributed across the portfolio. None of these three layers asks a question that depends on interpretation. They ask questions with objectively correct answers, and they are the layer that should run first, run cheaply, and run without external dependencies, regardless of whether AI is enabled anywhere in the workspace.

Dependency analysis without a single API call to anywhere

Dependency analysis is where the deterministic case is easiest to make concretely, because dependency questions are graph questions almost by definition. "What depends on this database" is a traversal from one node outward along relationship edges of the right type. "What is this application's full upstream chain" is the same traversal run in the other direction. "Are these two subsystems connected only through a single shared component" is a question about cut vertices, a well-understood problem in graph theory that has nothing to do with language modelling. CelinQ's model and query API is built to answer exactly this class of question directly against the canonical model that a workspace already holds, using the same relationship data that Fusion itself reasons about when it decides whether two changes to a model genuinely collide, described in more detail in the discussion of semantic synchronisation.

Because this kind of traversal runs entirely against locally or server-held structured data, it has no reason to leave the workspace's own infrastructure. A dependency map that takes seconds to compute against a graph of a few thousand elements does not become faster or more accurate by being phrased as a prompt to a remote service; it becomes slower, because now there is a network round trip and a rate limit involved, and it becomes less trustworthy, because now there is a step in the pipeline that cannot be inspected the way a traversal algorithm can. Dependency analysis is not a trivial problem in practice — real repositories have messy, inconsistent relationship data, and getting the traversal rules right for a given organisation's conventions takes real engineering — but the difficulty lives in getting the deterministic logic correct, not in acquiring intelligence from outside the building.

Model quality checks as arithmetic, not judgement

A related instinct worth resisting is treating "model quality" as inherently subjective, and therefore as inherently a job for AI. Some of it is subjective — whether a diagram communicates its intent clearly to a non-architect stakeholder is a real question and a hard one. But a large share of what people mean by model quality in practice is closer to a spreadsheet audit than to an aesthetic judgement: does every element have the fields the governance process requires, does every relationship type appear where the modelling conventions expect it, are naming patterns followed consistently, is there a lifecycle status recorded for elements the organisation has decided must carry one. These are checks with a correct answer, computable by walking the model and comparing what is present against a defined expectation. A companion piece on measuring architecture health as a quality score goes further into how these individual checks aggregate into a single number worth tracking over time, but the underlying point is the same one made here: the checks themselves are rule evaluation, not interpretation, and they belong in the deterministic layer regardless of whether a workspace has AI enabled at all.

This distinction has real practical weight: it changes what an organisation can promise its own governance and security functions. A rule that says "every application must have a documented owner" can be run against a workspace every night, with results that are reproducible, auditable, and explainable to a compliance reviewer who wants to know exactly why a given element was flagged. If that same check were performed by asking a language model to "review this model for ownership gaps," the answer would depend on prompt wording, on model version, on sampling variance, and on whatever the model happened to notice on a given run. For a check that is going to feed into a governance dashboard or an audit trail, determinism is not a nice-to-have. It is the entire point.

Where AI genuinely helps — and where CelinQ draws the line

None of this is an argument that AI has no place near model analysis. It has a real, useful, and deliberately narrow place: turning correct but dense output into language a human can absorb quickly, and helping an architect phrase a question without having to know the underlying query syntax. The pipeline CelinQ uses when AI is involved anywhere in the product follows the same shape regardless of which feature triggers it — an architect asks a question or requests a review, CelinQ retrieves the relevant model context deterministically, an AI advisor is given exactly that retrieved context and asked to summarise or explain it, and the human reviewing the output can trace every claim back to the underlying model facts that were retrieved before the AI ever saw them. AI never queries the repository on its own initiative, never writes to it, and never becomes the source of a fact that was not already established by the deterministic layer underneath it. The companion piece on AI for Sparx Enterprise Architect covers this pipeline for model generation; for analysis the same discipline applies in reverse — data flows out through a controlled, auditable retrieval step before any language model touches it, never the other way round.

The line CelinQ draws is therefore not "no AI" but "AI as an optional, clearly labelled interpreter of facts that were already correct." An architecture review might use an advisor to draft a short narrative summary of forty rule violations into three paragraphs a stakeholder can read in a meeting. A quality dashboard might use one to suggest, in plain language, what a sudden drop in ownership coverage probably means. In both cases the number, the count, the specific flagged element — the thing that actually matters for governance — was produced by deterministic code before the advisor was ever consulted, and the advisor's output is presented as exactly what it is: a generated explanation, not a new fact.

AI disabled mode and what stays working

Because the deterministic layer is architecturally independent of the AI layer, disabling AI entirely changes nothing about what a workspace can do with its own model data. This is a design decision that shows up concretely in the product rather than as a marketing claim: AI in CelinQ is optional and off by default, and none of synchronisation, Fusion's conflict detection, or the underlying model and query API depends on it in any way. An administrator who never opens the AI settings screen, or who opens it and leaves every capability toggle switched off, still has the full deterministic analysis surface available — rule evaluation, graph traversal, statistics, the model and query API — because that surface was never built on top of the AI layer to begin with. It was built first, as the actual product, with the AI advisor added later as an optional interpreter sitting alongside it.

This separation is visible in the Control Plane itself, where AI administration is its own dedicated area rather than a switch buried inside a feature. An administrator can review exactly what is configured, which capabilities are opted into individually, and confirm the connection before anything is enabled — and can just as easily confirm that nothing is enabled at all.

Customer-hosted models and the air-gapped case

For organisations that want an interpretive layer eventually but cannot accept any external network dependency at all — a defence integrator, a ministry running a genuinely isolated network, a bank whose security posture forbids any outbound call from a system holding architecture data — the relevant question is not "does CelinQ call OpenAI" but "does the architecture assume an external provider is the only option." It does not. The advisor that CelinQ's AI layer talks to sits behind a provider abstraction rather than a hard-coded dependency on a single vendor, which is the pattern that makes a customer-hosted or locally-run model a realistic direction rather than a hypothetical one: the interface the rest of the system talks to does not change based on where the model actually runs. Today the shipped default routes through OpenAI when an administrator explicitly enables it; extending that same interface to a model an organisation runs on its own infrastructure is the kind of change that can be made without touching Fusion, synchronisation, or the deterministic analysis layer at all, precisely because none of those layers were ever coupled to a specific provider.

The air-gapped case is, in a sense, the purest test of the whole architecture, and it is one the deterministic layer already passes on its own terms. A workspace with no route to the public internet can still run every rule check, every graph traversal, every statistic, every quality computation described above, because none of it requires reaching outside the server that already holds the model. What an air-gapped deployment cannot do — today, with the shipped provider — is call out to a hosted AI service, and it should not be able to, because that is precisely the property an air-gapped network is designed to guarantee. Whether a future customer-hosted model sits inside that same boundary is a deployment decision for the organisation to make, not a constraint the deterministic core imposes; the core simply does not need the answer to keep working.

The right measure of a private analysis feature is not how impressive its output sounds. It is how confidently a security reviewer can say, in writing, exactly where the data went — and for the deterministic layer, the honest answer is always: nowhere.

Data sovereignty as an architectural property, not a policy promise

"Sovereign" gets used loosely in vendor material, often to describe a checkbox rather than a structural fact. In CelinQ it names a real deployment mode: an administrator can force AI off at the configuration level in a way that cannot be re-enabled from the console afterward, while every core capability — synchronisation, Fusion, users and access, audit, monitoring, revisions, backups, the model and query API — remains fully available. That asymmetry is the whole point. Sovereignty here is not "we promise not to send your data anywhere unless you ask us to." It is "the mechanism that would send data anywhere is switched off at a level the product itself enforces, and turning it back on is not something a compromised session or a careless click can do."

The same discipline shows up in how the optional AI layer is built for organisations that do choose to enable it, which matters because sovereignty and AI-enabled operation are not opposites; an organisation can run AI features deliberately and narrowly rather than treating the choice as all-or-nothing. Per-workspace policy controls exactly which fields may ever be included in a request to an advisor — entity names and the specific conflict values needed to advise on a decision, by default, with notes, tagged values, and the surrounding model neighbourhood excluded unless an administrator deliberately widens the policy, and user names redacted regardless. An administrator can preview exactly what would be sent before switching anything on. Every external call that does happen is written to an audit log with its timestamp, actor, workspace, feature, and outcome — never the key, never the raw prompt or model content. None of that is a promise resting on trust in a vendor's intentions. It is a set of mechanisms an organisation's own security function can inspect, test, and hold the product to.

What this costs you

It would be dishonest to present the deterministic-first design as free of trade-offs, because no real architecture is. A rule engine only catches what it has been told to look for; it will not notice a genuinely novel structural problem that nobody thought to encode as a rule, in the way a sufficiently capable AI reviewer occasionally might, by pattern-matching against a much broader base of examples than any one organisation's ruleset encodes. Deterministic checks are also, by nature, conservative — a check for missing ownership fields will faithfully report every element that lacks the field, even when a human would immediately recognise half of those as false positives because the element is clearly out of scope for that governance rule. Tuning rules to an organisation's actual conventions takes real, ongoing work, and it is work a purely AI-driven analysis would appear to skip, at the cost of consistency and explainability it never really had.

The honest trade CelinQ makes is this: it accepts the labour of building and maintaining explicit rules, explicit traversals, and explicit statistics, in exchange for analysis that is reproducible, inspectable, and safe to run against a repository that may never be allowed to leave the organisation's own infrastructure. Where an optional AI layer is added on top, its job is deliberately narrow — explain, summarise, phrase — and it is switched off by default, gated by policy, and fully absent under sovereign mode, precisely so the deterministic core it sits beside can keep working exactly as well with it gone. For the kind of repository enterprise architects actually maintain — the map of systems a public body or a regulated enterprise depends on — that trade is the design decision that makes the analysis trustworthy enough to act on in the first place, not a limitation to apologise for.