What Gets Frozen When You Release a Board?

Your files are still editable after you release them. Nothing in your computer stops you opening the schematic the next morning and nudging a resistor.

So what does "frozen" actually mean?

It means a promise: that a named set of items, each at a stated revision, will not change under that name. Anyone who comes back to that name later gets the same thing. Break the promise once and the name stops meaning anything, which is the whole mechanism — a baseline has no technical enforcement behind it, only the discipline of not editing something you said you would not edit.

That sounds weak. In practice it is the backbone of every working hardware project, because it is what makes a statement like "we shipped Rev C" carry information.

What a baseline is for

Three things, and it is worth being clear which one you need, because they lead to slightly different contents.

Reproduction. Someone has to build the same thing again, perhaps in two years. The baseline has to contain everything needed to produce it.

Comparison. Something failed, and the question is what differs between the batch that worked and the batch that did not. The baseline has to be comparable, which means consistent in form across releases.

Accountability. Someone approved this configuration for a purpose. The baseline has to record who, when, and for what.

Most teams write baselines for reproduction and are then annoyed when they cannot answer the other two.

What goes in

And a few things people forget:

Library or footprint data, if it lives outside the project and can change underneath you. Tool and version, if reopening the design later depends on it. Approved alternatives in force at the time — a board built with the second source is still that configuration, but only if the baseline says so. Known deviations — anything accepted as a departure from the design.

Freezing is three mechanisms, not one

In practice teams freeze a release in one of three ways, and they are not equivalent.

Copy it. Take the outputs, put them in a folder named for the release, and never touch them. Simple, and it works. Its weakness is that the source remains editable, so the copy drifts from the project it came from and nobody notices until they differ.

Mark it. Record that Rev C is the released revision, and keep editing the source towards Rev D. This keeps one line of history, which is better, but it depends entirely on the marking being honest — and on nobody editing Rev C after the fact.

Record it. Store each revision as a thing in its own right, so that Rev C remains retrievable whatever happens to Rev D. This is what version control does for software, and what a PDM or PLM system does for hardware.

Most small teams use the first, graduate to the second, and only adopt the third when the first two have failed them in a way that cost money. There is nothing wrong with that progression, but it is worth knowing which one you are relying on, because each fails differently.

The release record

Whichever mechanism you use, write the record. It is one page and it is the part that survives:

Release 2025-03-14 — ORION Main Control Board PCB Rev C · Assembly Rev 2 · BOM Rev 4 · Firmware 1.2.7 Purpose: production build, 500 units Changes since previous release: ECO-018 (regulator), ECO-019 (silkscreen) Approved: [name], 14 March 2025 Deviations in force: none Files: /releases/orion-mcb/2025-03-14/

Sample content. The two lines that do the most work are purpose and deviations in force. Purpose stops a prototype baseline being used for production six months later. Deviations stop a known, accepted departure being rediscovered as a defect.

When you have to change something frozen

You will. A frozen baseline that turns out to be wrong is not a reason to edit it quietly.

Three legitimate responses:

Issue a new baseline. Normal, correct, slightly slow. Issue a deviation against the existing one. A documented, bounded departure — "for this build only, fit the alternative capacitor" — that leaves the baseline intact and records the exception. * Withdraw it. If the baseline is actively dangerous, mark it superseded and say why, so that anyone who finds the folder knows not to build from it.

What is not legitimate is editing the frozen files. It costs nothing today and destroys the value of every baseline you will ever create, because afterwards nobody can be sure that any of them is untouched.

The smallest version worth having

If this feels heavy for a two-person team, the minimum is genuinely small:

1. A folder per release, named with a date and a revision.
2. The outputs that went to the supplier, unmodified, inside it.
3. A one-page text file with the record above.
4. A rule, written down, that nothing in that folder is ever edited.

That is an afternoon of setup and it answers "what did we build in March?" for as long as the drive survives. Everything beyond it is refinement.

The failure it prevents is specific and common: a project where the newest files are the only files, where every release overwrote the last, and where the honest answer to any question about a past build is a reconstruction from memory and purchase orders.

How much of this is manual depends on where revisions live. If a frozen revision is a copied folder, the discipline is entirely yours; if each revision is stored as its own record, the freeze is a property of the data.

That is the part XKEMA handles: a board and its BOM each keep their own version history, so an earlier revision remains retrievable after later ones exist.

Hardware configuration management PCB release checklist * Hardware revision control: a practical guide