Technical documentation that survives an inspection
The file has to describe what the system is, how it was built, how it is monitored and what happens when it fails — written before anyone asks, not after.
Last reviewed:
Sound familiar?
- The documentation is a README, a Confluence page from 2024 and the memory of one engineer.
- Nobody knows which model version, dataset or prompt was live when a decision was made.
- Testing happened, but there is no record of what was tested and what the result was.
- Every customer security questionnaire triggers three days of archaeology.
What we do
Documentation structure
A template covering purpose, architecture, data sources, model and prompt versions, human oversight, known limitations and monitoring.
Fill the gaps
We work with your engineers to reconstruct what is missing and record it in a form that does not need a translator.
Keeping it current
Which events force an update, who signs it off, and how the file is versioned alongside the system.
Reuse for sales
The same file answers most customer due-diligence questionnaires — one artefact, two purposes.
Questions we get
How long does this take?
For one system, typically two to four weeks. Most of the time goes into recovering decisions that were made and never written down.
Can we generate it from our codebase?
Partly. Architecture, dependencies and versions can be pulled automatically. Intended purpose, oversight and limitations are judgement calls a person has to make and own.
Who has to keep it up to date?
Named owners, usually engineering for the technical parts and a compliance owner for the classification. If nobody is named, it stops being maintained within a quarter.
Tell us what's running in production.
We'll tell you what we'd check first — and what we wouldn't bother with.
Book a call