“Slower merges, faster trials. Nothing reaches production without a signature-ready package — and that discipline, not in spite of it, is why we ship every two weeks instead of twice a year with minimal thrash.
— The call I made Challenge:
Documentation that lagged the code, and a team too small to do both
A validated system needs a validated, QA-signed package for every production change. Ours arrived after the fact: engineering shipped, then someone scrambled to update requirements, trace tests, and get signatures. Hotfixes were worse — urgent, undocumented, and hard to defend in an audit.
The bind was capacity. The engineers building the platform were the only people who could document it to a regulated standard, and every hour spent on documentation was an hour not spent on the next release.
- Validation after the fact: Requirements, trace matrix and OQ results were updated after merges, so the package was always behind production.
- Bugs with no requirement: Fixes to behaviour that had never been written down had nothing to trace to — a Part 11 problem, not just a paperwork one.
- Hotfixes without a trail: Urgent production fixes bypassed the process entirely, leaving no evidence of review.
- Engineering hours: The scarcest resource in the company, spent on documentation instead of judgement.
Solution:
Make the package part of the release, and make tickets precise enough for an agent
The validation package moved in front of the merge instead of behind it: functional requirements, trace matrix and OQ summary are updated per release and marked passed before production, so the package is signature-ready the moment the code lands. A hotfix form gives urgent fixes the same evidence. And tickets are written precisely enough that an AI coding agent implements them and a single engineer approves — the team's hours go to review and judgement, not typing.
- Validation workflow: functional requirements, trace matrix and OQ summary updated per release and marked passed before the production merge
- Hotfix form and review loop so urgent fixes carry the same evidence as releases
- Delivery model where tickets are specified well enough for an AI coding agent to implement, with a single engineer approving
- Weekly engineering/product readout that tracks tickets and deployments in one place
The package
Four documents, kept current at merge, so a release is never waiting on paperwork.
Functional requirementsWhat the system does, one requirement per line, updated in the same PR as the change.
Trace matrixEvery requirement linked to the test that proves it — and the release that last touched it.
OQ summaryTest results for the release, pass/fail by requirement, signed by QA.
Hotfix formThe documented exception: what broke, what changed, who approved it, and the test that re-covers it.
- ✓Ticket is specified tightly enough for a coding agent — acceptance criteria, data, edge cases
- ✓Agent implements; one engineer reviews — the review is the human control
- ✓Requirements and trace matrix updated in the PR — not in a doc sprint afterwards
- ✓OQ run on the release candidate — results attached, signed
- ✓Production merge is signature-ready — two weeks after the last one
- ✓Hotfixes take the documented path — no quiet patches on a Part 11 system
Impact:
A release is one object, not three
Releases ship every two weeks with validation on day one. Bugs whose correct behaviour was never written down get a requirement, not just a fix. A hotfix carries the same evidence as a release. And the trace matrix became the alignment artifact — QA, engineering and product read the same table instead of three documents.
CadenceTwo-week production releases of a Part 11 system, each with a signature-ready package at merge.
HotfixesDocumented path; turnaround [X].
Engineering loadReview load [Y]% lower with agent-implemented, human-approved tickets.
Audit[METRIC: audit findings] — every production change traceable to a requirement and a test.
“Daily standup and a weekly readout keep everyone on the same page; Linear, deployments and validation docs are tied together so a release is one object, not three.
— How it came together