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.

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.

  • 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.

  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.