· ReadyStack
Worked example
Real numbers from this tool, line by line.
Fourteen IEC 62304 record gaps in an eight-item SOUP register: that is what the first run returns for a medical device software engineer getting an EU MDR technical file ready, and not one of the fourteen is a spelling mistake.
A SOUP list is the register of software of unknown provenance inside a device - the zlib, the SQLite, the OpenSSL, the Qt build that shipped with the firmware. IEC 62304:2006+AMD1:2015 does not ask for a tidy list of names. Clause 8.1.2 asks for the title, the manufacturer and the unique SOUP designator of each configuration item. 5.3.3 asks for the functional and performance requirements that item has to meet for your device, 5.3.4 for the hardware and software it needs to run, 4.3 for a software safety class of A, B or C, and 7.1.3 for an evaluation of the supplier's published anomaly list against your hazard analysis. Five clauses, and an auditor walks the register row by row looking for all five.
The register shipped with this extension as a test fixture holds eight items from a portable radiography viewer. Running the sixteen rules over it returns fourteen findings - eleven errors and three warnings - and every one of the eight rows carries at least one:
- SQLite is recorded as
^3.45. A caret range is not a unique SOUP designator; it names whatever resolved on the build machine that afternoon. - The libcurl row lists its manufacturer as
TBD. A placeholder in a technical file is a missing record, not a promise. - OpenSSL's evaluation says
No; Qt Base has no safety class and an evaluation readingchecked by QA, with no date. - libjpeg-turbo is pinned to
latest, classifiedLow, and dated 2026-12-01, which is in the future. - zlib appears twice, at 1.2.11 and 1.3.1, and the second row has no 5.3.3 and no 5.3.4 record.
- The oldest evaluation is 680 days old and a second is 462 days old. Both sit past the 365-day line the linter draws, so anomalies published since have never been judged.
The clean version of the same register returns zero. That is the whole shape of the tool: a register that carries its records prints nothing, and one that does not prints the clause number next to the row.
Three of these are what an assistant gets wrong. Clause numbers first: ask a chatbot which clause wants the anomaly-list evaluation and it answers confidently, sometimes correctly. Dates second: a model reading a register has no opinion about whether 2026-12-01 is in the future, because it does not know what today is. Version ranges third - ^3.45 looks like a version, and only a rule that knows a range from a build stops on it. A markdown linter checks table syntax, and all fourteen findings sit in a syntactically perfect table.
Both shapes of register are read: a markdown table, and a section per item. Headings match by meaning, so Supplier, Vendor and Manufacturer all count.
It does not read CVE feeds, judge whether an anomaly is hazardous, or decide your safety class. This is a completeness check on the register - the mechanical part, and the part that gets written down at the audit.
Linting one register is free, in the editor and in the browser: every gap in that file, every run, no item cap and no trial window. The licensed tier does a different job - it scans every SOUP list in the workspace at once, across a family of device repositories, and exports the dated evidence record in Markdown and CSV that you file with the technical documentation. A regulatory consultant reviewing SOUP documentation bills in the $150 to $250 an hour range, and a thirty-item register is a morning of that, at every version bump.
15 seconds — what it actually does
Questions people ask
What does SOUP List Lint actually check?
It reads the markdown file holding your SOUP register and applies 16 rules from five IEC 62304 clauses. It flags a missing manufacturer or title, a version written as a range instead of the exact build, absent functional or hardware requirements, a missing or invalid safety class, and an anomaly-list evaluation that is absent, undated, future-dated or older than 365 days.
Who is this for?
Medical device software engineers and regulatory affairs staff who maintain the SOUP register for an IEC 62304 technical file: firmware and application teams shipping under EU MDR or FDA premarket submissions, and the contract developers who hand a register over to a manufacturer at the end of a project.
Why not just ask an AI assistant or use a markdown linter?
A markdown linter checks table syntax, not records; it cannot tell a pinned version from a caret range. An AI assistant will answer confidently and sometimes cite the wrong clause number. This extension applies one fixed rule set, prints the clause next to every finding, and gives the same answer twice.
What is free and what needs a licence?
Linting one SOUP list is free and complete: every gap in that file, every run, no item cap and no trial window. The same engine runs free in the browser. The licence adds workspace-wide scanning across several device repositories and the dated Markdown and CSV evidence record you file with the technical documentation.
What would this cost done by hand?
A regulatory consultant reviewing SOUP documentation bills in the $150 to $250 per hour range, and a thirty-item register is a morning of that work, repeated at every version bump. The licence is $29 once, with a and it re-checks the register in seconds.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. SOUP List Lint - IEC 62304 dependency inventory (medical sof checks the file you open against 16 rules, each naming its legal or official basis, from a rule set dated 2026-09-20, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.