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.

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

Four stages. Each one only makes sense once the one before it holds.

The last two are where the model stops being a description and starts being a check. Once deployed resources carry the identifiers the model already uses, the gap between what was designed and what is actually running becomes something you can report on — rather than something you find out about during an incident.

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

    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.