Alpine: audit evidence without a documentation sprint

A documentation sprint is the regulated form of the phase-gated handoff: work happens in one mode and evidence is manufactured later in another. It fails on three counts. First, reconstruction is unreliable. Chat threads and 30-day CI logs cannot demonstrate which build produced which result, so what the team produces would be plausible rather than true. For a device that delivers drug doses, that is worse than an honest gap. Second, the effort is unbounded and lands on the same people at the worst time; it will be estimated at a fraction of its real cost and will compete with the release. Third, it treats documentation as something done to satisfy an auditor rather than as a way to make verification inspectable, so the same gap reappears after the next audit. On principles: working software over comprehensive documentation does not license missing evidence. The agile reading is just-enough documentation, produced continuously at the point of work, and valuing working software does not mean the auditor's question is optional. The auditor's question is narrow and legitimate: was each requirement verified, and can the result be tied to the released build. The team already generates most of the raw material through automated checks, exploratory notes and review. What is missing is the link to the requirement, the retention, and the build identifier. So the fix belongs in the definition of done and the pipeline, not in a retrospective sprint. Freezing the process until the audit also guarantees that the next audit finds the same problem, since the process will be unfrozen with the gap intact.

• Anchor: every story carries one or more requirement identifiers in the issue tracker, one per verifiable requirement statement.
• Automated checks: tag each check with the requirement identifier in the test framework. The CI run then emits a machine-generated trace: requirement identifier, check, build hash, result, timestamp. This is produced automatically and retained in an artifact store or published report per release candidate, replacing reliance on 30-day logs.
• Manual and exploratory work: a two-line record per chartered session, listing charter, requirement identifiers touched, timebox, findings and follow-ups, held in the same tool. This covers verification that cannot be automated and is exactly what the auditor will probe.
• Release record: a generated report per released build listing requirement identifiers in scope, verification method, result, open deviations and the named risk acceptor. Who and when: developers tag checks as they write them; the tester reviews session records within the sprint; the release report is generated by the pipeline and reviewed at the release review. Add requirement identifier present and trace generated to the definition of done so evidence is a by-product rather than a project. Risk-based rigour: not every requirement needs the same depth. Define classes, for example mapping the highest safety class to mandatory automated trace plus independent review of the results, and lighter classes to the same tagging with single review. The highest-class fifth, dose calculation and occlusion detection, gets the independent reviewer and the retained, signed release artifact. Lower classes still get a trace, because the cost is now near zero, but not the additional review effort. That keeps the burden proportionate and makes the argument to the regulatory lead concrete rather than a promise.