For Fraud Examiner / Financial Investigators ·
What you'll accomplish
Each interview plan starts from a blank page: which topics, in what order, which document under which topic, and how to phrase questions so they do not suggest the answer. You will save that routine as a Gem in Gemini so a coded case summary goes in and a topic list, a document order and open, non-leading questions come out. The same neutral rules apply every time, and anyone on your team can use the same setup. The plan is a first draft. You revise it with your knowledge of the case, and the interview itself belongs to you, your supervisor and counsel.
A note on Gems: Google is replacing Gemini Gems with skills, starting in November 2026 for personal accounts and in 2027 for work and school accounts. Google's help page says existing Gems are recreated as skills automatically, so a Gem built today carries over.
What you'll need
Data caution. Interview planning touches people and records, so use coded summaries only: "Witness B, accounts payable clerk", "payment batch P-14", never a name, an account number, a date of birth, an address or a health detail. Whether real case summaries may go into Gemini at all depends on your employer's AI policy and an approved account type. Check your account's activity and data settings to see whether chats are kept and whether they may be reviewed or used to improve Google's models. The workflow works the same on an invented summary, which is what the practice run below uses.
Rules belong to others. The Gem never states rules about rights, representation or recording. Check your unit's interview policy, and ask counsel about anything involving rights, representation or recording. A recording or transcription tool is a separate decision under your unit's policy.
Open a document and paste the text below. Edit it to fit your unit's terms.
You help a fraud examiner plan an interview from a coded case summary.
Input: a coded summary with the interviewee's role (for example "Witness B, accounts payable clerk"), the records held (named by code), and the topics to cover.
Output, in this order:
1. A numbered topic order, with one line on why each topic follows the one before it.
2. For each topic, which record (by code) to show, if any.
3. For each topic, three to five open, non-leading questions. Questions must not suggest an answer, assume a fact not in the summary, or contain a conclusion about the interviewee.
4. A short list of items from the summary that need confirming before the interview.
Rules:
- Add no facts that are not in the summary.
- Never suggest a conclusion about the interviewee's honesty, intent, role in wrongdoing or credibility.
- Never state or suggest rules about rights, warnings, representation or recording. If asked, answer: "Check your unit's interview policy and ask counsel."
- Keep codes exactly as given.
- The plan is a draft for the examiner to revise.
What you should see: a one-page set of instructions you can read in a minute. Troubleshooting: If you have your own wording rules for questions, add them as short bullets. Long instruction lists are followed less reliably.
Google's help page describes opening the sidebar and seeing your Gems, each with an Edit option.
What you should see: a Gem editor with a name field and an instructions field. Troubleshooting: Labels change, and Gems are being replaced by skills. If you see Skills instead of Gems, create a skill with the same name and instructions. Google says a skill is a reusable set of custom instructions, and the same text works.
The Gem editor may offer a place to add files as knowledge (Google's help page refers to files under "Knowledge").
What you should see: the file listed under Knowledge. Troubleshooting: If the outline mixes templates with real case references, make a clean copy first.
Save the Gem. Then start a chat with it and paste the invented summary below. It is made up for this guide.
Interviewee: Witness B, accounts payable clerk at Company X (invented).
Records held: payment batch P-14, approval log A-3, vendor change request C-9.
Topics to cover: how vendor changes are requested, who approves them, and what Witness B did on the dates in batch P-14.
Give a topic order, which document to show under which topic, and open questions that do not suggest an answer.
What you should see: a numbered plan. Topic 1 might cover the routine for vendor changes, with C-9 shown, and questions such as "Walk me through how a vendor change request reaches you." Topic 2 might cover approvals, with A-3 shown. Topic 3 might cover Witness B's own work on the batch P-14 dates, with P-14 shown. A short list of items to confirm closes the plan. Troubleshooting: If a question is leading ("You approved the change, didn't you?"), tell the Gem which question and why, and ask for a rewrite. If it adds a fact not in your summary, say "That is not in my summary. Remove it."
What you should see: a plan that reads like yours, with every question open. Troubleshooting: If you rewrite most of the plan every time, add a bullet to the instructions that describes your usual structure.
Second interview, same case:
Interviewee: Witness C, approver at Company X (invented). Records held: A-3, P-14. Topics: approval steps, thresholds as Witness C describes them, and what Witness C saw on the P-14 dates. Plan the topics, documents and open questions.
Check my questions:
Here are my draft questions: [paste coded questions]. Mark any that are leading, that assume a fact, or that combine two questions in one. Rewrite those as open questions.
Follow-up after the interview:
From my coded notes, list the topics that still need an answer and the record codes that might address each. Do not state what the interviewee meant.
Document order only:
Given the topic list and the records [codes], suggest the order in which to show each record. Give a one-line reason for each.