One model.
Every diagram derived from it.

Kanoniq stores your architecture as a single canonical model — elements and relationships with stable identity. Views reference that model instead of copying it, so no diagram can quietly disagree with another.

An isometric plane of connected elements, with solid structure and dashed derived links

model as code

platform storefront "Storefront" {

  component checkout "Checkout"
    : backend

  component payments "Payments"
    : backend {
    derived httpApi payments-api
  }

  component orders "Orders"
    : backend {
    derived httpApi orders-api
  }

  checkout -> payments-api over http
  payments -> orders-api   over http
}

canonical model

Three authored elements: Checkout, Payments and Orders Checkout Payments Orders

derived views

Two generated views: a layered application view and an entity view Order Payment
Kanoniq parses the .kq source into one canonical model, then derives views from it. Solid outlines are authored. Dashed outlines are derived — Kanoniq draws them, and they hold no data of their own.

Why this exists

Architecture models drift out of date. Not through neglect — through how the tools are built.

The same component sits in five diagrams. Change it once and four are wrong — so people stop trusting all of them and read the code instead.

In most tools the picture is the record — so the truth is whichever one you opened last.

What Kanoniq does

  • One canonical model

    Every element keeps a persistent identity. Rename it, move it, export it to another tool — the identity holds, and every view follows it.

  • Views you don't draw

    Layered application views, data flows and entity diagrams are generated from the model. Hand-drawn views are still yours to make; they reference the same elements rather than copying them.

  • Plain files in git

    Author visually or as code. The model is text you can branch, diff and review alongside the system it describes — it lives in your repo, not ours, parsed and rendered locally with nothing sent anywhere to draw a diagram.

Why it's opinionated

A modeling language with no opinions is a data format. Kanoniq takes positions.

An Ecosystem groups, it doesn't behave. A Domain Object and a Data Entity are different things, kept apart on purpose. A messaging exchange always has a Channel between two components — never optional, whether you draw it or Kanoniq derives it. Each of these is a decision, not a default: recorded and dated.

Rendering a diagram from a graph is not hard. Deciding which relationship becomes an ArchiMate assignment versus a realization, when two elements collapse into one view and when they don't — that takes judgment a generic diagramming tool doesn't have. Kanoniq's views are opinionated because getting ArchiMate right means committing to an interpretation, not because opinions are cheap to add.

Every rule in the metamodel is written down with why it exists, not just what it does. A tool trusted with how a company thinks about its own systems should be able to show its work — and expect its decisions to be argued with, not just adopted.

The model is a file you can read

The Northwind example: two ecosystems, sixteen components and every connection between them, in one file of 185 lines.

Declarations are highlighted, and each reference links to the declaration it points at — the same identity every view uses. derived marks what Kanoniq generates rather than what was written by hand, underlined the way the diagrams draw it.

ecommerce.kq, lines 68–90 of 185

68 /// Holds a basket for a signed-in shopper or an anonymous session, and
69 /// reprices it on every change.
70 component basket-service "Basket Service" : backend tech "Go" {
71 derived httpApi basket-api "Basket API"
72 }
73
74 web-shop -> storefront-bff-api over http
75 mobile-shop -> storefront-bff-api over http
76
77 storefront-bff -> catalogue-api over http
78 storefront-bff -> search-api over http
79 storefront-bff -> basket-api over http
80 storefront-bff -> order-api over http
81
82 /// Pulls product data to rebuild the index. Not on the shopper's read path.
83 search-service -> catalogue-api over http
84
85 web-shop realizes browse-catalogue
86 web-shop realizes manage-basket
87 mobile-shop realizes browse-catalogue
88 search-service realizes search-products
89 basket-service realizes manage-basket
90 catalogue-service realizes shop-merchandising
  • declaration
  • derived
  • relationship
  • kind and transport
  • name
Read the whole file →

Edit where you already write code

The VS Code extension colors a .kq file as you type and draws the diagram beside it, kept live on every save.

Get the VS Code extension →

Take the model out again

Export is one-way on purpose. Kanoniq holds the model; other tools receive a copy of it, and nothing writes back into it.

That constraint is what keeps the model canonical. A two-way sync means two things can both claim to be right, and reconciling them is a problem nobody solves well. Export instead produces a copy that is correct at the moment it is written, carries the identifiers it came from, and makes no claim to be the source.

A solid-outlined model of nested elements on the left, with dashed arrows leading to three dashed-outline panels: a grid of linked nodes, a hierarchy of typed shapes, and a flow of boxes joined by arrows.
KQ
  • ArchiMate
  • BPMN
  • ERD

  • ArchiMate specified, being built

    Open Exchange Format — model namespace 3.0, validated against the 3.1 schema, which is the pairing Archi itself emits and accepts. Every element and relationship carries its Kanoniq identifier, so the model can still be matched back after a receiving tool has renumbered everything.

  • BPMN stage 2

    Data flows in the notation process people already read, projected from the same elements rather than drawn a second time.

  • ERD stage 2

    Entities projected from the canonical model and bound to the components that own them — physical-ish, not a database schema.

Where this is going

A model is a claim about a system. Today, checking it is manual.

Someone checks the model against the codebase, the infrastructure, the deployed reality — and updates one or the other. The last two stages close that loop: once deployed resources carry the identifiers the model already uses, drift becomes something Kanoniq reports on, rather than something you find out about during an incident. Discovery and drift only mean something once there is a canonical model to drift from — which is why that comes first.

Two halves: on the left, scattered and broken blocks in disarray; on the right, the same kind of blocks arranged in an ordered ring around a central node, connected by clean lines.

  1. Canonical model in progress

    The metamodel, the model-as-code DSL, and models stored as plain files in git.

  2. Projections in progress

    The layered application view generated from the model, then BPMN, ERD and IAM projections of those same elements.

  3. Discovery

    Bind the designed model to deployed infrastructure by tagging cloud resources with the identifiers the model already uses.

  4. Drift

    Report where the running system has diverged from the model, what a proposed change would touch, and how far the blast radius reaches.

Kanoniq is early. The metamodel, the DSL and the first views are still being specified.

This page is where the work lands — the specifications, the views, and the tool itself, as each one is finished.

Try the demo →