AI design for structuring regulated data.
Most AI design thinking treats trust as a UX problem: can the user understand and verify what the AI produced? In regulated industries, the bar is higher. Outputs have to be auditable, traceable, and defensible to a regulator who wasn't in the room. These two tools explore what AI-assisted workflows look like when that's the requirement.
The context is biotech R&D. Scientists in regulated labs operate under frameworks like 21 CFR Part 11 that govern not just what data is captured, but how, by whom, and when. Decades of institutional knowledge exist as unstructured documents: protocols written for humans, not machines. Getting that knowledge into structured, auditable Electronic Lab Notebook (ELN) systems requires expert manual labor; exactly what AI should be able to help with, if scientists can trust it enough to act on the output.
Standard Operating Procedures are written by humans for humans: usable by a trained scientist, but not by the systems that need to store, query, and audit the work. ELNs need discrete fields, defined types, and compliance annotations tied to specific regulatory text. This tool does that translation.
GxP flags surface compliance concerns specific to this SOP's content: not generic warnings, but issues a scientist can actually look up and verify. Compliance notes anchor specific regulatory citations to the section they govern. Field types signal data structure commitments: a date field can be validated against a system clock; a text field can't.
The template is a starting point for human review, not a finished artifact. The AI does the translation; the scientist corrects and verifies. The stakes are higher than mere typos: a misextracted field can become a regulatory finding.
The two tools are sequential steps in a single workflow: the template produced by the SOP Generator informs the structure of the Experiment Canvas.
The canvas is where a scientist runs an experiment against the template.
For example, the Materials & Reagents section uses structured fields pulled from the free text of the original SOP. Free text says "there is data here." A structured expiration date field says whether that data is present, valid, and current; or flags exactly what's wrong. Each step up is a step toward a compliance record a regulator can verify, rather than one they take on faith.
Expired reagents are flagged, but do not prevent submission. An expired reagent might be usable with supervisor sign-off, and blocking on expired would prevent a reviewer from ever seeing the flag that needs their attention.
The audit trail appends on state transitions, so a regulator returning to the record months later can reconstruct exactly what happened and in what order.
Machine-verifiable compliance vs. trust-based compliance. The design goal isn't verification everywhere, that would make the system unusable. It's knowing which fields carry enough regulatory weight to verify mechanically, and designing the trust layer carefully everywhere else.
In practice, that line isn't obvious. It's a research question: one that changes by workflow, by user role, and by the specific regulatory framework in play. These prototypes are a starting point for that conversation, not an answer to it.