A chat answer says 'I checked the counter.' What happened? Perhaps the assistant only read pasted code. Perhaps a coding assistant opened a file. Perhaps an attached tool compiled it. Those are different activities with different evidence. Before trusting the sentence, establish which activity was possible and which actually occurred. You do not need to understand model training to ask this question.
A model is the component that generates an answer from the input it receives. An assistant is the surrounding application: it presents the conversation and may arrange files, instructions, permissions, and tools. A tool is a separate operation, such as reading a file, searching documentation, or invoking a command. A model name alone does not tell you which tools an application enables, what files it can see, or what your organization permits.
Interaction | What it can mean | Evidence to request |
|---|---|---|
Chat | Explain text supplied in the conversation. | Which supplied lines support each claim? |
Coding assistance | Suggest or edit code when the application supports it. | Which files changed, and what is the diff? |
Tool use | Ask an enabled operation to do work. | What operation ran, on which input, with what result? |
Human review | Accept, correct, or reject the result. | Who owns the decision and what remains unchecked? |
Synthetic interaction, not a model transcript:
Engineer: Explain this pasted counter. Do not edit files or run commands.
Assistant draft: I checked the design and it passes reset verification.
Engineer follow-up: State exactly what you observed and what you executed.
Corrected synthetic draft: I read the pasted reset branch. No verification
tool was run. The source assigns zero when reset is active at a clock edge.The corrected wording is narrower and useful. Reading a branch supports an explanation of the assignment; it does not establish that a testbench passed. If an assistant does have tools, a proposed command still differs from an executed command. A successful tool result also has a scope: compiling one file establishes neither full functional correctness nor timing closure. Keep those boundaries visible when copying an answer into a review note.
For a first session, write an allowed-actions statement: 'Use only the pasted synthetic source; explain it; do not read other files, edit, or execute commands.' Then inspect the application's actual permissions and settings. A prompt communicates your intention, but it is not a substitute for access controls. Grant only the capabilities needed for the task. If a tool requests broader access, reassess the task before granting it.
Record 'testbench draft supplied; execution unverified.' Inspect the code, identify the intended tests, and plan the appropriate authorized checks. Do not report a passing run. If execution evidence later appears, tie it to the exact source revision, command, and output.
Now identify a responsibility for each discipline. An RTL engineer checks intended behavior; a DV engineer reviews stimulus and expected results; an STA engineer checks constraints and analysis context; a PD engineer checks implementation conditions and reports. The assistant may prepare drafts for each person, but the person remains responsible for deciding whether the evidence answers the engineering question. Responsibility does not move to a model because its wording sounds confident.
Application capabilities and policies must be checked in the actual environment; this lesson makes no product-specific access promises. NIST AI 600-1, Generative AI Profile (July 2024) is a dated reference for considering risks across an AI workflow. Use your organization's approved process to assign ownership and permissions.