KM-301f · Module 2
Empirical Reconstruction
3 min read
When artifact archaeology and shadow expert sessions reach their limits — when the knowledge gap cannot be filled by what the expert wrote or what others observed — the remaining recovery method is empirical reconstruction: systematically testing what you think you know until the gaps in your knowledge become visible as prediction errors. This is the most expensive recovery method and the most reliable one. If the recovered knowledge is accurate, the system behaves as predicted. If it is not, the prediction fails — and the failure is the most specific possible indication of what is still missing.
- Define the Prediction For each piece of recovered knowledge, formulate a specific prediction: "If we execute the recovered process for [scenario], the output should be [expected outcome]." The prediction must be specific enough to be falsifiable. "The process should work" is not a prediction. "The system should return a 200 response within 2 seconds for [input type]" is a prediction.
- Test in a Safe Environment Test the prediction in a staging or sandbox environment before applying it to production. This is not a novel insight in software contexts, but it is routinely violated in operational contexts — teams execute recovered knowledge in production and discover the gaps through customer impact. Every empirical reconstruction test should have a defined blast radius.
- Map the Failures to Gaps Every test failure is a knowledge gap signal. "The process failed at step four" means the recovered knowledge for step four is incomplete or incorrect. Map each failure to the specific knowledge element that needs revision. The failure log becomes the second-pass recovery agenda.