The AI Interview Audit Trail: Prompts, Diffs, Tests...

An interviewer asks, “Which parts came from the AI, and which parts did you decide?” A weak answer lists tools or says the tests passed. A credible answer follows one reviewable chain: material request, reviewed diff, relevant test, and human decision.

That chain is the purpose of an AI interview audit trail. It is not a complete work diary, a transcript archive, or a general disclosure policy. The code provenance guide covers employer rules, contribution classification, final disclosure, and retention boundaries. Here, the task is to make one technical decision easy to inspect and explain.

Start with the Four Receipts the Reviewer Needs

Every useful audit entry should let a reviewer answer four questions without reconstructing your entire session.

Material request: What meaningful outcome did you ask the tool to help produce, and which constraints remained fixed?

Reviewed diff: Where did that assistance affect the code, and what did your review find?

Relevant test: Which check addresses the specific risk introduced or changed by that diff?

Human decision: What did you accept, revise, reject, or defer, and why?

Each receipt constrains the next: intent needs a diff, the diff needs review, the test needs a claim, and the decision needs those anchors. Missing links turn evidence into a memory-based story.

One entry should cover one material behavior. If the AI helped with an export bug and a separate caching decision, create two chains. Combining unrelated work makes both harder to defend.

Write the Material Request as a Bounded Summary

Do not begin with every prompt. Begin with the request that could materially affect behavior, architecture, security, data handling, dependencies, public interfaces, or the explanation you must defend.

A useful request summary has three parts:

Goal: the behavior or decision you needed help with.
Constraints: contracts, scope, or risks the answer must preserve.
Expected output: options, a patch, test ideas, or a diagnosis.

For example: “Propose a fix for CSV export timestamps crossing a daylight-saving boundary. Preserve the existing response schema and display format. Return a minimal patch plus focused test cases.”

This gives the reviewer a standard for inspecting the change without preserving a long exploratory transcript.

If the employer or platform does not allow you to retain the request wording, do not create a private copy. Use only an approved summary or point to the permitted work item. Anthropic's candidate guidance is one example of a company publishing its own expectations; it is not a universal retention rule.

The AI take-home assignment guide can help you clarify permitted use before the assessed work begins.

Anchor the Request to a Reviewed Diff

The next receipt is not merely “commit abc contains the fix.” It is the exact change you reviewed against the original constraints.

Record the affected behavior and the smallest useful location: a pull-request diff section, coherent commit, or file and function reference. Then add the review finding that changed or confirmed your decision.

In the timestamp example, suppose the generated patch normalizes values in the export serializer but also changes the user-facing date formatter. Your review note could say: “The serializer change addresses the export boundary. The formatter change alters an unrelated UI contract, so I removed it.”

That note establishes two important facts. First, you inspected blast radius rather than accepting a plausible patch wholesale. Second, the final diff can be compared with the request constraint to see whether the public display format stayed unchanged.

GitHub documents commits and pull-request review history as records of software change. Treat those records as anchors, not proof of complete authorship or complete prompt history. A commit shows content and sequence; a review note explains a decision. Neither records every discarded thought automatically.

For broader advice on connecting project claims to artifacts, see the AI project proof guide.

Attach One Relevant Test to the Changed Risk

The test receipt must answer the risk exposed by the reviewed diff. “CI passed” is not enough because CI may contain no check for the affected boundary.

Use a compact claim, evidence, and limit format.

Claim: what behavior should now hold.
Evidence: the focused test or observation that exercises it.
Limit: the important path or environment the check did not cover.

For the export patch: “The focused cases show that timestamps on both sides of the daylight-saving transition serialize to the required UTC form, while the existing display-format snapshot remains unchanged. I did not run the full browser locale matrix.”

The evidence is relevant because it checks both the intended correction and the constraint the first patch threatened. The limit prevents a narrow test from becoming an unsupported universal claim.

Do not attach every test command to every entry. Choose the test that most directly separates a safe accepted change from the risky alternative. A build or type check can be secondary context, but it should not replace behavior evidence.

Name the Human Decision in an Action Verb

The final receipt should begin with an ownership verb: accepted, narrowed, rewrote, rejected, combined, or deferred.

“Reviewed the output” is not a decision. “Kept the serializer normalization, removed the unrelated formatter change, and deferred a broader date-library migration because the assignment did not require it” is.

Add one reason tied to a requirement or observed risk. Avoid vague phrases such as “my version was cleaner.” Better reasons include preserving a public contract, avoiding a new dependency, maintaining an existing error boundary, or keeping the patch within the stated scope.

Human modification does not need to mean rewriting every generated character. It means the final result reflects an accountable choice. You may accept an output after verifying it, substantially rewrite it, or reject it entirely. The audit trail should state which happened.

If rejection is the strongest part of the story, the guide to rejecting an AI suggestion shows how to connect the violated requirement to a safer replacement.

Reconstruct Missing Evidence Without Inventing It

Tools reset, prompt history may be unavailable, and some environments permit only repository artifacts. A missing record is not permission to manufacture a polished transcript.

Reconstruct from the strongest surviving receipts. Start with the final diff, identify the material behavior, and locate the focused tests and review comments. Then label each statement by certainty.

You can say: “The review history proves that the formatter change was removed after scope review. The test commit proves the transition cases were added. I remember asking the assistant for a minimal date fix, but the exact request wording is unavailable.”

That sentence separates documented fact from recollection. If you cannot connect an AI-assisted change to a request summary, do not pretend that you can. State the gap and explain what the remaining artifacts do establish.

For future work, capture the permitted one-sentence request summary and decision note at the time of review. The goal is not to record more. It is to avoid asking memory to recreate the only link that matters.

Deliver the Evidence Chain in Two Minutes

A strong verbal explanation follows the same four receipts and stops. Do not narrate every interaction or open a folder of screenshots.

Use this sequence:

state the material request and its fixed constraints;
point to the reviewed diff and the issue you noticed;
name the relevant test and its limit;
finish with your accept, revise, reject, or defer decision.

For example:

“I asked the assistant for a minimal fix to CSV timestamps around daylight-saving transitions, with no response-schema or display-format change. The first diff normalized export values correctly but also modified the UI formatter, so I removed that unrelated part. Focused transition tests pass, and the existing display snapshot is unchanged; I did not run the full browser locale matrix. I accepted the serializer fix, rewrote the boundary handling to match the repository convention, and deferred a broader date-library migration.”

This explanation is short because the artifacts carry the detail. The request defines success, the diff shows what was reviewed, the test addresses the changed risk, and the final sentence makes the human decision explicit.

Interview AiBox can help you rehearse this two-minute explanation from your own permitted materials during preparation and recap. It should not be used to retain restricted prompts, interview content, or employer code.