The Customer's Own Version Control

ArchMeta keeps the architecture repository in plain files and drives it with plain git commands. No proprietary database, no vendor-hosted workspace, no bespoke change-management layer. The repository is a git repository like every other repository in the customer's organisation, and it is administered by whatever the customer already administers git with.

The gain is that nothing new has to be introduced

Every company that writes software already runs version control. It is installed, backed up, mirrored, access-controlled, audited and understood. When the architecture model lives in that same system, the customer inherits all of it on day one:

• Branching and merging. A proposed target architecture is a branch. Comparing it to the current state is a diff. Adopting it is a merge. No parallel "scenario" feature has to be learned, licensed or trusted.
• Review before change. Model changes arrive as pull requests, reviewed by the same people, in the same tool, under the same approval rules as code. Architecture governance stops being a separate process and becomes the process the company already enforces.
• History that is genuinely complete. Every element, relationship, diagram and description carries a full commit history: who changed it, when, alongside what, and — through the commit message — why.
• Access control and compliance. Repository permissions, signed commits, retention and audit export are already solved by the customer's platform. ArchMeta adds no second answer to any of them.
• Automation. CI runs the ArchMeta validation on every push, exactly as it runs tests. A model that does not load never reaches the main branch.

None of this is functionality b9 Solutions has to build, and none of it is functionality the customer has to buy twice.

Scale is not the obstacle it is assumed to be

The usual objection to file-based architecture is size. It does not hold. Git is the system of record for codebases of millions of files and decades of history; the largest engineering organisations in the world run on it, and the tooling around it — partial clone, sparse checkout, large monorepo hosting — exists precisely because that is the normal case.

An enterprise architecture model is small by comparison. Tens of thousands of elements are a few megabytes of text. The repository this document sits in is a rounding error against any production codebase in the same company. Whatever the customer's version control already survives, the architecture model will not strain.

Architecture is not the hard case

There is a persistent assumption that architecture content is too interconnected, too visual or too political to be managed like source code. It is not. A model is a graph of typed nodes and edges with prose attached — structurally simpler than the software it describes, and produced by fewer people, at a lower rate of change.

The organisation is already coordinating hundreds of developers making thousands of concurrent changes to systems far more intricate than their own architecture model, and doing it successfully with version control. Applying the same discipline to a few architects editing a few thousand elements is the easy end of a problem the company has already solved.

What this means commercially

The customer does not adopt an architecture platform. They adopt a file format and a tool that reads it, inside infrastructure they already own and pay for. The exit cost is a git clone — the repository remains readable, diffable and portable without ArchMeta in the loop, which is exactly the ownership position the motivation layer commits to.

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.

Imagination: own your metamodel

Most EA tools ship a fixed vocabulary. You model what the tool's authors anticipated, and anything your organisation actually cares about gets forced into the nearest available box.

ArchMeta is driven entirely by metamodels, and metamodels are just files in the repository. A customer can declare their own type vocabulary — their own elements, their own relationships, their own rendering — for whatever their domain or their language requires. A regulator's terminology, an industry-specific taxonomy, a house naming standard, a set of types in French rather than English: all of it is a .metamodel file, and the same engine renders it.

The built-in ArchiMate and C4 profiles are not privileged. They are examples of the mechanism, written in exactly the syntax a customer would use for their own.

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.