Baselines Are Decisions, Not Backups

The distinction that gets lost

Every revision is a point you could return to. A baseline is a revision someone chose to name, and the naming is the whole value.

Teams that miss this end up with baselines called baseline-2026-03-14, baseline-2026-03-21, baseline-2026-03-28 — which is a backup schedule wearing a different hat, and carries no more information than the revision timestamps already did.

What deserves a name

Four kinds of moment, and they share a property: something outside the repository now depends on this state.

• An architecture was approved. A board, a design authority or a governance forum accepted this and people will build against it.
• A release boundary. What the implementation was supposed to conform to, so conformance can be assessed later against the right target.
• An audit or regulatory submission. What was shown to someone outside the organisation.
• A decision point. Where one option was chosen over others, so the alternative can be reconstructed if the decision is revisited.

Everything else is a revision, and revisions are already kept. If you cannot say which external commitment a baseline underpins, it does not need a name.

Naming them

A baseline name is read by someone who was not in the room, eighteen months later. That is the audience to write for.

Restore, again

Restoring a baseline should create a new revision containing the baseline's content, not roll history back. This is worth restating in the context of baselines specifically, because the temptation is stronger here: a baseline feels like a save point, and save points feel like things you load.

They are not. The reason you might restore an approved baseline is usually that recent work went in a direction that was rejected. The fact that the work happened, and that it was rejected, is information. Deleting it removes the only record of a decision.

Who may create one

If anyone can create a baseline, the list fills with personal save points and stops being meaningful. This is a permission worth scoping deliberately — usually to whoever owns architecture governance rather than to every architect.

The same applies to deletion, more strongly. A baseline that can be removed by the person who found it inconvenient is not evidence. In practice the right answer is that baselines are not deletable at all; if one was created in error, mark it and leave it.

Baselines and published portals

A useful pairing: if you also publish a read-only portal of the architecture, publish from a baseline rather than from the current state.

That gives the published portal the same property the baseline has — it corresponds to something someone approved, rather than to whatever was in the repository when the job ran. Readers get a citable artefact, and the architecture team gets a clear separation between work in progress and what has been agreed.

Baselines and the delivery cycle

The most valuable baseline in practice is the one created at the start of a delivery increment rather than at the end.

A baseline named for what a release is being built against gives you something to assess conformance in the other direction: when the release ships, the question "did we build what we said" has a fixed target. Without it, the target moved during the build and the comparison is meaningless.

This is also the baseline most likely to be referenced by people outside the architecture team, which makes the naming convention worth agreeing with delivery rather than imposing.

When a baseline is superseded

Baselines accumulate and most eventually stop being current. Deleting them is wrong — they are records of decisions. Leaving them undifferentiated is confusing, because a reader cannot tell which approved architecture is the approved architecture.

A status field solves it: current, superseded, withdrawn. The baseline and its content are untouched; what changes is a label saying how to read it. Superseded baselines remain citable for the period during which they were current, which is exactly what an auditor asking about last year needs.

What a baseline has to capture beyond the model

A named revision on its own is still thin. Six months later the question is rarely what did the model look like — it is why did we accept it, and the model does not answer that. A baseline that earns its name carries four things alongside the content hash.

None of this belongs in the baseline name. Names should stay short enough to say out loud. The fields sit on the baseline record, where they can be queried.

Comparing two baselines

The comparison people expect is a diagram diff, and it is the least useful one. Two versions of a layered view rendered side by side differ in element positions as much as in content, and the eye cannot separate the two.

What answers real questions is a set difference over the records:

• Elements present in B and absent from A, grouped by type. This is the growth of the estate, and it is usually the shortest list.
• Elements present in A and absent from B. Retirements — or deletions nobody meant to make, which is why this list is worth reading even when it should be empty.
• Relationships whose source or target changed. Almost always the interesting list: it means something now depends on something else.
• Properties that changed on elements present in both. Owner and lifecycle changes hide here, and they matter more than most structural changes.

Rendering that as four tables takes a page. Rendering it as a diagram takes an afternoon and communicates less.

How long to keep them

Baselines are small — a content hash and a pointer to a revision that was being kept anyway — so the storage argument for deleting them does not hold. The argument that does hold is that a list of two hundred baselines is unusable, and the useful ones stop being findable.

A workable rule: keep every baseline that supported an external submission indefinitely, keep release baselines for as long as the release is supported, and let decision-point baselines expire when the decision they recorded has been superseded twice. That last one sounds arbitrary because it is; the point is that something expires, so the list stays readable.

Retention is also a compliance question in regulated sectors, where the answer is set for you and is usually longer than you would choose. Find out before designing the expiry rule rather than after.

The failure mode nobody plans for

Baselines get created diligently for about a year. Then a release slips, someone creates the baseline a week late from a model that has moved on, and the record now says a board approved something it never saw.

This is not caught by tooling, because a late baseline is indistinguishable from a timely one once it exists. The only defences are procedural: create the baseline in the meeting rather than after it, and make the decision reference mandatory, so a baseline created a week later has to point at a minute dated a week earlier and the gap is visible to anyone who looks.

Baselines in a tool that has no baselines

Plenty of estates need this before they have tooling that provides it. The mechanism matters less than the discipline, and a workable version exists in almost every setup.

With a file-based tool and a shared drive, a baseline is a copy in a read-only folder whose name follows the convention, plus a row in a spreadsheet carrying the four fields above. It is fragile — nothing stops someone editing the copy — but it is not nothing, and the spreadsheet is the part that does the work.

With Git behind a file-based tool, a baseline is an annotated tag. The annotation holds the decision reference and the scope, which is exactly the field Git gives you and teams routinely leave empty. A lightweight tag is a bookmark; an annotated tag is a baseline.

With a database-backed repository the feature exists, and the risk inverts: baselines become so cheap to create that people create them without deciding anything, and you are back to a backup schedule.

What conformance assessment actually needs

The most common justification for baselines is conformance — checking what was built against what was approved. It is a good justification and it is usually under-specified, because conformance means three different comparisons and they need different things from the baseline.

1. Did we build what we said? Compares the implementation against the baseline. Needs the baseline to record the intended target state, and needs the scope statement, because the answer is only meaningful within what was approved.
2. Did the target change while we were building? Compares the current model against the baseline. Needs the superseded-by chain, or the comparison silently uses the wrong predecessor.
3. Were the exceptions closed? Compares the exception list against current state. Needs the exceptions to have been recorded with expiry dates, which is why that field is not optional.

Teams that record baselines without those fields can answer the first question and neither of the others, and it is the third one that governance forums actually ask.

A convention that has survived contact with real teams

Names should be readable in a dropdown and unambiguous a year later. The shape that works is what happened then what it applied to, with the date left to the metadata where it already lives.

The rule underneath all four: a baseline name should still make sense to someone who was not there.

Who gets told when one is created

A baseline that only its author knows about is a private bookmark. The notification list is short and it is not everyone: the domain architects whose packages are in scope, the delivery leads who will be assessed against it, and whoever maintains the published portal, because the portal should usually be regenerated from a baseline rather than from head.

What the notification needs to say is narrower than teams assume. Not the diff — nobody reads a diff they did not ask for. Three lines: what was baselined, what decision it records, and what it supersedes. Anyone who needs the detail will open it.

The mistake worth avoiding is routing baseline notifications through the same channel as every model save. Publish events are frequent and unremarkable; baselines are rare and consequential, and mixing them guarantees the consequential ones are skimmed past.

What the portal reader sees of all this

Baselines are created by governance and consumed, mostly, by people who will never hear the word. The design finishes properly only when it decides how baselines surface to the portal reader, because that is where the distinction between decision and backup either becomes visible or evaporates.

The pattern that works: the working portal carries a quiet line under its title — "current state; the last approved baseline is 2026-Q2 Target, approved 12 June" — with the named baselines one click away, each rendered as its own dated, immutable publication. The reader who needs to cite something follows the link and cites a baseline; the reader who needs today's picture stays where they are. The register of baselines itself reads like a decision log rather than a file listing: name, date, approving body, one sentence of what it underpins — the ERP contract, the Q3 regulatory filing, the divestment data room. That sentence is the metadata that pays for everything, because it lets a reader in eighteen months understand not just what was approved but why anyone bothered to name it.

What this presentation quietly enforces is the discipline the whole article argues for. When every named baseline is publicly listed with its reason, baselines without reasons look as odd as they are — and the Friday-afternoon habit of baselining "just in case" dies of visibility. The portal becomes the baseline policy's enforcement mechanism, at zero additional cost: nothing disciplines a naming convention like an audience reading the names.

Held to this standard, a baseline register stays what governance needs it to be: short, legible and entirely made of moments that mattered. The revisions carry the history; the baselines carry the commitments; and a practice that keeps the two apart can answer both "what happened" and "what did we promise" without either answer diluting the other. That separation, more than any tooling feature, is what the word baseline was always supposed to mean.

A last test for any proposed baseline, useful precisely because it is blunt: write the sentence "this baseline underpins ___" and try to finish it with something outside the architecture team. A contract, a filing, a board decision, a release — any of these finishes the sentence and earns the name. "Friday" does not finish the sentence. Neither does "just in case". The register stays meaningful exactly as long as every entry can complete that one line, and the discipline costs nothing but the honesty to leave it incomplete.