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.

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.

Version Control Service

The version control service is the customer-side platform that holds text repositories and governs how they change: hosting, history, branching, review, permissions and automation. It is not part of ArchMeta. It is a service the customer already runs — GitHub, GitLab, Bitbucket, Azure DevOps or a self-hosted git server — and which ArchMeta deliberately consumes rather than replaces.

Modelled from the outside it is a single service. Modelled from the inside it decomposes into a small number of distinct things worth naming separately, because business processes attach to different ones.

What the service actually contains

Repository hosting. Durable storage of the repository and its complete history, with backup, mirroring and availability handled by the platform. This is what makes a file-based architecture model a corporate asset rather than a folder on an architect's laptop.

Change history. Every commit — author, timestamp, parent, message, and the exact diff. The non-negotiable core: it is the audit trail, the blame trail and the rollback mechanism at once, and it is produced as a by-product of working rather than as a separate documentation task.

Branching and merging. Isolated lines of change that can be developed, compared and integrated. For an architecture repository this is the mechanism behind target-state scenarios: a branch is a proposed architecture, a diff is the gap analysis, a merge is adoption.

Change review. The pull/merge request: a proposed change, its diff, a discussion, and a recorded approval by named people before it reaches the main line. This is the hook that architecture governance plugs into — the approval step is already there, already enforced, and already audited.

Access control and identity. Who may read, who may write, who may approve, who may override. Integrated with the customer's directory and, where required, commit signing and protected branches.

Automation and validation. CI/CD triggered by repository events. For ArchMeta this is where archmeta validate runs, so a model that does not load never reaches the main branch, and where the published site is rebuilt when the model changes.

Release and tagging. Named, immutable points in history — the architecture as it stood at a baseline, an audit date or a board decision. Any published or cited version can be reproduced exactly.

Plug points for the rest of the model

These are the seams where business and application content attaches. Names are illustrative — match whatever ids the target file already uses.

Part of the service	Typical model shape	What plugs in
Repository hosting	application service / technology service	Maintain Architecture Repository, backup and retention processes
Change history	business object / data object (Commit, Repository)	Audit, traceability and reporting processes
Branching and merging	business process	Propose Target Architecture, Run Change Scenario
Change review	business process + business role	Review Architecture Change, Approve Architecture Change; architecture review board as the role
Access control	application service + business role	Onboard Contributor, Grant Repository Access
Automation and validation	application service	Validate Model, Publish Architecture Site
Release and tagging	business process + business object (Baseline)	Baseline Architecture, Publish Release

Two directional notes when wiring it up. The version control platform is an external service the customer consumes, so model it the way 030-finance.arch models the payment provider: a service b9 and its customers use, not a role anyone staffs. And the ArchMeta components do not realize these services — they use them (serves from the platform toward ArchMeta, or ArchMeta processes accessing the repository object), which is the whole point of the strategy described in customer-version-control.md.

Why it is worth modelling at all

Because it is the load-bearing assumption underneath the product. ArchMeta's ownership, portability, governance and scale claims are all discharged by this service rather than by ArchMeta's own code. If it is left implicit, the model shows a product that appears to provide capabilities it does not build — and the reviewer cannot see that the customer already owns them.