A supplier can deliver a list of software packages without identifying the combination demonstrated at handover. For a UVH-PNP project with a separately commissioned ground-side application, distinguish declared dependencies, resolved versions and the wider execution environment. Request evidence of the demonstrated state and a named maintainer. A lockfile alone does not establish a supported aircraft integration, software security or operational approval.

The scope here is deliberately limited to an independent ground-side data tool, such as a separately specified report-organizing application. It is not flight-control firmware, an instruction to modify an aircraft or a claim that UVH-PNP uses a particular software stack. Confirm every proposed interface and responsibility with the relevant suppliers before treating any software work as part of a platform package.

Draw the boundary before asking for source files

Begin the procurement brief with what the custom application is supposed to do and what it must not do. Name its intended users, permitted inputs and expected outputs. Identify any connection to another service as a separate item requiring review. This makes it harder for a general phrase such as integration software to conceal very different responsibilities.

Our suggested boundary statement distinguishes the product purchase from the ground-software contract. It should identify the developer, the receiving organization and the person who accepts the software handover. Where an aircraft-related interface is proposed, ask for explicit supplier confirmation of the interface and its limits. Do not infer support from the availability of source code or the presence of a connector in an application.

A useful brief also names exclusions. It might exclude operation of the aircraft, changes to firmware and any unsupported interface. The exact exclusions depend on the project, but writing them down gives reviewers a shared starting point. This article proposes a procurement structure, not a technical integration design or authorization to execute untrusted software.

A declaration is different from a resolved record

For a bounded example, the npm CLI v11 documentation for package-lock.json describes a file that records the resolved dependency tree for subsequent installations. Its role differs from a high-level declaration of requested packages. This versioned documentation is used only to illustrate the distinction; it is not a recommendation of a runtime for UVH-PNP.

For a buyer, ask the developer to identify the dependency declaration, the resolved-version record used in the demonstration and the application revision to which they belong. Those items should be presented together. A detached file named lockfile, without a clear relationship to the delivered application, leaves an avoidable interpretation question.

The resolved record still does not describe every aspect of an execution environment. Our proposed handover checklist therefore also asks for the documented runtime, operating environment, configuration requirements and external-service assumptions. Have the developer explain what is necessary for the agreed demonstration and what remains outside the delivery.

Compare two fictional handover offers

Imagine a buyer commissioning a ground-side tool that organizes approved project reports. Offer A includes an application archive and a list of package names. Offer B identifies the application revision, its corresponding dependency records, the demonstrated environment and a receiving-team review session. The offers may have different prices because their scopes differ; the buyer should not treat the archives as equivalent simply because both contain source files.

This example is fictional and describes no UNITED UAV customer or included service. It illustrates a comparison question: which offer lets the receiving team identify what was actually demonstrated? A file count is not an adequate answer. Ask the developer to connect the delivered records to a specific, permitted sample task and the agreed application revision.

Neither offer should be described as secure or fit for aircraft-related use on that basis alone. Security review, interface support and application acceptance are separate matters. Keep them separate in the comparison table, and assign each to a responsible owner with an agreed evidence requirement.

Request a handover index with relationships

A practical index should explain how the delivered items relate, not merely list filenames. The following entries are our editorial proposal for a separately commissioned ground application.

• Application identity: the revision demonstrated and the location of its permitted delivery archive.
• Dependency declaration: the file or record describing the requested packages.
• Resolved dependency record: the corresponding record of versions used for the demonstrated state.
• Environment description: the runtime and operating assumptions the developer says the demonstration requires.
• Configuration inventory: the names and purposes of required settings, without exposing secret values.
• External services: the dependencies, access responsibilities and agreed limits outside the archive.
• Acceptance note: the sample task, observed result, unresolved issues and person approving receipt.

Ask the developer to flag any item that cannot be transferred or reproduced under the proposed contract. This may involve access rights, third-party arrangements or work outside the agreed scope. The buyer needs a clear limitation, not a promise inferred from a folder that happens to be present.

Define a receiving-team demonstration

Specify a modest sample task using permitted, non-sensitive input. Ask the developer to demonstrate the delivered application revision in the documented environment and show the expected output. The receiving team's role is to observe the agreed task, identify the records used and capture any exceptions. This article does not provide installation commands or advise running an unknown archive.

Agree in advance who authorizes execution and where any review may occur. Do not expose production credentials or aircraft systems merely to complete a handover checklist. A security or IT owner should determine the appropriate review arrangements for the organization's environment. The procurement file should record those responsibilities without containing the secrets themselves.

At the end of the demonstration, ask the receiving team to identify the accepted application state. Can they point to the revision and its dependency records? Can they name the maintainer and the unresolved limitations? These questions test the clarity of the handover, not whether every possible defect has been found.

Do not turn a lockfile into a security claim

A record of selected versions is not the same as a security assessment of those versions or of the application as a whole. Request a separately scoped security review where appropriate, with its own owner and limitations. Avoid a comparison-table shortcut that marks security complete simply because a resolved dependency record exists.

Likewise, a successful sample demonstration does not prove that an application is safe for every dataset or deployment context. The proposed acceptance should state what was examined and what was not. Where the buyer expects a broader assurance, ask for the additional scope and evidence explicitly rather than expanding the meaning of the original demonstration after the fact.

For any proposed aircraft-related connection, seek configuration-specific support evidence from the relevant parties. Ground-side source availability, dependency records and a functioning user interface do not provide airworthiness approval or permission to alter an operational system. The platform and software responsibilities must remain visible throughout the procurement process.

Maintenance starts with an owner

After handover, ask who is responsible for reviewing dependency changes and deciding when another demonstration is required. A project can have a clear initial record yet leave future changes unowned. Our recommendation is a written maintenance arrangement that identifies the decision maker, the scope of support and how a new accepted revision is documented.

Include the treatment of external services. If the application relies on something outside the delivered archive, ask who monitors its continued availability and who handles a change in access or behavior. Do not assume that purchasing the platform transfers responsibility for every service a separate developer chose to use.

Agree how the receiving team requests clarification. A named contact and a defined support scope are more useful than an informal expectation that the original developer will always be available. Record which activities are included and which need a new engagement. This is a commercial scoping recommendation, not a promise about any supplier's support terms.

Connect the software record to the data handover

If the ground-side tool manages imagery, the UG25 guide to preview and source deliverables offers a separate checklist for understanding what the data package contains. A software handover cannot correct an undefined data-delivery scope simply by making a preview easy to open.

If reports from the tool contain evaluation claims, use the UIV2200 discussion of repeatability and reproducibility to clarify what the supporting tests actually address. Software-state records and measurement evidence serve different purposes. Keep the links between them traceable without claiming that either automatically validates the other.

Make the UVH-PNP inquiry specific

The UVH-PNP product listing establishes the product reference for a platform discussion within the VTOL and fixed-wing drone category. Confirm the exact supplied configuration and any separately proposed integration work in writing. Nothing here asserts included application software, a supported runtime or a validated interface.

Our editorial integration lesson is to ask the receiving team to identify the demonstrated software state, not merely count files in a source archive. Send a separately scoped ground-software brief, its named maintainer and the unresolved responsibility questions to UNITED UAV when discussing UVH-PNP. Request explicit boundaries between the platform, the custom application and ongoing support before comparing the total proposal.