A Design That Argues With Precedent

Confidence: hypothesis. The failure modes below are drawn from published sources and widely reported industry patterns, not firsthand deployment. The buildable pattern at the end is unbuilt: I have not shipped it. Argue with it.

Design reviews have a predictable failure mode: the room agrees with the proposal because the proposal is well-presented, not because anyone in the room has actually checked it against what similar systems have done before and what happened to them. A retrieval-augmented model can fix the wrong half of that problem (it can find the prior art fast) while leaving the actual failure untouched, because finding precedent and arguing with it are different jobs, and most retrieval-augmented tooling only does the first one.

The clinical why

Before committing patients and years to a trial, a design team can retrieve the field's actual record: what endpoints, comparators, and populations the last hundred trials in this indication used, and what happened: regulatory reception, enrollment reality, effect sizes actually observed. This is design precedent assembly, and it is valuable precisely because a design team's remembered highlights and the field's actual record are reliably different things. Memory favors the trials people talk about, not the representative sample of what actually happened.

The trap is subtler than “the model didn't find enough precedent.” A retrieval system tuned to be helpful will tend to surface precedent that supports whatever direction the query already leans. It retrieves confirmation efficiently, because that's what “relevant results” usually means in a search context. A design team asking “show me precedent for this endpoint” gets exactly that, and reads a favorable answer as validation. The retrieval succeeded at its literal task and failed at the actual job, which was to pressure-test the design, not confirm it.