CelinQ Insights · No. 76

Can CelinQ Turn an Existing EA Repository into a Searchable Architecture Knowledge Base?

Most of what a knowledge base needs is already sitting inside a synchronised Enterprise Architect repository; what changes is how you ask for it.

Every architecture practice eventually accumulates a version of the same question, asked in a slightly different form every time. A new hire wants to know which system owns customer consent data. A programme manager wants to know whether anything downstream still depends on a mainframe interface that is scheduled for retirement. An auditor wants to know who approved the last change to a particular integration pattern, and when. The honest answer, in most organisations, is that the information exists somewhere, spread across a Sparx Enterprise Architect repository, a handful of wiki pages that were current eighteen months ago, a spreadsheet someone maintains from memory, and the recollection of the one architect who has been there long enough to remember why a decision was made. Getting to the answer means a search across all of those places at once, conducted by a human who happens to know where to look. That is not a knowledge base. It is a scavenger hunt with a subject-matter expert as the only reliable index.

The appeal of turning an EA repository into something you can genuinely query is obvious, and it is worth being precise about what would actually be required, because the honest answer is more interesting than the marketing version. A model already contains an enormous amount of structured fact: elements with types and names, relationships with direction and semantics, tagged values, notes, stereotypes, package hierarchies, and a revision history describing how all of it came to be. The question is not really whether the information exists. It is whether it is organised in a form that can be searched and traversed reliably, whether the answer you get back is grounded in something you can verify, and whether asking the question is something a non-modeller can actually do without learning the tool first.

What a synchronised workspace already gives you

CelinQ's starting point is not a blank slate. Because every architect's local Enterprise Architect repository synchronises through the background agent into a canonical workspace on the CelinQ Server, that workspace already holds a single, current, structurally coherent representation of the model, independent of which laptop last touched it. This matters more than it sounds, because a search or a query is only as good as the thing it searches. A knowledge base built by periodically exporting a repository to a document store is a knowledge base of what the model looked like at export time, drifting further from reality with every day that passes between exports. A knowledge base built on a workspace that is kept current by an always-running synchronisation layer is a knowledge base of the model as it actually is, which is a different and much more useful thing.

The workspace is also already a graph, not a pile of records. Elements connect to other elements through typed relationships; packages nest inside packages; diagrams reference the elements they display; tagged values attach structured metadata to almost anything. Answering "which applications depend on the customer database" is not a full-text search problem at all — it is a graph traversal, starting from the element representing the database and walking dependency relationships outward, filtering by element type as you go. That kind of question was never going to be answered well by a keyword search over exported documentation, because the answer depends on the shape of the graph, not on which document happened to mention the right words. A synchronised, structurally faithful workspace is precisely the substrate that traversal needs, and CelinQ already maintains it for reasons that have nothing to do with search: Fusion needs it to merge safely, and the Control Plane needs it to report accurately.

The revision history adds a second dimension that a document-based knowledge base cannot easily reproduce: time. Every synchronised change is recorded in order, with an author and a timestamp, which means a question like "when did this interface last change, and who changed it" is not a matter of asking around. It is a lookup against a structure that was designed, from the outset, to be an accurate account of what happened, because the same history is what makes Fusion's merges auditable and what makes disaster recovery possible after a restore. The proof-carrying merge record that explains why an automatic merge was safe and the revision log that answers "who touched this last" are drawing on the same underlying discipline: nothing in the canonical workspace happens without being written down.

Deterministic search: the part that needs no AI at all

It is worth being unusually explicit about how much of "searchable knowledge base" can be delivered with plain, deterministic engineering, because this is the part that regulated organisations care about most and the part that vendors tend to gloss over on the way to a more exciting AI story. A query engine that lets you filter by element type, search names and stereotypes, traverse relationships to a configurable depth, and filter by tagged-value fields is not artificial intelligence in any sense. It is indexing and graph traversal, the same category of engineering that has powered structured search for decades, applied to a workspace that already has the structure to make it useful. This layer answers precisely and only what the model actually contains. It does not interpret, it does not summarise, and it does not guess. If an element has no owner recorded, it reports that the owner field is empty rather than inferring one from context, because inference is exactly the thing a deterministic layer should refuse to do.

This distinction matters because it draws a hard line between two very different kinds of trust. A deterministic query returns a set of model facts and the exact path used to find them: this application, connected to that database, via this dependency relationship, last updated in this revision. You can verify every step of that answer by opening the model yourself and following the same path. There is nothing to take on faith. That is the foundation any credible knowledge base has to be built on, and it is the foundation CelinQ already has, because the graph and the revision history it relies on exist independently of any AI feature and would exist even in a workspace where AI has never been switched on.

Where a natural-language layer earns its place

The deterministic layer is precise, but precision has a cost: you have to know the vocabulary. "Show me elements of type Application Component with a dependency relationship to the element named Customer Database, filtered to tagged value Status equals Active" is exactly what the underlying query needs, and it is not how a programme manager thinks or talks. The gap between what a person wants to know and the structured query that would answer it is where a natural-language layer has a genuine, well-defined job to do: translate the plain-English question into the structured query the deterministic engine can execute, run it, and present the result with the model elements it came from clearly cited.

This is deliberately a narrow job, and the narrowness is the point. The AI does not answer the question from its own knowledge, because it has no reliable knowledge of your specific model beyond what the query returns; it does not compose a fluent-sounding paragraph and hope the facts inside it are correct. It converts intent into a query, and the query is what actually touches the model. The answer a user sees is the deterministic result, presented with links back to the specific elements, relationships, and tagged values that produced it — the same discipline the AI-assisted conflict-resolution recommendations follow when they explain why a merge needs a decision, and the same discipline that keeps AI out of the write path everywhere else in CelinQ. A knowledge-base query is, structurally, no different from any other AI-touched operation in the product: the model asks for what a user meant, CelinQ decides what that translates to deterministically, and the answer a person reads is always traceable back to the graph rather than invented by a language model filling in gaps it cannot actually see.

A knowledge base you cannot verify is not a knowledge base. It is a plausible-sounding guess with good production values. The whole value of a natural-language layer over a model is that it points you at the facts rather than replacing them.

Hallucination — an AI stating a confident fact about the model that is not actually true — is the specific failure mode this design is structured to make impossible for the class of question it answers, because the answer is always the output of a deterministic query against the real graph, never free text generated about the model from a language model's general knowledge. If the query returns nothing, the honest answer is that nothing was found, not a fabricated element that sounds plausible. That single design choice is the difference between a feature an architect can rely on in front of a client and a feature that quietly erodes trust the first time it gets something wrong.

What this looks like for the questions people actually ask

Return to the questions this article opened with. "Which applications depend on Oracle" resolves to a relationship traversal from every element tagged or typed as depending on the named technology, filtered to application-layer elements, and the answer lists the specific applications with the specific relationships that connect them. "Which systems have no owner" resolves to a tagged-value filter across the application inventory, checking an ownership field for emptiness, and the answer is a list you can hand directly to a governance process rather than a vague impression that ownership data is "probably incomplete somewhere." "Show me everything connected to the payment service" is a bounded graph walk from a named element, returned with the relationship types intact so the difference between "depends on" and "is documented by" is not lost in translation.

A fourth example is worth including because it is the one that most often surfaces uncomfortable truths: "which interfaces have not been touched in two years and still carry an active status." That question joins a revision-history lookup to a tagged-value filter, and it routinely finds the handful of integrations that everyone assumed someone else was watching. Nobody has to remember to ask it manually, and nobody has to trust a colleague's recollection of when a system was last reviewed, because the revision log does not forget and does not round a date in its own favour.

None of these answers requires the AI layer to know anything about payments, ownership conventions, or Oracle. It requires the deterministic engine to know the graph, and it requires the natural-language layer to correctly translate a plain question into the graph operation that answers it. Separating those two responsibilities is what makes the whole thing trustworthy: the part that could hallucinate is kept as far as possible from the part that actually touches the model, and the part that touches the model executes a query and reports the result rather than generating text.

Permissions travel with the query, not around it

A searchable knowledge base is only a good idea if it respects the same access boundaries as the repository it searches, and this is a place where naive implementations quietly go wrong. It is not enough for a query interface to be "read-only" in a general sense if it can still surface the contents of a restricted workspace to someone who was never granted access to that workspace in the first place. CelinQ's answer is that every query — deterministic or natural-language-assisted — runs inside the same role-based access model that governs everything else in the Control Plane. A user's workspace roles determine what the query engine is even allowed to see before it starts traversing, not as a filter applied afterwards to results that were already computed. Someone with read access to one workspace and no access to another cannot use a well-phrased natural-language question as a side door into data they were never meant to see, because the underlying query never reaches that data in the first place.

This matters especially for the natural-language layer, precisely because plain English is good at describing what you want without regard for organisational boundaries. "Show me everything connected to the payment service" is a perfectly reasonable sentence regardless of which workspace the payment service happens to live in, which is exactly why the boundary enforcement has to sit underneath the language layer rather than depend on it to behave. The AI never decides what is permitted. It proposes an interpretation of the question; the deterministic engine, working within the caller's actual permissions, decides what can be answered.

What gets logged, and what does not

Every AI-assisted feature in CelinQ writes an audit event when it is used — who asked, when, which feature, which provider, whether the call succeeded — without recording the API key or the full prompt and model content, following the same discipline documented for AI-assisted conflict recommendations and model analysis. A knowledge-base query follows the identical pattern: the fact that a question was asked, by whom, and against which workspace is part of the record; the literal free-text phrasing a person typed is not retained as a permanent artefact tied to their identity beyond what is needed to service the request. For an organisation with any sensitivity about who is asking what about which parts of the architecture, that distinction between operational logging and content retention is not a footnote. It is the difference between an audit trail that satisfies a security review and a transcript that becomes its own liability.

What is a real feature today and what remains a direction

It is worth stating plainly what exists and what does not, because a knowledge-base pitch is exactly the kind of claim that invites exaggeration. The canonical workspace, the relationship graph, the revision history, and the role-based access control that governs all of it are real and already load-bearing for synchronisation and Fusion, independent of any search feature. A structured, deterministic query capability over that graph — filtering by type, traversing relationships, searching tagged values, walking revision history — sits naturally on top of infrastructure CelinQ already operates for other reasons. A natural-language layer that translates plain questions into those structured queries follows the same governed, provider-abstracted, audited pattern as CelinQ's other optional AI features, off by default and enabled per workspace by an administrator.

What is a direction rather than a shipped feature today is the fuller ambition implied by the phrase "architecture knowledge base": a dedicated full-text search index spanning notes and documentation, semantic search that finds conceptually related elements without exact keyword overlap, and export formats built specifically for knowledge-management tooling outside CelinQ. These are reasonable things to want, and the graph-and-revision foundation this article describes is the right foundation to build them on, but describing them as available today would be exactly the kind of overreach this series tries to avoid. The honest framing is that the deterministic and natural-language query layers over the existing model graph are real and usable now; a broader indexed knowledge-management layer is a pattern the architecture supports, not a feature to point at in a demonstration and claim as finished.

The trust question underneath the feature question

It is tempting to evaluate a knowledge-base feature purely on convenience: does it save time, does it answer the question faster than opening the model and clicking through packages. That is a fair test, but it is not the whole test, because a knowledge base that is fast and wrong is worse than no knowledge base at all — it replaces the honest discomfort of not knowing with the false comfort of an answer that happens to be incorrect. The design choice that matters most here is not the phrasing of the natural-language layer or the speed of the traversal. It is the decision to make every answer traceable back to a specific model fact, so that "trust the tool" is never actually required. You can always ask CelinQ to show its working, and the working is always a query against the real graph, not a summary generated from a language model's impression of what an architecture like this probably looks like.

That discipline is the same one running through the rest of this AI series: natural language reaching the model only through a validated, auditable path, never by writing directly to repository data; deterministic analysis available as a complete path with AI switched off; and every AI-assisted answer grounded in evidence a human can independently check. A knowledge base built on those principles earns the right to be trusted gradually, the same way any new source of information earns trust in an engineering organisation — not by asserting it, but by being checkable every time someone bothers to check.

Honest limits

None of this turns Enterprise Architect into a general-purpose enterprise search engine, and it should not try to. The graph and revision history that make deterministic queries reliable are specific to what has actually been modelled; a system that was never documented in EA does not become discoverable just because CelinQ can search everything that was. The natural-language layer is only as good as the translation from plain English to a structured query, and ambiguous or badly scoped questions will sometimes produce a narrower or broader answer than the person meant, which is exactly why every answer shows its evidence rather than asking to be trusted on tone. And a workspace with genuinely poor modelling discipline — missing owners, absent relationships, undocumented interfaces — will surface exactly that poverty when queried, because a query engine can only report what is actually there. It cannot invent the ownership record nobody ever created, and it should not try to; reporting the gap honestly is more useful than papering over it with a plausible-sounding guess. A knowledge base built this way will always be as good, and no better, than the modelling discipline of the team that fed it, and that is a feature of the design, not a flaw in it.