ENVOLOK™ runs before a modification ships to a cleared device. A Predetermined Change Control Plan is the list of modifications FDA cleared a manufacturer to make without filing again. Your team turns that authorized plan into rules ENVOLOK can check, and signs off that the rules match the source. ENVOLOK then applies the same boundary to every modification. It reads the modification's paperwork — what changed, who says it fits, which tests ran, who approved it — and returns DEPLOY, BLOCK or UNKNOWN, naming the rule that stopped it. Then it signs a record whose integrity anyone can verify with the public key.
A command-line program that runs on the release engineer's laptop, or on a validated workstation, or as a step in your build pipeline. Not a service, not a portal, not a consultant. There is no account to create, nothing to upload, and no server to call.
Your team encodes the authorized plan once: which modification types are permitted, which metric ranges apply, which validation tests are required, and who must approve them. The file changes only when the authorized plan changes.
The dataset, the candidate build, the validation results, the approval, the release record, the deployed artifact. Files your quality system already produces for every change.
DEPLOY, BLOCK or UNKNOWN, with the failing rule named. The signed receipt lists all twenty-four checks it ran and states what it did not check, inside the signed body, so those limits cannot be removed without breaking the signature. Anyone can verify that receipt's integrity with the public key. ENVOLOK does not have to be installed, and nobody has to be asked. What the public key proves is that the record was not altered — not that the change was appropriate, and not that the category somebody chose was the right one.
It runs on the release engineer's laptop, on a
validated workstation, or in your build pipeline. ENVOLOK makes no network calls
during evaluation, and your device data stays in the environment where you run it.
It has exactly two dependencies, cryptography and PyMuPDF, both
named in requirements.txt; everything else is the Python standard library.
Point a network monitor at it and check.
One component does reach outward, and only when you
run it deliberately: external_anchor.py, which requests an RFC 3161 timestamp so a
release can be proved to have existed by a date. It is a separate command, the engine
does not call it, and it sends a hash of the release — never device data. If the
timestamp authority is unreachable it records UNAVAILABLE rather than faking a success.
When 3B Medical acquired the iCodeConnect software, its Software Copyright Transfer Contract named Risk Management Report YF-CSP1-3-02, version 4.0. The risk record instead contained version 1.1, effective 13 August 2016 — a document that could not account for design changes made years later.
A version number did not match a version number.
A program checks that in a millisecond. Nobody had one pointed at it. FDA identified the discrepancy in a May 2026 warning letter.
Before a modification ships, somebody decides it is inside the authorized plan and somebody senior agrees. Most of the time they will be right. The problem is the one time they are not.
FDA is not vague about what a deviation costs.
Deviations from the authorized PCCP … would generally cause the device to be adulterated and misbranded … FDA may take legal or regulatory action against violations of prohibited acts, including, without limitation, seizure or injunction. FDA, Predetermined Change Control Plans for Medical Devices, 22 August 2024
The plan is enforceable. In most companies nothing enforces it except someone remembering it correctly under time pressure, and no version of that scales to the life of a device.
That last line matters more than it looks. Most systems record what passed and what failed. A check nobody ran is neither, and calling it a pass is how a gap reaches the field with a signature on it.
Every claim on this page is one you can check yourself, against documents the agency published.
FDA's guidance publishes eight worked examples. For each device the agency names the changes that belong in a plan and the changes that do not. That is 47 decisions the regulator has already made, in public. ENVOLOK was run against every one of them, and agreed with the agency on all 47.
What that number measures, stated plainly. The 47 tests confirm that FDA's published boundaries were encoded correctly and that ENVOLOK enforced those boundaries correctly. They do not show a machine interpreting FDA guidance. No machine reads intent, and this one says so on its own receipt. Example 8 ran in-scope only, three of six or more cases: FDA's out-of-scope list for that device was not retrievable, so ENVOLOK does not count what it could not test.
The computed evidence is the K253281 run below. Six of those twenty-five cases are not membership tests at all. They compare a measured value against an acceptance range the manufacturer wrote and FDA authorized: a regression suite at 99.4% against a required 100% blocks, one unit conversion error in a thousand against a required zero blocks, a 2% import deviation against a required zero blocks. That is the instrument computing a verdict, on a real filed plan.
| FDA example | Device | Result |
|---|---|---|
| 1 | Cancer risk microarray, over the counter | agreed |
| 2 | Potassium electrode, lab analyser | agreed |
| 3 | Polyethylene surgical suture | agreed |
| 4 | Patient monitor with arrhythmia alarms | agreed |
| 5 | Sleep apnea risk app, over the counter | agreed |
| 6 | Antimicrobial susceptibility test | agreed |
| 7 | HLA typing assay | agreed |
| 8 | Implantable pulse generator | agreed, in-scope only |
Software, diagnostics, implantables, surgical hardware. The whole suite runs on a laptop with the wifi off, and every answer can be checked against the FDA documents themselves.
These are not ENVOLOK's numbers. They come from Capturing the value of good quality in medical devices, the McKinsey study the device industry has been quoting at itself since 2017. McKinsey sells consulting, not change control software.
| What McKinsey measured | Figure | Whose number |
|---|---|---|
| A major recall or other non-routine quality event what it can cost one manufacturer, inside a year |
up to 11.7% of segment revenue, near $300M |
a single company |
| FDA device-surveillance inspections leading to official or voluntary action, 2010–2015 |
about 50% | the inspected |
| Non-routine external quality failures recalls, 483s, warning letters, consent decrees, import bans, litigation |
1.9 – 2.5% of annual sales |
industry-wide |
| The same events, totalled up to 3.8% of sales at the high end |
$7.0B – $8.5B per year |
industry-wide |
The first row is the only one that describes a single company. One event. Up to 11.7 percent of segment revenue, gone inside a year.
A Predetermined Change Control Plan exists for one commercial reason: it lets a manufacturer ship a modification without filing a new 510(k). Congress wrote it into the Act in 2022 so software and AI devices could improve without a submission for every improvement.
Two FDA clearances, a year apart, put a price on both sides of that.
In September 2025 FDA cleared K252586, a Special 510(k) from Odin Medical. The submission “addresses an update to the device’s Convenience Feature (Cecum AI …) model algorithm” — one AI model inside one convenience feature. It still required a submission, standalone performance testing and an FDA review cycle. The words PCCP and Predetermined appear in it zero times. The PDF ships in the package as K252586.pdf; count them yourself.
In 2025 FDA cleared K243274 for the CDC influenza panel. Of that submission its own 510(k) Summary says “No technological characteristics were changed.” Nothing about the device was different. The submission existed to establish the plan. That sentence is the span bound to the source document’s bytes and carried in K243274_source_extract.txt. The fuller quotation this page previously showed — naming the plan directly — sits in the operator’s notes and is not inside the bound extract, so it is not shown here until it is. A quote outside the binding is an illustration.
Somebody paid for a submission to get a plan. Somebody else paid for a submission because they were making a change without one. The plan is the asset. What it is worth depends entirely on whether the organisation can rely on it under pressure.
The obvious objection is that a model could just read the 510(k) and extract the plan. FDA does not use one name for the plan.
That is not an inference. It was measured across nine FDA documents covering seven clearances, and the inconsistency is FDA’s own: two documents FDA wrote about the same submission call the same authorized plan by different names.
For K243804, the clearance letter says FDA’s determination “included the review and clearance of your Predetermined Change Control Plan (PCCP)”. The Decision Summary for the same submission, also written by FDA, instead calls it a breakpoint change protocol. It uses the string PCCP zero times.
A filter searching for PCCP reports that document as having no plan. It has one, and FDA authorized it. Searching instead for FDA’s authorization sentence catches that case and misses K253281, whose authorization lives in a Decision Summary section rather than a clearance-letter paragraph. Two independent lexical methods, two different false negatives.
The same collapse shows up in this package’s own measurements. Extraction recall runs 1.000 on the documents as written and 0.231 after paraphrase — and changing one literal string, The planned modifications include:, drops it from 1.000 to 0.308 by itself. Modification detection rests on two exact strings. That number is published in accuracy/EXTRACTION_ACCURACY.json and labelled a demonstration rather than a rate, because the substitutions were the builder’s own. K243804 shows the same collapse occurring in FDA’s own words, with nothing substituted at all.
A laser has operating limits. A sensor has tolerances. A validation protocol has acceptance criteria. A manufacturing process has controlled parameters.
A PCCP creates another boundary: the changes FDA has already authorized you to make, and the conditions those changes have to satisfy. ENVOLOK executes that boundary against a proposed change before it ships, and signs a receipt saying what it checked.
In July 2025 FDA cleared K251149, an update to Cutera’s 1726 nm AviClear laser. The whole change: a new handpiece with a 3 mm square spot, and post-treatment skin cooling reduced from 2 seconds to 1 second.
That took a full 510(k), filed April and cleared July, plus a prospective clinical study — ten subjects scheduled for abdominoplasty and rhytidectomy, laser treatment on pre-excised skin, histology read by an independent dermatopathologist. The submission contains no PCCP. The words PCCP and Predetermined appear in it zero times. This is an engineering analogy, not a governed case. Nothing here claims a PCCP would have covered that change — only that a one-second timer adjustment went through a clinical study and a review cycle.
K250392, cleared 3 November 2025. The ZAP-X Radiosurgery System, a self-shielded 3 MV linear accelerator. FDA’s clearance letter says it plainly: “FDA’s substantial equivalence determination also included the review and clearance of your Predetermined Change Control Plan.”
The plan authorizes one thing: an additional circular beam 3.0 mm across, with a new collimator wheel and the planning and delivery software to commission, select and deliver it. The device already has eight beam sizes, from 4.0 to 25.0 mm. ENVOLOK runs sixteen cases against that plan and agrees with it sixteen times.
ZAP-X is not a laser, and this page does not call it one. It fires x-rays. But IEC 60825-1, “Safety of laser products”, is in that submission’s own FDA-recognized standards list, alongside IEC 60976, IEC 62083 and IEC 60601-2-1 — the standards its authorized plan requires the change to be tested against. If you work to those, you are reading a boundary written in the vocabulary you already use.
A 2026 review found authorized PCCPs across FDA-cleared AI devices, and also found that the plans vary substantially in what they document. Even FDA's public database undercounted them: researchers found 34 radiology devices with authorized plans where the database listed 25.
A PCCP is not a one-time filing. It is a standing commitment that lasts as long as the device is on the market — and what is inside one gets asked in a release meeting, not in a database.
FDA finished the guidance in 2024 and 2025. Most quality systems in this industry were designed before any of it existed, by people now carrying an obligation that did not exist when they built the process.
Every change made under an authorized plan has to be shown to be inside it. Not once. Every time.
| Meanwhile | Figure | When |
|---|---|---|
| Software issues, as a cause of device recalls 31 of the 236 US device recalls that quarter, second only to device failure at 48 |
2nd leading cause | Q1 2025 |
Devices are more software than they used to be, and software is a growing share of what goes wrong. The industry now has a mechanism for authorising future changes — but the resulting boundary still has to be interpreted and checked at every release. ENVOLOK makes that check executable.
ENVOLOK was built by attacking it and repairing what broke. One claim did not survive: an early version said it enforced scope, and a red team showed a mislabelled out-of-scope change still deployed. The claim was withdrawn and the product got smaller. It now demands a written description, a named asserter, and a boundary bound to its source — and the receipt states what it did not check.
Eight rounds. The record of every failure ships with the instrument.
The clearest example is a scoring one. A hostile layout test was scored by one method and passed most cases. The scorer was then rebuilt to be harsher, rejecting truncated and contaminated rule text, and the same run scored worse.
| The same run, two scorers | Lenient | Strict |
|---|---|---|
| Cases fully passing across five hostile document layouts | 3 / 5 | 0 / 5 |
| After repair, re-tested against the strict scorer | — | 5 / 5 |
The worse number was published as the authoritative one. The strict
0 / 5 is in layout_authority/REPORT.md, and the repaired
5 / 5 is reproducible: run
layout_authority/run_v20_closure_gauntlet.py. The lenient number was never
the one reported.
Before a modification ships, someone picks its category from the list your plan permits. ENVOLOK checks that the category is on the list. It does not check that the modification belongs in the category.
Nihon Kohden added a Silence Alarms function to a cleared patient monitor. At decision point B2 of their own regulatory assessment — is it a control mechanism, operating principles, or energy type change? — they selected No, and filed a letter to file. In June 2026 FDA wrote that Yes was the correct answer and that it required a new 510(k). ENVOLOK would have cleared that release, because the category they chose was one the plan permitted.
The judgment is a person's and no software will make it. What ENVOLOK does is put the category, the written description, and the name of whoever chose it into a signed record that cannot be edited afterward. The call stays human. It stops being anonymous.
There is a test in the package called K1d. It miscategorizes a
modification and confirms the release still goes through. It passes. It is supposed
to pass.
A category on its own is a value picked off a list. The engine will not grade a modification without a written account of what changed, and it will not accept "tweak."
Somebody has to assert that the category describes the modification. Their name and the date go into the signed record. A wrong category is no longer invisible. It is permanent and it belongs to someone.
The boundary has to name the document it came from, with a hash and an attestation, or nothing is graded at all. A boundary with no provenance is a boundary somebody typed.
And the receipt carries its own limits inside the signed body, so they cannot be stripped without breaking the signature. In plain words, on every record it produces:
Not verified: that the asserted label correctly describes the actual change. A named person asserted that. It is recorded here, not proven. from the receipt schema, on every ENVOLOK verdict
A receipt that implies more than it checked launders a human judgment into a machine verdict. That is the failure this exists to prevent.
Three kinds of product get pitched into this gap. None of them does this job.
Your eQMS records that a modification was approved and routes it to the right signatures. What it does not do is execute the boundary and tell you whether this particular modification satisfies it. Several of those vendors publish long explainers about PCCPs; every one ends in a demo request.
Gartner named that market in June 2026 and it is a real one, aimed at NIST AI RMF, ISO 42001 and the EU AI Act. It governs AI in general. ENVOLOK has a narrower job: check one modification against the encoded PCCP boundary and produce the verdict and the evidence record. Among the leaders, enforcement at the point of deployment is still described as roadmap.
A consultant helps you write the plan and get it authorized. That is real work and worth paying for. ENVOLOK works afterward, when the organisation has to keep making modifications inside that plan for the life of the device.
ENVOLOK is the check. It executes the boundary a named person encoded and attested from the authorized plan, and returns a verdict on the modification under review. If your eQMS or your governance platform already does that, do not buy this — ask them to show you the verdict and the rule it cites.
Eleven documents. Between them they hold every figure on this page. Not one was published by ENVOLOK.
Not a demo on another company's device. Use the plan FDA authorized for one of yours, a modification actually under review, and a verdict that can be checked line by line against the encoded boundary.
Redact whatever you need to. Under NDA if your legal team prefers. ENVOLOK runs on your machine, on your side of the firewall, and makes no network calls during evaluation.
If it disagrees with your own reading of the plan, that is worth knowing too.
hello@envolok.com