Typed system entity
A service, database, network, actor, deployment target, or other addressable element. Identified by a
stable unique-id within the document.
- unique-idstring
- node-typeenum
- namestring
- descriptionstring
CALM is an open-source, JSON-based meta-schema for defining system architectures as code — versioned, validatable, and composable alongside the implementations they describe.
CALM turns architecture into a versioned JSON document that travels with the code, validates in CI, and binds compliance controls to the relationships they govern.
architecture.calm.json, validated against a shared meta-schema.calm validate runs next to your unit tests; non-conforming changes fail the build, not the next ARB.@finos/calm-cli from npm, render with CALM Hub, and ship a docs site with calm docify.For three decades, architecture artefacts have lived in Visio files, Confluence pages, and PowerPoint decks. Implementation has lived in Git. The two have drifted apart at every release. CALM closes that gap by treating the model itself as a versioned JSON document that travels with the source.
Every Tier 1 institution has the same problem. A reference architecture is approved by a board, drawn in Visio, attached to an ADR, and within two sprints it no longer reflects the deployed estate. Reviews happen in meetings that produce no machine-checkable output. Compliance evidence becomes a forensic exercise — piecing together screenshots, change tickets, and runbook entries to satisfy DORA Art. 6, SOX ITGC, or MAS TRM 8.4.
A CALM architecture.calm.json is the contract. It binds intent (the pattern) to instantiation
(the deployed system) to control (the compliance posture). It is reviewable in pull requests, validatable in
CI, renderable as C4 diagrams, and queryable for drift. The same artefact answers what is the system?,
does it meet our golden pattern?, and which controls apply?.
CALM has a small, deliberate set of primitives. Each is a typed JSON object with a unique identifier and a defined slot in the meta-schema. Learn these seven and you have read the entire spec.
A service, database, network, actor, deployment target, or other addressable element. Identified by a
stable unique-id within the document.
Connects two or more nodes. The relationship-type determines semantics:
connects, deployed-in, composed-of, or interacts.
The escape hatch. Anything that does not fit the core schema — cost centre, data classification, business owner — lives here as structured key/value pairs.
A pattern is a JSON Schema that describes a class of valid architectures — for example, a golden three-tier web app or an event-driven microservice topology. Patterns are the unit of reuse.
An architecture document is a specific, validated instance of a pattern. It contains the same nodes and relationships, populated with real names, owners, and runtime details.
Declarative requirements attached to nodes or relationships. Examples: “all relationships entering PCI scope must use mTLS”, “every persistent store must declare encryption at rest”.
A flow describes a business or data path across nodes — for example, the steps to register an attendee, settle a trade, or process an instant payment. Flows reference existing nodes and relationships in order, so they remain consistent with the structural model.
Three nodes, two relationships, one control. The same model is renderable as a C4 container diagram or as a Mermaid graph — CALM is the source, the diagrams are views.
FINOS members did not open-source CALM to make documentation prettier. They open-sourced it because regulators are asking the same questions in five jurisdictions, and there is no scalable way to answer them with PowerPoint.
Attach DORA Art. 6, PCI-DSS 4.0 8.3, and SWIFT CSCF 2.4A directly to the relationships they govern. Evidence is queryable instead of forensic.
A nightly job introspects the cluster (or Terraform state, or cloud APIs) and renders the live topology as CALM. Diff against the approved document → drift PR opened automatically.
Architecture changes are GitHub pull requests on the CALM document. Reviewers see the JSON diff, the rendered C4 view, and the controls delta in the same place they review code.
A new service must validate against the approved pattern before merge. The control plane fails the build — it does not wait for the next ARB. By the time a system reaches production review, it has already been validated.
CALM validation drops into the same pipeline as your unit tests and SAST scans. A pull request that breaks the pattern fails at the same gate as a pull request that breaks a test.
calm validate sits alongside unit tests and SAST as a first-class CI gate.
CALM ships as an npm CLI. The only hard prerequisite is Node.js 18+. Java 21 and Maven are needed
only if you intend to run CALM Hub locally; the CLI itself does not need them. Start with the
preflight check — if a binary already shows ok, skip the step that installs it.
Run the loop below once. It probes every binary the rest of this section installs and prints
ok with a version or missing. Each subsequent step is safe to skip if its
binary reports ok at a recent enough version (Node 18+, Java 21+ for CALM Hub).
# report which prerequisites are present on this machine
for cmd in curl gpg make git node npm calm java mvn; do
if command -v "$cmd" >/dev/null 2>&1; then
ver=$("$cmd" --version 2>/dev/null | head -n1)
printf " ok %-6s %s\n" "$cmd" "$ver"
else
printf " missing %-6s -\n" "$cmd"
fi
done
Typical output on a fresh Ubuntu 26.04 box:
ok curl curl 8.5.0 (x86_64-pc-linux-gnu) ok gpg gpg (GnuPG) 2.4.4 missing make - ok git git version 2.43.0 missing node - missing npm - missing calm - missing java - missing mvn -
Refresh the package index and install the small set of tools we need to bootstrap Node. Skip this step
if the preflight reported ok for curl, gpg, make,
and git — ca-certificates is preinstalled on Ubuntu Server images.
# refresh index, install build essentials and curl
sudo apt update
sudo apt install -y curl ca-certificates gnupg build-essential git
Ubuntu 26.04 ships a recent Node in apt, but it tracks Debian’s snapshot and can
drift from the active LTS. Use the NodeSource repository to pin Node 22.x — the CLI requires
Node 18+, and Node 22 is the current LTS line (Node 20 reached end-of-life in April 2026). Skip this
step if the preflight reported ok for both node and npm at
v18 or newer.
# add NodeSource repo and install Node 22
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
Confirm both binaries are on PATH and reporting a version on the 22.x line.
node --version v22.14.0 npm --version 10.9.2
Pull the official package from npm. The binary is exposed as calm. Skip if the preflight
already reported ok for calm — re-run only to upgrade.
npm install -g @finos/calm-cli
Print the version and the top-level command list.
calm --version calm --help Commands: generate Generate an architecture instance from a pattern validate Validate an architecture against a pattern (+ controls) template Render a template using a CALM document as input docify Generate a documentation site from an architecture init-ai Bootstrap AI-assistant config (Claude, Copilot, Kiro)
Only required if you intend to run the CALM Hub registry/visualisation server locally. It is a Quarkus
application and will not start without Java 21+ and Maven 3.8.6+. Skip if the preflight reported
ok for both java (21 or newer) and mvn.
sudo apt install -y openjdk-21-jdk maven java --version mvn --version
The FINOS monorepo carries the spec, reference patterns, and the conference-signup tutorial used below.
git clone https://github.com/finos/architecture-as-code.git
cd architecture-as-code/calm/getting-started
ls -1 *.json
conference-signup.pattern.json
Take the official getting-started pattern, instantiate it as an architecture, validate, visualise, and render a documentation site. Five commands, five minutes — the same loop you will run in CI.
The FINOS monorepo bundles a reference pattern for a simple attendee-registration system. The pattern is a JSON Schema describing the shape of a valid architecture.
cd architecture-as-code/calm/getting-started ls -1 conference-signup.pattern.json README.md
calm generate walks the pattern and produces a stub architecture document. The output is
your starting point — you then fill in the populated values (real ids, owners, hostnames).
calm generate \ --pattern ./conference-signup.pattern.json \ --output ./conference-signup.arch.json [calm] reading pattern: conference-signup.pattern.json [calm] resolved 3 nodes, 2 relationships [calm] wrote: conference-signup.arch.json
calm validate checks the architecture against the pattern (schema conformance) and against
any attached controls. In CI this is the failing gate.
calm validate \ --pattern ./conference-signup.pattern.json \ --architecture ./conference-signup.arch.json [calm] schema check ............ OK [calm] node id uniqueness ........... OK [calm] relationship references ...... OK [calm] controls ...... OK [calm] PASS
CALM Hub is the FINOS-hosted (and self-hostable) registry and visualisation server. Upload the architecture and you get a rendered topology, control overlay, and shareable URL. Either upload to hub.finos.org or run your own instance with Java 21 + Maven.
# self-host (after cloning architecture-as-code) cd calm-hub mvn quarkus:dev Quarkus 3.x dev mode listening on http://localhost:8080
calm docify generates a static site from an architecture — nodes, relationships,
controls, and embedded diagrams. The output is a folder you can publish to GitHub Pages.
calm docify \ --architecture ./conference-signup.arch.json \ --output ./website [calm] wrote 12 files to ./website [calm] open ./website/index.html
Truncated to nodes and relationships for clarity — the full document also carries metadata, controls,
and flow definitions. The $schema URL pins the meta-schema version used to validate.
{
"$schema": "https://calm.finos.org/release/1.0/meta/calm.json",
"name": "Conference Signup",
"description": "Reference architecture for the FINOS conference signup example.",
"nodes": [
{
"unique-id": "conference-web",
"node-type": "webclient",
"name": "Conference Web UI",
"description": "Public-facing web interface for attendee registration."
},
{
"unique-id": "conference-api",
"node-type": "service",
"name": "Conference Signup API",
"description": "REST API exposing attendee registration endpoints."
},
{
"unique-id": "attendee-store",
"node-type": "database",
"name": "Attendee Store",
"description": "Relational store for attendee records."
}
],
"relationships": [
{
"unique-id": "web-to-api",
"relationship-type": {
"connects": {
"source": { "node": "conference-web" },
"destination": { "node": "conference-api" }
}
},
"protocol": "HTTPS"
},
{
"unique-id": "api-to-db",
"relationship-type": {
"connects": {
"source": { "node": "conference-api" },
"destination": { "node": "attendee-store" }
}
},
"protocol": "JDBC"
}
]
}
A reference list of CALM-adjacent terms. Skim if you are already fluent; bookmark if you are not.
unique-id.@finos/calm-cli on npm) for generating, validating, templating, and documenting CALM documents.If you take nothing else from this page, take these. Each one shifts how architecture is practised — not what is drawn.
Diagrams are derived views. The CALM document is the source. If they disagree, the JSON wins — rebuild the picture from the data.
Everything — patterns, architectures, controls — validates against one meta-schema. The schema is the only thing you need to learn deeply.
One golden pattern, dozens of architectures. The pattern enforces what is non-negotiable; the architecture fills in the rest.
calm validate sits next to your unit tests. A non-conforming architecture fails the build — not the next architecture review board.
Attach DORA, PCI-DSS, SOX, and MAS TRM requirements to the relationships they govern. Evidence is queryable, not forensic.
Upload to hub.finos.org or self-host the Quarkus service. Diagrams render automatically — humans never touch a drawing tool again.
The authoritative sources. Pin these in your bookmarks bar.
npm install -g.