Your code ships fast.
Your compliance should too.
With every software release, tracy.md seamlessly updates your technical documentation to align with your code.
For teams building medical device software.
Code ships. Compliance docs fall behind.
Code fast. Get compliant faster.
From PR merge to regulatory sign-off in minutes.
Start with the device profile.
Tell tracy.md what the medical device is intended for, by who and which safety class applies. This is the one-time part and will be used in every run when analyzing your codebase.
Connect the codebase.
Connect the repositories that make up the medical device software. tracy.md reads your code base and merge metadata.
What changed and needs an update.
tracy.md analyses each code change, identifies what the software does differently, and compares with your current documentation.
A list of records that need your attention.
Anything that no longer matches or is missing gets flagged, ready to get updated.
Nothing changes without a human.
Every finding is a proposal. Accept it, edit it, or reject it. No record changes until a person signs it off, creating an immutable audit trail for every regulatory decision.
From reactive to real-time.
Your code changes with every release. Your records change when someone finds the time. tracy.md does the check at the release itself, so the technical file is never behind.
Every release, not every audit: the work is continuous rather than reconstructed under deadline.
No context gets lost: a change is reviewed while the person who made it still remembers why.
Records a reviewer can walk.
Every record in tracy.md has an ID, a status, a version history and how it links to each other, so that a reviewer can walk your documentation in a series of clicks rather than a search through folders.
Unique IDs: every record is addressable and filterable, the format reviewers ask for.
Links both ways: open a requirement, see the need above it and the tests below it.
Gaps are visible: a requirement nothing verifies shows up as a gap before a reviewer finds it.
No black box.
Nothing is suggested without its source. Each finding carries the change that triggered it, the rule of the standard that got triggered, giving you all the tools to verify the outcome.
Check it, don’t trust it: the reasoning is on the page, not inside a model.
Learn as you build: all in plain-English so no separate training is needed.
What actually changes.
The first job is getting the technical file built at all. The second is keeping it true once you're certified.
Compliance that keeps pace with your code
Questions we get asked.
Getting started
Connecting a repository is quick. Pointing tracy.md at your existing requirements and risk file is the part that varies, and it depends entirely on how those are stored today. We do that part with you during the onboarding phase rather than leaving you to it.
No. tracy.md connects as a webhook on pull requests into a branch you pick, usually the one you release from, and does its reading outside your pipeline. You can also run it over the whole repository whenever you want, which is how the first baseline gets built. It doesn't gate merges, rewrite branches or sit in your deployment path. Turn it off and your pipeline is exactly as it was.
Your code is yours. It is never used to train models, never shared with another customer, and never leaves the environment set out in your contract. Every customer is isolated. tracy.md reads the repository and writes nothing back to it, and you can revoke access at any time. Your security reviewer gets the full architecture and the data processing agreement before you connect anything.
You need someone who can approve a change to a risk control. On most teams that's a QA or RA lead, sometimes a founder wearing that hat. tracy.md proposes. It has no authority to sign.
Here, and it is the best place to start from. tracy.md reads the codebase and produces a baseline: the software architecture, the requirements and specifications, the risks and the risk controls it can identify, and the verifications your software already implies. All of it is a draft and all of it is editable. You are reviewing a first pass rather than facing an empty template.
No. tracy.md keeps the software records themselves: every record has an ID, a version history, a status and its links to the code and the clause. That is what a reviewer walks through. When you do put a QMS in place, the records move into it as a set that is already structured and already traceable.
Compliance & regulatory
The standards care about whether your process is defined, followed and evidenced. They don't specify which tools produce the evidence. What matters is that a competent person reviewed and approved each item, and that the record shows it. That's why sign-off is always a person, and why every finding carries the change and the clause it came from.
No. Your QMS stays the system of record. tracy.md works on the software records and the code they describe, and hands the result back. It sits alongside what you already run.
That's a judgement call and it stays with your regulatory lead. What tracy.md does is make the change visible: when code lands that touches a claim about intended use or a clinical function, it surfaces it rather than letting it pass unnoticed.