Day 86: Writing the README: measured error, not claimed accuracy
Documenting like a professional
The README is where your honesty becomes visible. Write it in runbook style: what the pipeline does, its architecture (the four models and why each), the calibration approach and its assumptions, the per-dimension error table, the known failure modes, and how confidence is derived. This document is a Stage 2 exit deliverable and doubles as interview material — reviewers read READMEs, and a rigorous one signals a rigorous engineer.
- What & how: the pipeline's job and the detect→pose→segment→parse→measure flow.
- Architecture & choices: each model and one sentence on why it (Day 88's defense, written down).
- Calibration: the height-scaling approach and its stated assumptions/limitations.
- Measured error: the per-dimension MAE/range table — the centerpiece, not an afterthought.
- Failure modes & confidence: where it breaks, and how the confidence number is computed.
The README that gets you hired
Most portfolio READMEs claim; yours measures. 'Validated against 5 people with a tape measure; shoulder MAE 2.1cm, arm length MAE 4.8cm (worse under occlusion); confidence calibrated to flag off-angle poses' — that paragraph does more for your candidacy than the code itself. It proves the roadmap's thesis: verification over plausibility, made legible to a reader.
Key terms
- Runbook-style README
- Documentation covering purpose, architecture, measured performance, failure modes, and operational detail — as an operator would need.
- Measured vs claimed
- Reporting empirically measured performance (with method and error) rather than asserting an unverified accuracy figure.
What makes the Measurement Engine README credible to a technical reviewer?
