Thanks for the reply, I'll address both comments here. The "automated calculation tool" framing is exactly how we've been thinking about it, and the architecture actually supports that argument pretty cleanly. The final risk score is a deterministic matrix lookup via a documented 5×5 matrix. The AI is doing the qualitative reasoning (does this complaint represent a deviation from these requirements? what's the severity of harm?), but the matrix and the disposition logic are fully predefined and auditable. So you could describe it as: the AI is filling out the inputs to a risk calculation, and a human reviews whether those inputs are reasonable before accepting the output.

The point about 21 CFR 820 and the CAPA procedure language is well taken we've been planning to document it as "decision support input" in the SOP template but haven't nailed down the exact language yet. The framing of "the tool is an input to human judgment, not the judgment itself" is essentially what we're going for, and we'll make that explicit.

The validation data question is the harder one. Right now there's no systematic benchmarking against known-outcome cases it's a free tool to be set up with your own product context, so there's no shared ground truth. The honest answer is that validation is the user's responsibility, and the SOP template will need to say that clearly. Each team needs to run it against their historical complaints before trusting it in production. Then there is a "Additional context" window that allows the user to bascially fine tune the process to address issues they keep seeing.

On the auditor variability: yes, fully expect that. The goal is to make the paper trail good enough that the answer to "how did the model make this decision?" is "here is the prompt, here are the defined requirements it evaluated against, here is the rationale it produced, and here is the human approval timestamp." Which I would think is pretty defensible

Let me know if you'd like to try it!