By Bill Hartzer · Published · How this site is researched
Most of what goes wrong with AI in expert work goes wrong before the first request is typed. The expert did not know a protective order covered the material, did not agree anything with counsel, did not start a log, or asked the system a question that should have been answered from the expert's own analysis. Every one of those can be settled in advance, and none of them can be repaired afterward. This checklist puts those decisions in the order an engagement meets them.
It is organized in three stages: once per matter, before each use, and before anything enters the report. Each item names the clause of the Expert Record Standard it serves, so a firm that has adopted the Standard can use this as the working version of it.
Before the engagement starts
Once per matter
Find out what already governs AI use in this matter.
A court rule, a judge's standing order, a protective order, an arbitral rule or the engagement letter itself may restrict, condition or require disclosure of AI use. Read them before the first request, not after the first draft.
Agree the protocol with retaining counsel, in writing.
Say how you intend to use AI systems, for which kinds of task, and what will be disclosed. Anything beyond mechanically checkable work should be cleared with counsel before you begin, because a client objection raised after the analysis is done cannot be cured.
Put everyone who touches the work under the same protocol.
Associates, research staff, subcontracted specialists and translators are inside your signature. If they use a system, you have used it, and you will be the one asked about it at deposition.
Take stock of the systems you already use.
Transcription services, document review platforms, search tools and spreadsheet assistants increasingly carry AI inside them. Under the Standard's definition, a system operating inside other software is still a system.
Choose the system deliberately, and record why.
Note which system, which account and which tier you will use, and why that one rather than the alternatives. Read the provider's terms on retention, training on your inputs and deletion before any case material goes near it.
Open the contemporaneous log on day one.
Start it before any system is used, and record days with no system use as well. A log that begins when you first think you need one begins too late.
Before each use
Every time
Name what you would check the answer against.
If you already hold it, the task is green: proceed and log it. If you would have to go and get it, the task is yellow: proceed, get it, read it, and log the verification. If nothing comes to mind, stop. That work is yours.
Form and record your own view first.
On any question that bears on the opinion, write down what you think before the system sees the question. The order cannot be repaired afterward, and the log will show it either way.
Confirm you are free to submit the material.
Protective orders, privilege, personal data and third-party license terms can each prohibit an upload. Answer the question before the upload, because it is a question about compliance with an order, not about preference.
Make any analysis a procedure, not a conversation.
If the output will support a finding, write it as a script or documented procedure that runs on the produced data and returns the same answer each time.
Set limits before a system acts on its own.
Some systems plan and carry out several steps without further instruction. Decide in advance what such a system may do, and keep a record of each action it took, not only the instruction you gave it.
Write the log entry as you go.
Date, system and account, the task, what you gave it, and what you did with the output. Record the verification, not merely the use.
Before anything enters the report
At adoption and at signing
Check every checkable assertion against an independent source.
Citations, figures, dates, quotations and specifications are confirmed against a source that exists independently of the system. Verify at the moment of adoption, not in a pass at the end.
Read summaries and translations against the source text.
Fluent output can still be skewed. A system can tilt a characterization, drop a qualification or carry assumptions from the material it was trained on, and the only reliable check is the original.
Confirm no conclusion traces to a system.
What the evidence shows, whether a standard was met and what the opinion is are judgments with no primary source to check them against. Those are yours alone.
Decide what you will disclose, and how you would answer if asked.
Meet whatever the rules, orders or engagement require. Then write the one-paragraph answer you would give at deposition: which systems, for which tasks, what you verified and against what, what you declined to use them for, and that the log exists.
Apply the governing test.
Could a competent examiner in your field, working only from the primary sources and with no access to any AI system, reproduce your result? If not, the work is not ready to sign.
Where the checklist meets the rules
In federal civil cases a retained expert's report must state the basis and reasons for each opinion and the facts or data considered in forming them, under Federal Rule of Civil Procedure 26(a)(2)(B). Several items above exist so that you can answer that requirement with a record rather than a recollection: the log opened on day one, the verification recorded at adoption, and the one-paragraph account of which systems you used and for what. State rules and arbitral rules are worded differently, and counsel should confirm which one governs your matter.
The rules on AI use itself are still moving. Court rules, standing orders and ethics opinions are collected, with their current status, under rules, orders and guidance, and the matters in which an expert's AI use was challenged are under expert witnesses and AI. None of them changes the order of the decisions on this page.
The full working versions are in the working papers: the log template, the engagement letter provisions and the verification checklist that governs what happens after a system has produced something.
Questions about this checklist
Is this checklist the same as the verification checklist in the book?
No. The verification checklist in the working papers governs what happens after a system has produced something: how each category of assertion is checked and what to do when a source cannot be found. This page covers the decisions before and around each use. The two are meant to be used together.
Does every item apply to mechanically checkable work such as transcription?
Most of them do, in a lighter form. A transcription where you keep the audio is green work, so the check is cheap, but it still belongs in the log and the material still has to be yours to upload. The items that fall away for green work are the ones about forming a view first, because there is no view to form.
Can I adopt this checklist in a firm policy?
Yes. It is written to sit beside the Standard, which is licensed for verbatim adoption. If you reproduce it, attribute it to The Expert Record and link to this page so readers get the current version.
Why log every use rather than only the risky ones?
Because you rarely know at the time which use will be the one examined. Clause 7 logs every use, including the ones that turn out not to matter, and records days with no system use as well. A log that only records risky uses invites the question of what else was left out.