The content is the asset, not the tool

The expensive part of an architecture repository is never the licence. It is the years of accumulated content — the elements, the relationships, the prose that explains why things are the way they are. Tools get replaced. That content has to survive them.

So the repository is held in readable, editable text that the customer owns outright. Three consequences follow, and they are the whole point:

• Use it directly. The model can be read, grepped, diffed and reviewed with ordinary tooling, by people and by machines, without going through ArchMeta at all.
• Leave whenever you want. Because the format is legible, a script can transfer the repository to any other tool. There is no export feature to be at the mercy of, and no lock-in to negotiate.
• Arrive from anywhere. The same legibility works inbound: content can be migrated into ArchMeta from another tool, with AI doing the translation where the mapping is not mechanical.

Ownership here is not a licence term. It is a property of the file format.

Text-Native Model Engineering

The ability to design and evolve file formats that are simultaneously a machine-loadable model and a document a person can read, diff and edit by hand.

This is harder than it sounds. .arch, .data, .bpmn and .md have to carry enough structure for the Kernel to build a graph, stay legible enough to review in a pull request, and survive being regenerated by the Viewer's write-back without losing what the author meant.

Every other capability rests on this one. Ownership, AI-readability and portability are not features layered on top of the product — they are consequences of the format decision.

Metamodel Engineering

The ability to drive the whole engine from declared metamodels, so that type vocabulary is data rather than code.

Elements, relationships, layers, shapes, colours and icons are all declared in .metamodel files. The built-in ArchiMate and C4 profiles use exactly the syntax a customer would use for their own — they are examples of the mechanism, not privileged internals.

The pay-off is that a customer can model their own domain in their own terminology, in their own language, without waiting for b9 Solutions to ship support for it. Adding the ArchiMate Motivation layer to this very repository took one file and ten icons.

Repository Interoperability

The ability to move a repository in and out of ArchMeta without the vendor's cooperation.

Outbound, legibility is the whole mechanism: because the format is readable, a script can transfer the model to another tool. There is no export feature to be at the mercy of. Inbound, the same property lets content be migrated into ArchMeta from another tool, with AI handling the translation wherever the mapping is not mechanical.

Deliberately, this capability makes leaving easy. A customer who cannot leave has not been given ownership, whatever the licence says.

Built for AI

The file formats are the product decision. .arch, .data, .bpmn and .md are all plain, readable text, and that is deliberate: it makes the repository something an AI can read, reason over and edit without an adapter, an API key or an export step.

A conventional EA tool keeps its model in a proprietary database. To put AI near it you must first build an integration, and you are limited to whatever the vendor's API exposes. Here the model is the interface. Point any agent at the directory and it has the whole architecture — types, prose, processes and data — in a form it already understands.

This is what makes it practical to build an AI environment around the repository rather than waiting for one to be built into the tool.

A self-describing repository

Metamodels are not islands. Any metamodel can be linked to any other, so a custom vocabulary sits alongside ArchiMate and C4 in one model rather than in a separate silo.

What makes that workable is where the meaning lives. The semantics of a type — what it means, when to use it, how it differs from its neighbours — are written in the repository itself, in the type descriptions and the accompanying .md files. The explanation travels with the model.

The consequence is that understanding this repository does not depend on anyone having been trained on it. A newcomer reads the descriptions. An AI reads the same descriptions, in the same files, and needs no fine-tuning, no vendor-specific knowledge and no external documentation to work accurately within the customer's own vocabulary. A repository that explains itself is one that stays usable after the people who built it have moved on.

The Customer's Assets — What Enterprise Architecture Documentation Costs, and What It Is Worth

Buyers of enterprise-architecture tooling usually assess the licence. The licence is the smallest line in the total. The real cost of enterprise-architecture documentation has two components, only one of which ever turns into an asset the customer keeps.

The two cost lines

The knowledge of the architecture team. This is the expensive one, and it is unavoidable. Someone has to know how the estate actually works: which systems exist, what they do for whom, where the dependencies run, what was decided and why. That understanding is accumulated over years by people who sit in the meetings, read the contracts and survive the migrations. No product creates it and no product substitutes for it. It is the substance of the documentation — everything else is transcription.

The cost to introduce and maintain the documentation. This is the avoidable one, and in most organisations it is where the budget actually goes: modelling conventions nobody agreed to, a tool that must be installed and administered, a metamodel that has to be configured, an import that has to be built, a repository that must be kept alive, and — the recurring killer — the manual effort of keeping it current after the initial push. Documentation decays the moment maintaining it costs more than consulting it.

The assessment question is therefore not "what does the tool cost?" but what fraction of the spend ends up as a retained asset, and what fraction is consumed by the act of documenting? A tool earns its place only by shifting that ratio.

Where ArchMeta aims to sit

The aim is for ArchMeta to be the centre of the value of the customer's documentation, not a container it happens to be stored in.

That distinction is concrete. In a conventional tool the value is split: some sits in the model, some sits in the tool's proprietary representation of the model, and the second part evaporates the day the licence lapses — so a large share of what was paid for was never an asset in the first place. In ArchMeta the value is entirely in the customer's files: plain text, in the customer's own version control (see customer-version-control.md), readable and portable without ArchMeta in the loop. What the customer pays for is the leverage the product applies to content they own outright, and the cost of introducing and maintaining that content is what the product is obliged to drive down.

The mechanism is that the model stops being a deliverable and becomes an internal knowledge base:

• The architecture repository is the single place the estate is described — elements, relationships, the prose behind each of them, the processes, the diagrams, the decisions.
• It is published as a navigable site, so the knowledge reaches people who will never open a modelling tool.
• It is text, so it is AI-readable: the knowledge base can be queried, summarised and extended by assistants rather than only by its authors. That is what makes maintenance affordable rather than aspirational.
• Because maintenance is cheap, the documentation stays true — and documentation that is true is the only kind that is worth anything.

Extending down to the engineering teams

The last step is that this knowledge base does not stop at the architecture team. Architecture documentation read only by architects is funded by goodwill and dies with the next budget round.

ArchMeta's format is deliberately the format engineers already work in: files in a repository, changed through pull requests, validated in CI. An engineering team can be handed the part of the model that describes their systems and maintain it in place, alongside their code, without adopting an architecture practice or learning a modelling tool. Detail flows upward from the people who hold it instead of being extracted from them in workshops, and the architecture team curates and connects rather than transcribes.

When that happens the two cost lines finally separate. The organisation pays for the knowledge — which it needed anyway, and which stays on its side of the table — and stops paying, over and over, for the act of writing it down.