From practice to evaluation

“This is AI work, and I am not technical.”

It is the single most common reason people close the page. It is also backwards. Nothing in this work requires you to know how a model is built, any more than being a good witness requires you to know how a courtroom is constructed. The scarce input is your professional judgment. The technical part is somebody else's job.

Reviewing a junior's work. Explaining precisely why something is wrong. Knowing what a defensible answer looks like in your field. Recognising when someone is confidently out of their depth.

If you have supervised, examined, marked, audited or peer-reviewed, you have been doing a version of this already. The object under review is unfamiliar; the judgment is not.

Two things, in our experience.

The first is writing for a reader who is not in your field. Research teams are excellent engineers and not clinicians, lawyers or actuaries. Your explanation has to carry its own context.

The second is separating the conclusion from the reasoning. In practice you mostly care whether the answer is right. Here, an answer that is right for the wrong reason is a more serious finding than one that is simply wrong — because it will fail unpredictably on the next case.

Most people do five to fifteen hours a week, asynchronously, with deadlines rather than fixed sessions. It runs alongside clinical work, chambers, practice or teaching.

The first submission on any project comes back with specific feedback before you continue. Nobody is expected to be calibrated on day one.