A chip-design backup was never made, so its manager reconstructed two revisions six years later
An anonymous semiconductor veteran recalls delegation without a completion receipt, followed by a restoration nobody could confidently validate.
A manager asked an engineer facing dismissal to preserve a chipset design at a specific production revision.
The engineer decided to wait for the next revision, told nobody, and left the company before completing the task. Six years later, a customer wanted the old design for a radiation-hardened satellite chip. In the original reader interview, the manager, identified by the pseudonym Gordon, says he and a colleague found fragments on nightly tapes.
They handed over a reconstructed database without explaining its mixed revisions. Gordon says he kept “confirmation that backups had been done” after that episode. He still does not know whether the customer produced a useful chip.
The assignment had a very particular promise: preserve the cleaned-up design at that production stepping. Delaying it until another revision would change what was being preserved even if a later copy eventually existed. A backup request can fail by saving the wrong coherent state as well as by saving nothing at all.
Gordon’s account also leaves the manager inside the mistake. The person assigning the task already knew the engineer’s work was in question, yet the important handoff went unverified. The employee’s private decision to postpone it remained invisible until the request for old data arrived. There was no timely receipt that would have forced the disagreement into view.
For a design team, the practical acceptance condition would be a named revision restored as a set, with enough evidence to identify what it contains. A folder of readable files is weaker evidence. The gap becomes obvious in this account because the rescue assembled pieces of different steppings. Finding files answered whether some data survived; it did not establish that the original milestone could be reconstructed faithfully.
The six-year delay makes the oversight awkward to discover. People may leave, the reasons for a snapshot may fade and a new customer may ask a question nobody expected when the work was current. A restore check performed at the milestone would have much better access to people who could recognize the right result.
There is a limit to what the anecdote can prove. The company and customer are undisclosed, and the account supplies no later technical outcome. It supports a very specific failure of delegation and verification without establishing that a satellite ever flew with the reconstructed design. The next owner of a milestone backup can close that uncertainty earlier by asking for the restored output while the original team can still recognize it.
The account comes from one anonymous participant, with no disclosed customer outcome. A future restore exercise could answer the question Gordon’s request email never did: what can actually be rebuilt from this copy?