Code Provenance in AI-Assisted Take-Homes: What You...

You finish a take-home assignment and find one final field: “Describe any AI assistance.” Five minutes before submission is the wrong time to reconstruct code provenance. Memory makes material help sound vague, while copying raw transcripts may expose assignment content you were never allowed to retain.

For a candidate, code provenance is a practical account of permitted origin and contribution: which employer rule applied, what AI assistance materially influenced the work, what you changed, how you checked the result, what you disclosed, and what you must not keep. It is not a second engineering audit system. The detailed request-to-diff-to-test evidence chain belongs in the AI interview audit-trail guide.

Read the Employer Policy Before Choosing a Tool

Take-home instructions usually create one of three working states.

Prohibited: Do not use AI for the assessed work. Read whether the restriction also covers autocomplete, external explanation, preparation, or only solution generation.

Permitted with conditions: The employer may allow certain tools, require disclosure, limit what data can be entered, or restrict AI to brainstorming, debugging, or test ideas.

Unclear: Ask before using the tool. An installed assistant, common industry practice, or another employer's policy does not establish permission.

Anthropic publishes candidate AI guidance for its own hiring process. It shows why candidates must look for company-specific instructions; it is not an industry-wide rule. The broader AI take-home assignment guide can help you clarify the assignment workflow before work begins.

Keep the policy reference in the employer-approved location. Record the version or date you relied on if the process supports that. When instructions change, follow the latest authorized direction and note the change without copying restricted content elsewhere.

Classify Material Contribution, Not Every Keystroke

A provenance note should be complete enough to avoid hiding meaningful assistance, but concise enough to remain useful. Materiality is the filter.

AI assistance is usually material when it influences:

externally visible behavior or a key algorithm;
architecture, data flow, persistence, or public interfaces;
authentication, authorization, privacy, or security;
dependencies, licenses, generated assets, or external code;
test strategy or acceptance criteria;
a trade-off you must explain in the submission or review.

Spelling changes, formatting, and a short completion that you immediately replace may not need separate entries unless the policy says otherwise. Do not use that exception to hide a generated core function or design decision.

Classify the contribution by its role: exploration, option comparison, implementation draft, debugging, test ideation, documentation, or explanation. “AI helped a little” is not a useful category. “Used AI to compare validation approaches and draft keyboard-navigation edge cases” tells the reviewer what kind of influence occurred without dumping the conversation.

Keep a Contribution Log While the Work Happens

The smallest useful log is created during the assignment, in a location the employer permits. Each material entry can fit in five short fields:

Tool and purpose: which approved tool helped with what goal.
Contribution category: options, code draft, debugging, tests, or explanation.
Affected area: the feature or behavior influenced.
Candidate modification: what you accepted, rewrote, narrowed, or rejected.
Verification and disposition: what you checked and whether the entry must be disclosed, retained, or deleted.

For example: “Used an approved coding assistant to compare keyboard focus-management approaches and suggest edge cases. I kept the edge-case list, rejected a new focus-trap dependency, and rewrote the helper around the repository's existing DOM utility. Focus-return and keyboard-navigation checks passed; the full browser matrix was not run. Include in final disclosure, then retain only as instructed.”

This log attributes influence without claiming that the assistant's entire response entered the submission. It also makes the final disclosure a short editing task rather than a memory exercise.

Record the Human Modification Without Creating a Second Audit Trail

Provenance needs one clear sentence about human transformation. It does not need a second-by-second history of every prompt, commit, and rejected branch.

Use action verbs: accepted, rewrote, narrowed, combined, rejected, or removed. Then name the reason at the level needed for attribution. For example: “Rejected the suggested dependency because the repository already had an approved utility; rewrote the helper to match that interface.”

That sentence satisfies the core ownership question: the generated option was not treated as an unquestioned final answer. Human modification may be a complete rewrite, a bounded correction, or an evidence-based decision to accept the output as written. Describe what actually happened rather than implying that only a full rewrite counts as ownership.

GitHub documents commits as records of repository changes, so a coherent commit can support the provenance note. It cannot by itself prove who conceived each line. If a reviewer needs the exact request, reviewed diff, relevant test, and final decision, hand off to the audit-trail method instead of expanding the contribution log into a duplicate framework.

Add a Verification Receipt at the Right Granularity

Human modification and verification are required because provenance should not describe only where an idea came from. The candidate must still take responsibility for the submitted result.

Keep the verification field concise: name the risk checked, the relevant result, and one important limit. For the focus-management example: “Keyboard focus returns to the trigger after closing, and tab navigation remains contained in the intended flow; Safari was not included in the available browser run.”

Avoid two extremes. “Tests passed” is too vague to support a material contribution. A page-long test chronology turns provenance into an engineering audit and obscures the disclosure. The contribution log only needs enough information to show that the final result was not accepted blindly.

NIST's Secure Software Development Framework treats verification and secure development practices as normal software work. It does not prescribe a take-home disclosure format or guarantee that one test suite proves safety.

For a broader portfolio claim rather than a single assignment contribution, the AI project proof guide provides a more expansive artifact method.

Turn the Log into a One-Minute Final Disclosure

Use the employer's form when one is provided. Otherwise, a concise final note can follow five lines:

Policy: State the instruction you followed.

Material assistance: Name the approved tool and meaningful contribution categories.

Human modification: State what you rewrote, narrowed, accepted, or rejected.

Verification: Summarize the relevant checks and their material limit.

Scope: Confirm which submitted areas were not materially AI-assisted when that clarification is useful.

Example:

“The assignment permitted AI assistance with disclosure. I used an approved coding assistant to compare focus-management approaches and suggest keyboard edge cases. I rejected an added dependency, rewrote the helper around the repository's existing utility, and authored the final integration. Focus-return and keyboard-navigation checks pass; the available run did not include Safari. No AI tool was used to generate the written product rationale.”

Disclosure improves transparency; it does not promise acceptance. The employer still evaluates policy compliance, technical quality, and whether you can explain the work.

Apply the Retention and Confidentiality Boundary

A provenance record does not authorize you to copy confidential prompts, private repository code, secrets, customer data, or unpublished interview questions into a personal log or public tool. Use only employer-approved systems and omit protected details from summaries.

Decide the disposition of each log entry when you create it: include in submission, retain in the approved workspace, or delete after the required period. Do not keep a personal archive “just in case” when the assignment says materials must be removed.

SLSA provenance concerns verifiable software artifact origin. It is a useful analogy for thinking about origin and transformation, not a default hiring attestation. A candidate usually needs a readable contribution note, not a supply-chain document, unless the employer explicitly requests one.

The privacy and local processing guide can help you ask where data is processed and retained. The assignment's policy remains controlling.

Interview AiBox can help you rehearse follow-up questions from your own permitted contribution summary during preparation. It should never receive a restricted assignment, confidential repository, or raw prompt history merely to make the disclosure sound polished.