ArchMeta · Built 2026-09-09T17:39:23.802Z

Archmeta Application C4 Level1

Software SystemArchMetaA platform for managing architecture documentation as code. Architects describe their organisation in a textual DSL stored in Git; the Kernel reads that repository into an in-memory graph and serves it over REST, the Viewer authors it, and the Publisher turns it into a static site. There is no database — Git is the source of truth, and the same commit always produces the same model. ContainerCLIThe command surface: archmeta init scaffolds a repository with its metamodel profiles, archmeta load reports the model and its diagnostics, archmeta build generates the site, archmeta daemon serves the Kernel and the Viewer. The only entry point in a CI pipeline. ContainerDiagram RenderThe rendering primitives both renderers share: geometry, element shapes, orthogonal routing, status styling, relationship chips and the link indicator. One implementation per render boundary is an enforced rule — a diagram must look the same on the canvas and on the published site, and the only way to guarantee that is to give them one function. ContainerGrammarThe Langium grammars for .arch, .data, .view, .cascade and .metamodel, plus the generated parsers and TextMate syntaxes. Depends on nothing else in the product — deliberately, so the language can be reasoned about without the Kernel. ContainerKernelReads the repository into an in-memory graph and serves it over REST on port 7777. Never throws on model content: unresolved references, malformed attributes and rule violations become diagnostics, and the load always completes. A pure function of the repository — no clock, no randomness, no network during a load — so the same commit produces the same model and the same diagnostics forever. ContainerKernel ClientThe wire contract: the types crossing HTTP, and the predicates that must not be re-implemented on either side of it. Shared so the Viewer and the generated site cannot disagree about what a relationship means. ContainerPublisherGenerates the static site from a loaded model: element pages, view pages with interactive SVG diagrams, the BPMN gallery and the search index. The output has no back end and carries no diagnostic data — what an architect needs to fix the model is not what a stakeholder should read. ContainerGenerated SiteThe deliverable: static HTML, CSS and JavaScript with a prebuilt search index. No server, no database, no API — it can be served from object storage, a CDN, an nginx container or a filesystem, which is the point. ContainerViewerThe single-screen React SPA that is the primary authoring tool: model canvas, BPMN modeler, Markdown editor and Explore in one shell, flanked by a management pane and a docked Inspector. Never reads the whole graph — every instance read is a point read, a search or a bounded neighbourhood — and never touches the filesystem. Edits stage; only a commit sends them to the Kernel. Invokes for archmeta buildLoads throughParses every source file withReads the loaded model fromSame primitives as the Viewer, so the two cannot driftEmitsREST over HTTP

Elements (9)

ArchMetac4:softwaresystem

archmeta

A platform for managing architecture documentation as code. Architects describe their organisation in a textual DSL stored in Git; the Kernel reads that repository into an in-memory graph and serves it over REST, the Viewer authors it, and the Publisher turns it into a static site. There is no database — Git is the source of truth, and the same commit always produces the same model.

CLIc4:container

archmeta.cli

The command surface: archmeta init scaffolds a repository with its metamodel profiles, archmeta load reports the model and its diagnostics, archmeta build generates the site, archmeta daemon serves the Kernel and the Viewer. The only entry point in a CI pipeline.

Diagram Renderc4:container

archmeta.diagram-render

The rendering primitives both renderers share: geometry, element shapes, orthogonal routing, status styling, relationship chips and the link indicator. One implementation per render boundary is an enforced rule — a diagram must look the same on the canvas and on the published site, and the only way to guarantee that is to give them one function.

Grammarc4:container

archmeta.grammar

The Langium grammars for .arch, .data, .view, .cascade and .metamodel, plus the generated parsers and TextMate syntaxes. Depends on nothing else in the product — deliberately, so the language can be reasoned about without the Kernel.

Kernelc4:container

archmeta.kernel

Reads the repository into an in-memory graph and serves it over REST on port 7777. Never throws on model content: unresolved references, malformed attributes and rule violations become diagnostics, and the load always completes. A pure function of the repository — no clock, no randomness, no network during a load — so the same commit produces the same model and the same diagnostics forever.

Kernel Clientc4:container

archmeta.kernel-client

The wire contract: the types crossing HTTP, and the predicates that must not be re-implemented on either side of it. Shared so the Viewer and the generated site cannot disagree about what a relationship means.

Publisherc4:container

archmeta.publisher

Generates the static site from a loaded model: element pages, view pages with interactive SVG diagrams, the BPMN gallery and the search index. The output has no back end and carries no diagnostic data — what an architect needs to fix the model is not what a stakeholder should read.

Generated Sitec4:container

archmeta.static-site

The deliverable: static HTML, CSS and JavaScript with a prebuilt search index. No server, no database, no API — it can be served from object storage, a CDN, an nginx container or a filesystem, which is the point.

Viewerc4:container

archmeta.viewer

The single-screen React SPA that is the primary authoring tool: model canvas, BPMN modeler, Markdown editor and Explore in one shell, flanked by a management pane and a docked Inspector. Never reads the whole graph — every instance read is a point read, a search or a bounded neighbourhood — and never touches the filesystem. Edits stage; only a commit sends them to the Kernel.

Relationships (18)Relationships (2)

Loads throughc4:uses

archmeta.cli → archmeta.kernel

Loads the model through

Invokes for archmeta buildc4:uses

archmeta.cli → archmeta.publisher

Parses every source file withc4:dependson

archmeta.kernel → archmeta.grammar

archmeta.kernel → archmeta.kernel-clientKernel → Kernel Clientc4:dependson

archmeta.kernel → archmeta.kernel-client

Same primitives as the Viewer, so the two cannot driftc4:dependson

archmeta.publisher → archmeta.diagram-render

Reads the loaded model fromc4:uses

archmeta.publisher → archmeta.kernel

Emitsc4:sendsto

archmeta.publisher → archmeta.static-site

archmeta.viewer → archmeta.diagram-renderViewer → Diagram Renderc4:dependson

archmeta.viewer → archmeta.diagram-render

archmeta.viewer → archmeta.kernel-clientViewer → Kernel Clientc4:dependson

archmeta.viewer → archmeta.kernel-client

REST over HTTPc4:uses

archmeta.viewer → archmeta.kernel

REST over HTTP — never IPC, never shared state

archmeta → archmeta.cliArchMeta → CLIarchimate:composition

archmeta → archmeta.cli

archmeta → archmeta.diagram-renderArchMeta → Diagram Renderarchimate:composition

archmeta → archmeta.diagram-render

archmeta → archmeta.grammarArchMeta → Grammararchimate:composition

archmeta → archmeta.grammar

archmeta → archmeta.kernel-clientArchMeta → Kernel Clientarchimate:composition

archmeta → archmeta.kernel-client

archmeta → archmeta.kernelArchMeta → Kernelarchimate:composition

archmeta → archmeta.kernel

archmeta → archmeta.publisherArchMeta → Publisherarchimate:composition

archmeta → archmeta.publisher

archmeta → archmeta.static-siteArchMeta → Generated Sitearchimate:composition

archmeta → archmeta.static-site

archmeta → archmeta.viewerArchMeta → Viewerarchimate:composition

archmeta → archmeta.viewer

← Home