The structure is not written down
That this supply carries two converters and not three is something you learn by reading the schematic. It is not a fact you can look up.
Hardware configuration management
Exactly what the unit that shipped in March contained
The answer almost always exists, but scattered: one person knows the equipment, the board revision is in a folder name, and the BOM that was bought is an email. Managing the configuration is being able to look that answer up instead of reconstructing it.
In XKEMA a product is not a folder: it is a tree of real elements —equipment, boards, PCBs, stackups— and each one has its own version. The configuration is that tree with one specific version at each node.
Why that question is so hard to answer
The versions do not line up
Each document has its own revision, but nothing says which revision of each thing went with which.
Nothing is frozen
The folder for the revision that was manufactured is still writable, so a year later nobody knows whether it is the one that was manufactured.
A complete example
A power supply, from top to bottom
This is the sample equipment from the screenshot above. Each row is a different XKEMA element with its own version identity: changing the stackup does not renumber the BOM, and changing the BOM does not renumber the equipment.
| Element | Type | Version | Status |
|---|---|---|---|
| EXAMPLE_EQUIPMENT | Equipment | V1.0 | Frozen |
| POWER_BOARD_U12 | Board | V2.1 | Frozen |
| PCB_U12 | PCB | V1.3 | Frozen |
| STACKUP_6L | Stackup | V1.0 | Frozen |
| BOM_U12 | You pull up its bill of materials | V2.0 | Frozen |
| gerbers_u12.zip | Manufacturing package | V1.3 | Frozen |
Sample data about a sample equipment. The version numbers are made up; the way they are numbered and frozen is not.
How it is numbered
Each element is numbered V<major>.<minor> within its own version family and starts at V0.0. Each version records which one came before it, so the chain is explicit: you do not have to infer it from a file date or a folder name.
Freezing a configuration
Three states, and the last one has no way back
-
Draft
The version is worked on as normal. It is edited, it is corrected, and it owes nobody anything.
-
Under review
Somebody asks to freeze it. From then on it needs whoever has to sign it to sign it.
-
Frozen
It is closed. It does not reopen: if something has to change, it changes in a new version, which is exactly what freezing one is for.
How many signatures are needed
As many as the team's policy asks for, but never more than the people who were available to sign that day, and never fewer than one. A team of two does not get stuck behind a policy written with a team of six in mind.
And the review records all three separately: what the policy asked for, how many people there were, and how many signatures were actually required. Years later the history reads on its own, instead of looking like somebody skipped the procedure.
| Kind of change | Major |
|---|---|
| Signatures the policy asks for | 3 |
| People who could sign | 2 |
| Signatures required | 2 |
Sample data.
And how you know it is still the same one
A fingerprint of the approved state
When a version is frozen, XKEMA reduces its engineering state to a canonical form and stores its SHA-256 fingerprint. It is written once: it is calculated when the review closes and never touched again.
When it is needed, it is recalculated and compared. If it does not match, XKEMA says so and does not fix it: silently rewriting the fingerprint would erase the only trace that anything had changed, which is exactly what it exists for.
- Calculated once, at freeze time.
- Can be verified again whenever you want.
- A mismatch is reported; it is never repaired on its own.
What is left out of the fingerprint, and why
Price, stock and availability do not go in. They move on their own, on dates nobody on your team decides: if they went in, every frozen configuration would fail its own check the next time a supplier updated something, and the check would stop meaning anything.
What does go in, frozen exactly as it stood on the day of approval, is what forms part of the engineering decision: the compliance and lifecycle status each component had when it was approved.
What you won't find here
XKEMA does not version your design tool's native file: what it controls is what comes out of it —manufacturing and documentation— and the structured engineering data. It does not track unit by unit with serial numbers, does not raise purchase or manufacturing orders, does not look up distributor prices or stock, and does not warn about obsolescence.