Somebody asks what the nose cone mass is. Four people answer. They give three different numbers, and the fourth says "check with Aero".
This is parameter drift, and it is the most expensive failure mode a hardware team has, because it does not look like a failure. Nothing is broken. No test went wrong. There is just a number that used to be agreed and now quietly isn't, and the only way to find out is for two pieces of work built against different versions of it to meet.
Where the copies come from
Nobody decides to keep five copies of a value. It happens because every copy was reasonable at the time.
The mass starts in a CAD model. It gets read out into the mass budget spreadsheet, because the spreadsheet needs to add it to twenty other things. Someone building the recovery system needs it for a descent-rate calculation, so it goes into their working doc. It appears in a slide for the design review, because you cannot present a spreadsheet. And it goes into the simulation config, because the simulation needs a literal number, not a reference.
That is five copies, all created honestly, in five tools that have no idea the others exist. The CAD model is the source of truth, and everyone would agree if you asked. But the CAD model is also the only one of the five that nobody outside the structures sub-team opens.
Then the nose cone gets 40mm longer.
What actually happens next
Follow it through, because the abstract version undersells how ordinary this is.
The structures lead extends the nose cone to fix a fineness-ratio problem flagged in an aero review. Mass goes from 1.30 kg to 1.42 kg. They update the CAD model, tell their sub-team in a channel, and move on. Nothing they did was wrong. There was no list of the other four places to update, because that list has never existed in any team I have worked in. It lives in whoever happens to remember that recovery did a descent-rate calculation back in March.
The mass budget spreadsheet keeps saying 1.30. Total vehicle mass is therefore 120 g light. That is under 1% and well inside everyone's mental margin, so it survives three more reviews without anyone blinking.
The descent-rate calculation keeps saying 1.30 too. Descent rate scales with the square root of mass over drag area, so a 9% mass error is about a 4.5% velocity error at touchdown. Also small. Also invisible. It gets folded into a parachute sizing decision that is now slightly wrong in the unsafe direction, and the person who made it has moved on to the avionics bay.
The slide deck is a snapshot and nobody expects it to be current, which is fine right up until someone screenshots a slide into a handover document, at which point a nine-month-old number acquires a second life with no date attached.
The simulation config is the one that eventually surfaces it, because simulation output gets compared against a real test. Apogee comes back lower than predicted. Two weeks go into looking for a bug in the simulation, because the simulation is complicated and complicated things are where bugs feel like they should be. The bug is a literal in a config file that was correct in March.
None of these five people made a mistake. The system had no way to tell them.
Why it survives so long
The reason drift persists is that the cost of finding it is paid by a different person than the one who caused it, months later.
Stale copies look exactly like fresh ones. A number in a spreadsheet carries no indication of when it was last checked against its source, or whether the thing it came from has moved since. It is just a number, right-aligned, in a cell. Your confidence in it is identical whether it is current or nine months rotten.
Compare that with software, where the equivalent failure mode is largely solved. If a function signature changes, everything calling it fails to compile, loudly, immediately, in the editor of the person who made the change. Hardware documentation has no compiler. The document is the artefact, and if it does not know its own dependents, nothing does.
There is a second reason, which is social. By the time drift surfaces, the question "which number is right" has become entangled with "who got it wrong", and teams are bad at that conversation under launch pressure. So the incentive is to quietly adopt whichever number the loudest person is holding and move on, which resolves the disagreement without resolving the drift.
How to tell whether you have it
You do. But if you want to confirm it before spending effort, three cheap tests.
The five-minute audit. Pick one value that matters. Dry mass, chamber pressure, bus voltage, anything with more than one consumer. Find every place it appears. Do not ask people, go and look. Teams that have never done this routinely find between three and seven copies, and at least one that disagrees.
The provenance question. Take any number in your current design and ask where it came from. Not who typed it, where it came from. If the answer takes more than one hop of asking someone, that number is unverifiable, which means in practice it is unverified.
The change test. Ask what would happen if a parent spec changed today. If the answer is a person's name, that person is your dependency graph, and they are going to graduate.
Three fixes that don't work
"We'll just be disciplined about it." This is the default plan, and it fails for a structural reason rather than a moral one. The discipline has to be exercised by the person making the change, on behalf of consumers they cannot enumerate. You are asking someone to update five documents they do not know exist. Discipline scales with how visible the obligation is, and here it is invisible.
"One big spreadsheet." Better, and a lot of teams get real mileage out of it. It fails on two things. First, a spreadsheet has no notion of what depends on what, so changing a cell tells you nothing about what just went stale. Second, it is one file with one editor at a time and no history worth the name, so the moment two sub-teams need to move at once, someone takes a local copy. Then you are back to five copies, with extra steps.
"More review gates." The instinct after a drift incident is to add a checkpoint: a sign-off before any parameter changes. This makes things worse in a specific way. Review gates raise the cost of updating a number, but they do not raise the cost of not updating one. So the rational move for a busy person becomes leaving their local copy alone and working around it, which is precisely the behaviour that created the problem. Any fix that makes the correct action more expensive than the incorrect one will be defeated by deadline pressure, every time.
What actually fixes it
Two things, and they only work together.
One definition, referenced everywhere. The value exists once. Everywhere else that needs it holds a reference to it, not a transcription of it. This is the part most teams can conceptually agree with and never implement, because none of the tools in a normal hardware stack support referencing across documents. But it is the whole game. If there is one copy, there is nothing to drift.
Dependency tracking, so a change announces itself. A reference is only half the fix. The other half is that when the definition changes, everything built against the old version gets flagged. Not deleted, not silently updated, but marked as needing a look by a human. The descent-rate calculation from March does not become wrong automatically. It becomes unverified, which is a state a team can actually act on.
That second part is what turns a change from an invisible event into a visible one. The structures lead changes the geometry, and the system does the thing no human can reliably do: it knows the full list of consumers, and it tells them.
Note what this does to the social problem too. When staleness is a state the system assigns rather than an accusation a person makes, re-checking a calculation stops being an implied criticism of whoever wrote it. It is just the next task in a queue.
The uncomfortable part
Doing this properly means accepting that some of your existing numbers are already wrong and you do not know which. Teams stall here, because the first week of putting values into one place is mostly discovering disagreements, which feels like the tool is creating problems.
It isn't. Those disagreements were already in your build. You were going to find them at integration, or at a test, or not at all. Finding them at a desk in October is the cheapest version of that discovery you will ever get.
There is also a real cost worth naming. Defining a parameter properly, with units, bounds, and an owner, takes longer than typing a number into a cell. Perhaps a minute or two per value. For a few hundred values that is a couple of afternoons, and those afternoons produce nothing visible. It is genuinely hard to justify against a launch date, and it is why this work only ever happens immediately after drift has embarrassed someone.
Where to start
The teams that get through this do it one sub-system at a time, starting with whatever has bitten them most recently. Mass budget is usually the honest answer, because it has the most consumers and the most obvious failure.
Do mass first. Get the arguments over with while the stakes are low. Every disagreement you surface is one you were going to have anyway, at a worse time. Then the next sub-system is easier, because half its inputs are already defined and referenced rather than copied.
Do not try to do the whole vehicle in one pass. A migration that takes three weeks and blocks other work will be abandoned in week two, and the half-migrated state is worse than either end state, because now people do not know which system to trust.
What good looks like, eventually, is unremarkable. Someone changes the nose cone. Four things light up as needing review. Three are fine and get cleared in a minute. The fourth is the parachute sizing, and it gets fixed in October rather than discovered at a launch.
Prototype is built around exactly this: one definition per parameter, real references instead of transcriptions, and automatic staleness flags on anything downstream when a parent spec changes. It came out of a university rocketry team that got tired of finding drift at integration. See how it works, or read about why wikis and spreadsheets struggle with this specifically.