Guide
Set Up Device Software Evidence From the First Commit, and the File Builds Itself
No rule says regulation begins at the first commit, yet the evidence regulators expect can only be created at the time. Most of the controls are ordinary engineering settings.
5-minute read5 November 2026
In Brief
- A team that adopts regulated process once the product works has chosen to reconstruct its own past. FDA's guidance warns that records made long after the work can raise questions about design control.
- Four actions this week: protect the main branch, tie every change to an identifier, make the pipeline the test record, and treat each release as a recorded decision.
- Thinqmesh engineers join your team in your repositories, set up automated tests and deployment, and ship a first feature with your team within four weeks.
No regulator reads a device company's first commit, and nothing in the rules says that regulation begins there. The formal obligations attach later, at an audit, a licence application or a premarket submission. The first commit matters for a practical reason: a submission has to show how the software came to exist, and that history cannot be written afterwards with any credibility.
The Controls Worth Having Cost Little on the First Day
FDA's guidance on device software functions says design records should keep pace with development, verification and validation, and that records created long after the work could raise concerns about whether the developer has adequate control of its design process. India's CDSCO guidance expects source code, version control and release management to be documented.
Most of what supports this is ordinary engineering: a protected branch, identifiers in each change, a retained test record, pinned dependencies and a tagged release. We switch these on with your team in the first sprint, so your procedures can describe something that already happens. For early experiments, we keep a clear boundary between feasibility work and product code, and we record honestly when the controls began.
Four Settings to Switch on Before the Next Sprint
Each one is a setting or a small habit in tools most teams already use, and each creates evidence that cannot be made later.
Protect the Main Branch and Require a Second Reviewer
No direct commits, and the platform retains each review.
This takes minutes to configure, and it cannot be applied retrospectively to work already done. Early requirements may be rough, which is acceptable as long as their changes are recorded. Reviews by a second person are then part of the history from the first day.
Get started
- Turn on branch protection and required review in your repository settings.
- Confirm the platform keeps the review record.
Tie Every Change to an Identifier
A requirement, a risk control or a defect, referenced in each pull request.
A pull request template asks for the identifier and for a statement of regulatory impact. Traceability then becomes a query, where it would otherwise be a matrix assembled by hand before an audit.
Get started
- Add a pull request template with an identifier field and a regulatory impact field.
- Give existing requirements identifiers, even rough ones.
Make the Pipeline the Test Record
Each build has an identity, and results are stored against it.
Check retention in your continuous integration tool, because defaults are often much shorter than the life of a device. Lock dependency and toolchain versions and generate a software bill of materials with each build, so a released version can be rebuilt long after the original machine has gone.
Get started
- Extend the retention of build and test records.
- Add generation of a software bill of materials to the build.
Treat Release as a Recorded Decision
Continuous integration produces evidence. Release to the field is a separate choice.
A pipeline can enforce that the regulatory impact of each change has been classified and recorded. A named person makes the judgement, since some changes, such as a new clinical claim, carry consequences that software cannot assess. Tag each release so a version in the field can be traced to its source.
Get started
- Take your latest release and rebuild it from its tag on a clean machine.
- List whatever fails to reproduce as your first work.
How Thinqmesh Solves This
We join your team on a defined piece of the roadmap, working in your repositories and to your standards, and plan the exit from the start. Your first feature ships with our team within four weeks, and the full engagement runs to eight.
- Week 1
Architecture and Pipeline Review
We assess the architecture, delivery pipeline and quality of the product, because that is often where the constraint lies.
- Week 2
Working With Your Team
Our engineers join your planning and your repositories, and agree how work is reviewed and released.
- Week 3
Quality and Release
The tests and release steps the first feature depends on are put in place before it is built on further.
- Week 4
First Feature Shipped
Your first feature ships with our team, and the findings of the review set the plan for the remaining weeks.
You finish with a first feature shipped, automated tests and deployment for what we built, and documentation reviewed by your engineers. The code sits in your repositories.
