The software delivery package procurement should ask for

Automotive procurement can negotiate a clear milestone for executable software while leaving its maintenance evidence ambiguous. The component may pass a demonstration, but later teams cannot reproduce its build, identify dependencies or understand a field fault. Those gaps turn support into a negotiation conducted after the organisation has become dependent on the delivery.

Define a software delivery package around the decisions the manufacturer must make. The objective is to acquire enough evidence and access to integrate, operate and maintain the component responsibly. It is not to demand every internal supplier document regardless of relevance.

Translate support questions into deliverables

Ask engineering and service teams what they would need to investigate a fault in a delivered version. Their answers may include supported configuration information, interface definitions, diagnostic descriptions, release notes and dependency records. Assign each item an expected format and an acceptance owner.

NIST's Secure Software Development Framework offers a common vocabulary for discussing development practices with suppliers. It can structure conversations about evidence and responsibility. It should not be presented as a certificate that proves a component's behaviour in a particular vehicle.

Separate ownership from access

Source ownership, access to source and access to maintenance support are different commercial questions. Decide which arrangement is appropriate for the component and its role. A manufacturer may reasonably use proprietary software, but it still needs a dependable route for investigating defects and obtaining fixes.

Define what happens if the supplier changes its tools, discontinues a component or transfers support responsibility. Consider the evidence that must remain usable and the assistance needed for migration. An escrow or exit provision requires practical detail about the material and rights involved; a reassuring clause alone does not demonstrate recoverability.

Test the evidence, not its presence

An acceptance checklist should include a representative maintenance exercise. Attempt to identify the delivery's configuration, follow a diagnostic path and connect a reported defect to the relevant artefact. This reveals whether the information is understandable outside the team that created it.

Check consistency across documents. Release notes, interface descriptions and dependency inventories may each look complete while describing different builds. Require an unambiguous identifier tying the package together. Record discrepancies before acceptance so they do not become inherited assumptions in the next vehicle programme.

Carry acceptance into the support period

A later software update should refresh the relevant delivery evidence. Define which changes trigger renewed review, including interface changes, new dependencies and altered diagnostic behaviour. Otherwise the original documentation becomes increasingly detached from vehicles in use.

Give procurement a role in preserving the agreed support relationship, while keeping technical acceptance with qualified teams. Commercial milestones should not force technical ambiguity to be labelled complete. A well-defined software delivery package makes responsibilities visible before leverage shifts. It also gives both parties a clear way to show that they have delivered a component the customer can continue to support.