AI-generated dependencies need receipts

An AI assistant can add a dependency faster than a team can understand why it exists.

The generated change compiles, the package name looks familiar, and the pull request includes one clean import. Hidden behind it may be dozens of transitive packages, a permissive version range, an abandoned maintainer path, a new license obligation, a postinstall script, or a capability the platform already provided.

The OpenSSF guidance for AI code assistant instructions treats assistant configuration as part of secure development. I would extend that discipline to every third-party component an assistant proposes.

A dependency receipt is a short record of the requested capability, the chosen component, the alternatives considered, the supply-chain checks performed, and the person who owns updates or removal.

The point is not to reject packages. It is to make the new trust relationship visible before it becomes infrastructure.

Begin with capability, not package

The team should agree what needs to be accomplished before evaluating the assistant's suggested component.

I would pressure-test that decision with four questions:

• What capability is missing?
• Is it product-critical?
• Does the platform already provide it?
• Could a small local implementation be safer?

The failure mode here is accepting the first familiar dependency name. In AI-assisted code changes where a generated import, package, action, container, model, or copied snippet can silently expand the software supply chain and its security, licensing, maintenance, and operational obligations, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a capability statement above the package choice. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a decision that remains valid if the package changes. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a capability statement above the package choice beside the question “What capability is missing?” before the first implementation review. The next pass would use “Is it product-critical?” to test the boundary, then “Does the platform already provide it?” to expose the state most likely to be missed. I would keep “Could a small local implementation be safer?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a decision that remains valid if the package changes.

Verify the source

Generated names, repositories, versions, and examples can be stale, mistyped, or fabricated.

The practical review starts here:

• Does the package exist?
• Who publishes it?
• Is the repository linked?
• Does the version match documentation?

Those questions keep installing a plausible name before checking provenance from becoming the default. I would capture the decision in a source verification line with registry and repository, then use it while the work is still cheap to change. For AI-aware software supply chain review, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like fewer hallucinated or typosquatted dependencies. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a source verification line with registry and repository part of the working surface. I would use it to answer “Does the package exist?” while scope is still flexible, and “Who publishes it?” before code or content becomes expensive to unwind. During QA, “Is the repository linked?” and “Does the version match documentation?” become concrete checks rather than discussion prompts. That sequence turns AI-aware software supply chain review into something the team can operate and gives me a specific outcome to report: fewer hallucinated or typosquatted dependencies.

Inspect transitive scope

A small direct dependency can bring a much larger graph and a different risk profile.

Before implementation, I would answer:

• How many transitives arrive?
• Which run in production?
• Are versions duplicated?
• Which package owns native code?

The artifact is a dependency-tree summary and lockfile diff. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is reviewing only the direct package README; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is a clearer view of the code entering the system. That connects a dependency receipt as the review artifact that explains why new third-party code entered the system to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “How many transitives arrive?” easy to answer. The boundary should force a decision about “Which run in production?” and “Are versions duplicated?.” I would record both in a dependency-tree summary and lockfile diff, including the part that stayed unresolved after the first pass. The final check, “Which package owns native code?,” is where the artifact earns its place: it either supports a clearer view of the code entering the system, or it shows exactly why another iteration is needed.

Check executable behavior

Install scripts, plugins, actions, generators, and hooks may execute with developer or CI privileges.

I would use these prompts during the working review:

• Does installation run code?
• Which filesystem paths are touched?
• Are network calls made?
• What secrets exist in CI?

If the team slips into treating development dependencies as consequence-free, the product can still look complete while its operating rule stays ambiguous. I would make an execution and permission note the shared reference and keep it small enough to update as evidence changes.

The standard is review proportional to actual capability. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft an execution and permission note, review it against “Does installation run code?,” implement the narrowest useful path, and then return with evidence for “Which filesystem paths are touched?.” I would use “Are network calls made?” to inspect product consequence and “What secrets exist in CI?” to decide whether the result is stable enough to ship. This keeps treating development dependencies as consequence-free visible as a known risk and makes review proportional to actual capability the release receipt rather than a hopeful conclusion.

Review license and policy

AI-generated inclusion does not remove the organization's license, attribution, or acceptable-use obligations.

I would pressure-test that decision with four questions:

• Which license applies?
• Are transitives compatible?
• Is attribution required?
• Does policy permit the source?

The failure mode here is assuming generated code has no provenance question. In AI-assisted code changes where a generated import, package, action, container, model, or copied snippet can silently expand the software supply chain and its security, licensing, maintenance, and operational obligations, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a license scan result with human owner. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is fewer legal surprises downstream. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a license scan result with human owner beside the question “Which license applies?” before the first implementation review. The next pass would use “Are transitives compatible?” to test the boundary, then “Is attribution required?” to expose the state most likely to be missed. I would keep “Does policy permit the source?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports fewer legal surprises downstream.

Evaluate maintainer health

Release cadence, issue response, ownership changes, and project governance affect long-term support.

The practical review starts here:

• Who maintains the project?
• When was the last release?
• How are vulnerabilities handled?
• Is governance concentrated?

Those questions keep using download count as the only trust signal from becoming the default. I would capture the decision in a maintainer-health snapshot with date, then use it while the work is still cheap to change. For AI-aware software supply chain review, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like a more durable adoption decision. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a maintainer-health snapshot with date part of the working surface. I would use it to answer “Who maintains the project?” while scope is still flexible, and “When was the last release?” before code or content becomes expensive to unwind. During QA, “How are vulnerabilities handled?” and “Is governance concentrated?” become concrete checks rather than discussion prompts. That sequence turns AI-aware software supply chain review into something the team can operate and gives me a specific outcome to report: a more durable adoption decision.

Pin and reproduce

Builds should resolve the reviewed artifact rather than whatever satisfies a broad range later.

Before implementation, I would answer:

• Is the lockfile committed?
• Are hashes verified?
• Can CI reproduce resolution?
• Which update automation exists?

The artifact is a version and integrity policy in the receipt. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is merging a floating dependency range with no update owner; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is reviewed components that remain the ones deployed. That connects a dependency receipt as the review artifact that explains why new third-party code entered the system to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Is the lockfile committed?” easy to answer. The boundary should force a decision about “Are hashes verified?” and “Can CI reproduce resolution?.” I would record both in a version and integrity policy in the receipt, including the part that stayed unresolved after the first pass. The final check, “Which update automation exists?,” is where the artifact earns its place: it either supports reviewed components that remain the ones deployed, or it shows exactly why another iteration is needed.

Test the failure boundary

A runtime dependency needs explicit behavior for outage, malformed output, breaking change, and partial availability.

I would use these prompts during the working review:

• What if it throws?
• Can the core task continue?
• Is fallback safe?
• How is failure observed?

If the team slips into testing only the API's happy path, the product can still look complete while its operating rule stays ambiguous. I would make a dependency failure fixture and recovery state the shared reference and keep it small enough to update as evidence changes.

The standard is product behavior that survives third-party failure. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a dependency failure fixture and recovery state, review it against “What if it throws?,” implement the narrowest useful path, and then return with evidence for “Can the core task continue?.” I would use “Is fallback safe?” to inspect product consequence and “How is failure observed?” to decide whether the result is stable enough to ship. This keeps testing only the API's happy path visible as a known risk and makes product behavior that survives third-party failure the release receipt rather than a hopeful conclusion.

Assign lifecycle ownership

Someone must own advisories, upgrades, breaking releases, and the decision to remove the component.

I would pressure-test that decision with four questions:

• Who receives alerts?
• How often is it reviewed?
• What upgrade evidence is needed?
• When should it leave?

The failure mode here is letting the original generated PR become permanent anonymous infrastructure. In AI-assisted code changes where a generated import, package, action, container, model, or copied snippet can silently expand the software supply chain and its security, licensing, maintenance, and operational obligations, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be an owner and removal trigger in dependency metadata. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a supply chain with visible stewardship. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put an owner and removal trigger in dependency metadata beside the question “Who receives alerts?” before the first implementation review. The next pass would use “How often is it reviewed?” to test the boundary, then “What upgrade evidence is needed?” to expose the state most likely to be missed. I would keep “When should it leave?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a supply chain with visible stewardship.

Show dependency judgment in a portfolio

A strong artifact can show why the package was needed, how it was verified, what risk was reduced, and how the lifecycle is operated.

The practical review starts here:

• What alternative was rejected?
• Which hidden cost was found?
• What check became automated?
• Who owns the component now?

Those questions keep listing package names as proof of technical depth from becoming the default. I would capture the decision in a redacted dependency receipt and review diff, then use it while the work is still cheap to change. For AI-aware software supply chain review, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like credible evidence of secure engineering judgment. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a redacted dependency receipt and review diff part of the working surface. I would use it to answer “What alternative was rejected?” while scope is still flexible, and “Which hidden cost was found?” before code or content becomes expensive to unwind. During QA, “What check became automated?” and “Who owns the component now?” become concrete checks rather than discussion prompts. That sequence turns AI-aware software supply chain review into something the team can operate and gives me a specific outcome to report: credible evidence of secure engineering judgment.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a capability statement above the package choice
• a source verification line with registry and repository
• a dependency-tree summary and lockfile diff
• an execution and permission note
• a license scan result with human owner

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because a dependency receipt as the review artifact that explains why new third-party code entered the system becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

# capability
parse signed webhook events
Needed for provider v3; native crypto covers signing; package only parses canonical payload.
# decision
pin 4.2.1 with lockfile
Apache-2.0, active releases, no install script, four transitives, advisory scan clean.
# owner
integrations team quarterly
Renovate review, provider contract test, security alert route, remove after native SDK migration.

Resource path

The practical follow-up I would build is a dependency receipt with source, requested capability, selected package, version policy, transitive scope, license, maintainer health, security checks, alternatives, owner, update path, and removal trigger. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• What capability is missing?
• Does the package exist?
• How many transitives arrive?
• Does installation run code?
• Which license applies?
• Who maintains the project?
• Is the lockfile committed?
• What if it throws?
• Who receives alerts?
• What alternative was rejected?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For AI-aware software supply chain review, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• a more durable adoption decision
• reviewed components that remain the ones deployed
• product behavior that survives third-party failure
• a supply chain with visible stewardship
• credible evidence of secure engineering judgment

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• A dependency receipt turns generated convenience into an explicit trust decision.
• Dependency cost continues after the merge.
• Review depth should follow what the dependency can do.
• A useful dependency receipt stays short enough for the pull request.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to AI-assisted code changes where a generated import, package, action, container, model, or copied snippet can silently expand the software supply chain and its security, licensing, maintenance, and operational obligations: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through a dependency receipt as the review artifact that explains why new third-party code entered the system. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

A dependency receipt is a hiring signal because it shows I treat AI-generated package choices as architecture and supply-chain decisions, not harmless autocomplete.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.