Documentation as an Engineering Standard
Work that is not documented did not fully happen; we record assumptions, methods, and decisions so the analysis can be understood and audited.
The record is part of the work
An analysis that lives only in someone's head or a stray script is fragile and unauditable. Documentation -- of assumptions, methods, inputs, decisions, and their reasons -- is what turns a calculation into knowledge that others can check, build on, and trust. We treat writing it down as part of doing the work, not an optional afterthought.
What we document
- Assumptions and their justification.
- Methods, including numerical settings and tolerances.
- Inputs and constants with their sources.
- Decisions and the reasoning, including options rejected.
- Known limitations and open questions.
Documenting the reasoning, not just the result
The reason behind a choice matters as much as the choice. A future reviewer -- or our future selves comparing against a FOAK measurement around 2030 -- needs to know why a value was set, not merely what it is. Recording the reasoning is what lets a later question be answered honestly instead of reconstructed from guesswork.
Good documentation is also a defense against orphan numbers and quiet drift. If every figure carries its context, no figure can float free of its origin, and no assumption can be forgotten and then silently violated. The document is where traceability, change control, and reproducibility are actually written down. Written well, the documentation is where a design study becomes something other people can actually inherit, rather than a result that dies with the person who computed it. The test of good documentation is simple and unforgiving: could a competent stranger, months later, understand what was done, why, and how far to trust it, using only the record we left behind.