Stop rebuilding architecture project by project.

Sparx Enterprise Architect and Archi are both excellent at what a single project needs. The trouble starts one project later, when a repository was built for one pair of hands at a time, or when the next project quietly re-models an application, a capability or a service that another project already described — under a slightly different name. CelinQ removes both walls without asking anyone to leave the tool they already know.

Watch it work

The clearest way to explain CelinQ is to show the actual sequence a change goes through — not an abstract diagram of "AI" and "merging," but the real path from a plain-language description to a governed model change. No actors, no staged data: what's below is the real product, doing the thing.

How CelinQ works

CelinQ sits alongside Enterprise Architect and Archi rather than replacing either. Each architect keeps working in their own local repository — fast, responsive, and usable with or without a network connection. A small companion service watches that local repository and keeps it in step with a shared workspace on a central CelinQ server that your organisation runs. Save in EA or Archi, and your changes travel to the server; when a colleague's changes arrive, they appear in your model. No file locks, no waiting your turn, no manual export and import — and no new modelling client to learn.

One workspace, not one file per project

Project by project, both Enterprise Architect and Archi practices tend to fragment the same way: Project A models an application because nothing describes it yet, and a year later Project B models the same application again, under a different name, because nobody knew Project A's file existed. Every individual file can be perfectly correct. Across projects, the organisation ends up with several representations of the same enterprise.

CelinQ's answer isn't "merge every file into one undifferentiated repository." Projects keep their own views, their own pace, their own ownership. What they stop doing is re-describing an application, capability or service that the organisation already knows about — because that knowledge now lives in one shared, governed workspace instead of scattered across independent project files.

AI proposes. You approve.

CelinQ includes an optional design assistant you reach from Enterprise Architect's own menu — Ask CelinQ AI, Analyze Selected Package, Generate into Selected Package — without switching to another window. Select a package, describe in plain language what you want — "add a Fraud Check service that guards the Claims Orchestrator" — and the elements and relationships are drafted directly into that package as real model content, previewed before anything is applied. Ask the other way round and you get a grounded reading of the part of the model you selected, with answers that name the actual elements involved rather than a generic summary. The fuller AI-for-Sparx-EA story → For requirements-shaped input specifically — a project brief, a stakeholder email, a rough requirement — see the fuller requirements-to-architecture story →

This is the trust boundary that matters most: an LLM never gets unrestricted write access to a governed architecture. Every proposal is validated deterministically, previewed, and requires a person to approve it — edited, rejected, or accepted as-is — before it becomes a real, synchronised, versioned model change. Missing information stays a visible, named gap instead of being quietly invented into false precision.

The request starts on your machine, but the call to the AI provider never does: the add-in never talks to a provider directly. It hands the question to the local CelinQ Connect agent, which relays it to the CelinQ Server — the same server holding your workspace — and only that server calls the provider, and only if an administrator has switched the capability on. Nothing about this changes what stays local: your model, your merges and your history never depend on it. Sovereign and customer-hosted deployment patterns →

Your tracker manages the work. Your architecture should explain what satisfies it.

Jira and Azure DevOps are genuinely good at what they do: a requirement's status, its owner, its sprint. Neither can tell you which system actually satisfies that requirement, which service implements it, or what else would break if it changed — and they were never meant to. That's an architecture question, and it can only be answered by a model that is current enough, and shared enough, to actually ask.

CelinQ doesn't replace your tracker. It answers the question the tracker was never built to answer: deterministic dependency queries — what depends on this, what does this depend on — run directly against the shared architecture, not against whichever project file you happen to have open. How shared context makes these questions answerable →

CelinQ Fusion: merging you can trust

Once several architects, and AI-assisted proposals, are all touching the same shared architecture, the obvious next question is how you keep it trustworthy. The heart of CelinQ's answer is its merge engine, Fusion. Most tools that claim to support collaboration fall back on "last write wins" — whoever saves most recently overwrites everyone else. That is not merging; it is data loss with good manners. Fusion instead performs a proper three-way reconciliation: it knows the common ancestor of two versions and can therefore tell the difference between a change one person made and a change the other made, combining both when they do not overlap.

It works at the level of individual model facts rather than whole diagrams or packages, so two architects editing different attributes of the same element, or different elements in the same package, simply both succeed. When two people genuinely change the same thing in incompatible ways, Fusion does not guess. It preserves both versions, marks the point of contention, and lets a human decide — with full context about what each side intended. Deletions are handled with tombstones rather than silent disappearance, so a colleague's in-progress work is never destroyed by someone else's cleanup. The whole process is deterministic: the same inputs always produce the same result, which is what makes it safe to trust and possible to audit.

What you get

Technical specifications

Works with	Sparx Enterprise Architect (in-process add-in plus a companion sync service), existing .eap/.eapx repositories used as-is; and Archi, the free ArchiMate modelling tool — both clients synchronise through the same server and Fusion merge engine.
Collaboration model	Local-first: each author edits an independent local repository; changes synchronise to a shared central workspace.
Merge engine	CelinQ Fusion — deterministic three-way merge at model-fact granularity, with tombstones, conflict isolation and reproducible results.
Sync	Smart Sync with adaptive cadence (responsive during active collaboration, quiet when idle), plus manual and fixed-interval modes.
AI assistance	Optional, off by default. Requirements/intent to proposed model elements and relationships; every proposal previewed and human-approved before it lands. Provider configurable (OpenAI, Azure OpenAI, Anthropic, or any OpenAI-compatible self-hosted endpoint); sovereign mode removes it entirely.
Authentication	Personal access tokens today (PBKDF2-SHA256 hashed, shown once at issue). OIDC SSO — Entra ID, Keycloak, Okta — is the planned next step; the role model already fits it.
RBAC	Workspace roles, strictly ordered: Viewer < Editor < Administrator < Owner, enforced server-side on every call. Azure AD/Entra-issued roles are on the OIDC roadmap above, not shipped yet.
History & governance	Ordered revision history per workspace; change review; a full audit log of user, token, membership and workspace actions.
Server	Runs on your own infrastructure. Storage on SQLite for small teams or PostgreSQL for larger deployments.
Security	Token authentication (PBKDF2-SHA256, constant-time compare), encrypted transport with certificate pinning, workspace authorization re-checked on every call — not just at login.
API surface & gateways	gRPC for sync, REST for the Control Plane and admin API. CelinQ has no built-in API gateway — the documented guidance is to deploy it behind your own reverse proxy or API gateway (rate limiting, WAF) when exposed beyond a trusted network.
Data residency	Fully sovereign. No dependency on any external service for core collaboration or merging.

Honest about what's shipped versus planned: Entra ID/Azure AD sign-in and an API gateway are both on the roadmap, not in the product today. What's live is documented above — token auth, workspace RBAC, and a server that expects to sit behind your own network edge.

Start with five

If you read nothing else, these five cover the core of what makes CelinQ different.

Questions we actually get asked

Request a trial

Not a self-service signup, and not a sales call you have to book just to see the product. Tell us roughly what you'd want to evaluate; a person reviews the request and, if it's a fit, provisions a dedicated trial environment — typically 14 days, seeded with a scenario matching what you asked about.

Name Work email

Organisation Team size

Modeller Enterprise Architect Archi Both What do you want to evaluate? Shared architecture across projects Requirements → architecture Collaboration / synchronisation Fusion / conflict handling All of the above

Anything else worth knowing? Request a trial

Reviewed by hand, usually within a couple of business days. No obligation, no automatic charge, ever.

Get in touch