Requirements traceability software that fits how regulated engineering actually works

If you work in regulated engineering, this story (or a version of it) has probably kept you up multiple nights: Two engineers on the same satellite project opened the same 300-page specification on different installs of Microsoft Word and got different page counts. A page break had shifted between the French installation and the English one. Every cross-reference to “the requirement on page 243” was pointing somewhere else, and there was no clean way to know which version was right. Reconciling them took most of a day.

But that is not the worst part. The worst part is the meeting where someone asks how this happened and you have to explain that the tool you were using was never actually built to handle a document this long, across this many people, against this kind of audit standard. And you have to do it without sounding like you are making excuses.

Most regulated engineering teams hit some version of this moment eventually. The teams that get past it stop trying to make the wrong tools fit and start putting together their own setup from a small number of off-the-shelf pieces. This article is about what that setup looks like, why it works, and where to start if you are tired of losing days to problems your tools were never going to solve.

The off-the-shelf tools are appliances, and the work has too many edges

Most commercial requirements management tools are appliances. They do the thing their designers thought the work should look like. For some teams, the fit is close enough. For engineers operating in regulated industries, it usually isn’t, and the reasons are pretty predictable.

IBM Doors is the legacy reference and it does work. The trouble is that it works the way it worked in 1995, on Windows, with a deployment overhead that most modern engineering teams find painful even when budget is not the issue. Plenty of teams have been willing to pay for it and then discovered that the workflow Doors imposes is not the workflow they actually want to run.

Notion is the modern alternative most teams reach for first. The relational database model is closer to what traceability needs, and the editor is genuinely pleasant to use. The flaw is in the export. What you see in the Notion editor is not what comes out in the PDF. For most companies this is a minor annoyance. For a regulated workflow where the exported PDF is the legal deliverable, it is the whole game.

Airtable, Monday, and Smartsheet are cloud-only, which rules them out for most European engineering work, all defense work, and a growing share of medical device work where data sovereignty is not negotiable. They also handle copy-paste, undo, and bulk editing in ways that are fine for marketing teams but quietly painful for engineers working with thousands of structured records.

Word and Excel are where teams fall back to when the alternatives fail. They are great for small projects. The page-break problem in the opener is one of half a dozen ways they come apart on larger ones.

None of these is a bad tool. Each one was built for a different audience, and a regulated engineering team is rarely that audience. Appliances fit when the work fits inside the appliance. Regulated engineering work has too many edges.

What teams build instead

This is the point where a lot of teams stop, reasonably. Putting your own setup together sounds like the thing you do not have time for, especially when you are already behind on the work that is making you wish you had a better tool.

The good news, if you want to call it that, is that the components approach is not building software from scratch. It is wiring together three things that already exist and that other teams have already proven work for this kind of project.
The three pieces are:

1. A spreadsheet-database, self-hosted, that holds requirements, tests, implementers, and audit records as related tables. The interface looks familiar enough that engineers and non-engineers can both use it. The relational structure does the cross-referencing work that breaks in a flat spreadsheet.
2. A typesetting engine like Typst or LaTeX that turns the data into delivery-ready PDFs. Deterministic, reproducible, version-controllable. The PDF an engineer reviews is the PDF the auditor receives, every time.
3. Git, holding the database file, the document templates, and the code in one versioned bundle. Every release of the documentation matches a specific commit of the code. Anyone with access can regenerate any deliverable from any point in history.

That is the whole pattern. Three components, each one replaceable, each one open source, each one independently auditable. The team owns all of it.

This is not the only way to build requirements traceability, but it is the way that holds up under the constraints regulated engineering teams actually face: data sovereignty, deterministic deliverables, auditability of the system itself, and the freedom to change the workflow without waiting on a vendor’s roadmap.

Grist is one of the spreadsheet-databases that supports this pattern. NocoDB is another. Teams pick by what fits the rest of their stack. The shape of the components matters more than the brand of any single component.

One team’s setup

Dotphoton is a Swiss deep-tech company that builds image compression for machine vision. Their work has been integrated into systems at Samsung, SK Hynix, and the Ariane rocket program.

In 2021 they started a satellite project that needed full requirements traceability against engineering standards used by the European Space Agency. They were ready to pay for IBM Doors. The rejection was not on price. The license would have required them to hire two additional people to manage the tool, and the workflow Doors imposed was not the workflow they wanted to run. They tried Notion. The export problem killed it. They tried Word. The page-break moment in the opener is from that attempt.

So they put their own setup together on Grist, with Python pulling the data into LaTeX, with the whole bundle versioned in Git. First working version, two days. The current version, three generations on, is simpler than the second one. PDF generation now takes about ten milliseconds through a custom widget that triggers a Typst service in a Docker container.
Bruno Sanguinetti, co-founder and CTO of Dotphoton, walked through the build in detail on a recent webinar.

Common questions

Does this approach hold up for regulated work in space, defense, or medical devices?
Yes, when built carefully. Dotphoton’s setup is in production on work to engineering standards used by the European Space Agency. The factors that matter to auditors are traceability (the relational structure), reproducibility of deliverables (the typesetting engine), auditability of the system (source code you control), and version control of both data and templates (Git). The pattern was shaped by exactly those requirements.

How long does it take to put together the first usable version?
For an engineer who has used a spreadsheet-database before, the database for a small project can be built in a day or two. Dotphoton’s first generation took roughly two days. The document generation piece takes a few days more. The hardest work is not the build, it is defining the data model: which entities you track, how they relate, which fields each one needs. That is the same hard work you would do for any requirements system, regardless of the tool underneath.

Can a non-technical team member maintain it once built?
For the day-to-day work like adding requirements, updating test results, and triggering PDF generation, yes. The interface looks like a spreadsheet. Structural changes like adding new tables or modifying relationships need someone with more familiarity, but those changes are rare once a setup stabilizes.

Does it scale beyond a small team?
The pattern scales. The constraint is usually the discipline around the data model, not the tool. Larger teams need clearer ownership over which roles can change which parts of the database, which is what row-level access controls in the spreadsheet-database are for.

Where to start

If your team is somewhere in this picture, the place to start is the data model, on paper, before you touch any tool. List the entities you need to track, the relationships between them, and the fields each one needs. This work is the same regardless of which components you pick, and it is the work that decides whether the eventual system is useful or just a different tool with the same problems.

Then build the smallest version that does anything. One project, one deliverable PDF format, the simplest version of the traceability links. Resist adding features. Most of what teams put in version one turns out to be unnecessary in version three.

If you want to talk through where your team is and what would actually work, we run fifteen-minute calls. No pitch, just a conversation with someone who has watched a lot of teams figure this out.