Progress since the last update
It has been a year since ACX Grants backed OpenReg, and this is the first update I have posted. That is my fault and I am fixing it. Here is where the work actually stands.
The thesis held up. The premise was that FDA premarket documentation costs a startup $20,000 to $50,000 largely because public rules and public precedent are unreadable at scale, and that turning them into machine-readable software removes an unnecessary bottleneck. Everything since has pointed the same way.
What shipped, open source. pdfer, a pure-Go PDF library with zero dependencies, built because parsing and generating FDA submission documents needed primitives nothing off the shelf provided. onnxer, Go bindings for ONNX, now with outside contributors. And we have reverse-engineered the eSTAR itself, including the XFA form structure FDA uses for submissions, which is the piece the $100k milestone was pointing at.
The corpus. The full public CDRH record is normalized and indexed, every word of every filing rather than the three fields FDA's own search exposes, linked to CMS reimbursement codes, clinical trial evidence, and patent records. It re-syncs on FDA's publication cadence: weekly for clearances, near-daily for recalls and warning letters.
Research output. We published the first full census of Predetermined Change Control Plan adoption, the mechanism FDA uses to let a cleared model change without a new submission. Preprint: https://ssrn.com/abstract=7127401
Against the stated milestones. The $100k tier was the core MVP with PDF parsing and an interactive web application. PDF parsing is done and open source, and the web application is live. The $200k tier was the AI Compliance Assistant; the research agent that returns structured claims and citations against the corpus is running.
What I got wrong
I framed OpenReg as a drafting problem: make the document cheaper to produce. The document turns out to be the least interesting part. Almost all the leverage sits upstream of it, in choices made before anyone writes a sentence, and the companies that handle this well run the regulatory process as part of their commercialization plan rather than as a compliance exercise that trails it. Four findings reordered the roadmap.
Most of your timeline is decided before you write anything. Across roughly 71,000 submissions, the dominant variables are structural. A Special 510(k) clears in a median 30 days against 144 for a Traditional. Third-party review runs 30 days against 128. In a random forest over the same data, pathway carries an importance of 0.45; firm experience carries 0.02. Preparation matters, and matters about five times more than a cross-section suggests once you compare a firm against itself rather than against other firms, but it is second-order and sits underneath a structural effect. The highest-value regulatory decision a company makes is which door it walks through, and it makes that one months before anyone drafts a section.
Precedent you own is faster than precedent you borrow. Citing your own prior device as predicate clears in a median 101 days; citing another firm's takes 147. The number of predicates is flat, and buys nothing. So the play is to get a first, narrow device cleared and build a lineage on top of it, rather than assembling a thicker citation list. That is a sequencing decision about the product roadmap, made for regulatory reasons, two years ahead of the filing it pays off in.
There is a free option on the table and almost nobody takes it. A PCCP pre-authorizes a defined set of future model changes, so in-scope updates ship against internal validation instead of a new submission. We ran the first full-text census: AI devices disclose one at roughly 7.1% against 0.64% for non-AI, about eleven times the rate, and still only one AI clearance in fourteen. There is no review-time penalty for including one, a median 156 days against 153. Both figures are floors, since the signal reads only the filings that publish a public summary. It was built for software that changes after clearance, it costs nothing in review time, and the companies it was designed for are not using it.
The endpoint that speeds you through FDA can cost you at the payer. This is the subtlety I most underrated. Breakthrough designation's real accommodation is evidentiary rather than temporal. The PMA review benefit is about 101 days. But designated devices lean on surrogate endpoints 29 percentage points more often and composite endpoints 21 points more, with no increase in hard clinical endpoints at all. FDA will accept a surrogate. A payer, deciding a year later whether to cover the device, generally will not. The trade that buys you a faster authorization is the same trade that creates the reimbursement problem waiting behind it. CMS rewired the link between the two twice this year: the RAPID Coverage Pathway in April, and a proposed repeal of the NTAP alternative pathway in the FY2027 IPPS rule. The teams that handle this well work backward from the coverage decision and pick their endpoints with it already in view.
A smaller finding with the same shape: you cannot define this category from the rulebook. We tried to identify AI and software devices from FDA's own product codes, and recovered 43% of the devices on FDA's own AI list, because the codes for imaging modalities contain no software or AI words at all. The regulation does not describe the thing it regulates. We stopped treating that as a data-quality problem to clean up and built the corpus on full text instead of fields.
What are the next steps
Continued open-source release of the parsing and corpus tooling, and finishing the traceability layer from user needs through requirements, risks, and tests. On the research side, the next two papers follow the thread above: what actually drives review time, and what breakthrough designation buys once you measure the outcome at market access rather than at authorization.
Is there anything others could help with
Yes. pdfer is the piece most likely to be useful to someone outside this domain, and it is the one I would most like other people to break. It is public at https://github.com/benedoc-inc/pdfer. If you work with PDFs in Go, please try it and file what fails. The XFA support in particular has had almost no eyes on it beyond our own submissions, and a library only used by the people who wrote it stops being a library.
