Perspective
Build the Design History File From the Records Your Engineers Already Create
A design file assembled before an audit describes work after the fact. Built from engineering and test records, it stays current and needs far less chasing.
5-minute read5 November 2026
In Brief
- Weeks before an audit go on gathering documents, chasing signatures and making a traceability matrix agree with what was built. The file helps no one while the work is under way.
- Four actions: keep requirements in a tracked system, link every test to a requirement, link risk controls both ways, and generate the index at release and freeze it.
- Thinqmesh builds a small layer of software over the tracker and repository you already use, tested against your real scenarios, with the code and documentation yours.
A familiar pattern in device development runs as follows. Engineers finish a design, and then someone spends weeks before an audit or a submission gathering documents, chasing signatures and making a traceability matrix agree with what was built. The result may read well. The organisation has spent its effort describing the work after it happened, and the file told no one anything useful while the work was under way.
The Design File Should Be an Output of the Work
FDA's Quality Management System Regulation, effective from 2 February 2026, asks for a design and development file that includes or references the records showing conformity. A file that references records can be an index over the systems where they properly live.
We settle the structure of those records first, then add a small layer of software over the tracker and repository your team already uses. Testers gain most, because their work becomes the source of the file's strongest evidence and no longer has to be written up at the end. The time saved should go into design review, which stays a human decision.
Four Habits That Make the File a by-Product of the Work
Each one fixes the structure of a record, so the file can be produced from systems already in daily use.
Keep Requirements in a Tracked System
Each has an identifier, an owner and a visible history of change.
No one then has to compare document versions to learn what moved. Design decisions sit beside the design, and architecture notes under version control are reviewed like code. Records that are created in step with the work answer the question of what steered the design.
Get started
- Give every requirement in one product an identifier and an owner.
- Move design notes into version control and review them like code.
Link Every Test to a Requirement, and Keep the Failures
Each run records the software version, the environment, the result and who ran it.
Bench and manual testing can record to the same identifiers as automated tests. A record of only passing runs says little about how the product was tested, so failures are retained with the passes.
Get started
- Write each new test against a requirement identifier.
- Check that your pipeline keeps failed runs for the life of the device.
Link Risk Controls in Both Directions
A hazard control points to the requirement and test that implement it.
A change to either then prompts someone to look at the risk. The links also show where a requirement has no test, which is the most useful single gap a file can reveal.
Get started
- Pick one hazard and trace it to its requirement and test.
- List requirements that have no test.
Generate the Index at Release and Freeze It
The file is an index over working systems, fixed at each release.
Under the QMSR, the design and development file may include or reference the records that show conformity, so it can be an index and need not hold copies. Design reviews stay as human decisions, with a named person reading a sample of the links critically. Automate the clerical work and keep the reading.
Get started
- Take one change released last quarter and trace it back to its requirement, test and risk record.
- Time the exercise and note every point where you had to ask a colleague.
How Thinqmesh Solves This
We build only what a product cannot do for you. A first working version of a defined scope arrives within four weeks, and the full engagement runs to eight.
- Week 1
Records Mapped With Your Engineers
We map where requirements, tests, reviews and risk records live today, with the people who create them, and agree in writing what the first version must do.
- Week 2
Links Designed
Data and integrations are planned so identifiers connect your tracker, repository and test results without anyone retyping.
- Week 3
Built in Short Cycles
Working software is delivered in visible stages, starting with the links that matter most.
- Week 4
Tested on a Real Change
Testing uses a real released change from your own history, and the code sits in your repository with documentation.
You finish with a working version that produces a release index from your existing systems, tested against your own scenarios. The source code and documentation belong to you.
