A matching checksum supports a file-integrity check; it does not approve the survey inside the file. For a UVH1 project discussion, separate successful transfer from technical acceptance, and attach both decisions to the same delivery revision. The buyer needs to know which bytes arrived and which deliverable a qualified reviewer actually accepted.

Consider a hypothetical survey handover. The supplier sends a revised surface, but the acceptance email still names the earlier package. The download completes, the recipient calculates a matching digest, and the project dashboard turns green. Nothing in that sequence establishes that the revised surface passed the agreed quality review. The transfer can be correct while the approval record is wrong.

Give transfer and quality separate questions

The transfer question is whether the received file matches the file represented by the supplier's trusted digest record. The quality question is whether the delivered information meets the contracted purpose and acceptance criteria. Keep separate fields for these outcomes. Combining them into one checkbox makes it difficult to explain a later dispute, especially when different people perform the download and the technical review.

The NIST Secure Hash Standard describes message digests used to detect whether messages have changed since the digests were generated. That is a useful foundation for integrity checking, not a statement about survey accuracy, completeness or fitness for use. This source was reviewed on October 18, 2026. Selecting an appropriate algorithm and securing the digest exchange remain matters for the project's technical and security owners.

Our buyer-side recommendation is to name each acceptance boundary before delivery. A transfer coordinator may confirm receipt and integrity. A survey reviewer may assess the agreed technical evidence. A project manager may authorize use after those records are linked. These are proposed responsibilities, not a claim that every project uses the same organization or requires the same review structure.

Build a manifest that identifies the release

A useful handover manifest identifies the package revision, intended recipient, file inventory, digest algorithm, digest values and the person or process that issued the record. It should also identify the scope of each digest. A digest for an archive is not automatically a separately documented digest for every extracted file. Ask the supplier to make that distinction explicit so the recipient compares like with like.

Use the actual delivered filenames, but do not make filenames the only identity. A name such as final_surface can survive several replacements. A revision reference and a digest record make the intended delivery clearer. Keep the technical approval reference beside that identity. Where a package contains multiple outputs, indicate whether approval applies to all outputs or only a named subset.

Agree how the recipient obtains a trustworthy manifest. A file and its digest arriving through the same compromised route do not, by themselves, establish who supplied them. Integrity checking should not be sold as a replacement for the organization's authentication and access controls. The appropriate exchange channel is a project decision, and this article does not prescribe a security architecture.

Choose what the recipient will actually compare

Before the main delivery, run a small handover rehearsal using non-sensitive sample data. The supplier issues a manifest, the recipient downloads the package, and the recipient records the comparison result using the agreed tool. Capture the tool identity and the input path sufficiently clearly that another reviewer can understand what was checked. Avoid a screenshot that shows a green indicator but not the file concerned.

If the recipient extracts an archive, edits a metadata file or converts a dataset before calculating a digest, the comparison may no longer concern the original delivered bytes. Preserve the received package and distinguish later working copies. This is not an instruction to avoid legitimate processing. It is a reason to record which stage of the workflow each check represents.

The rehearsal should include a deliberately changed, disposable sample. Confirm that the receiving process reports the mismatch and directs the user to an agreed resolution path. Do not run destructive tests on the production deliverable. The purpose is to test the handover procedure, not to demonstrate the aircraft or validate the accuracy of the survey.

Handle a mismatch without rewriting the evidence

When a comparison fails, retain the received file, expected digest record and observed result under the project's access and retention policy. Ask whether the parties compared the same revision and the same packaging level before assuming corruption. A renamed archive, a rebuilt export and a genuinely interrupted transfer can lead to different investigations, even though the recipient initially sees the same failed comparison.

Do not fix the report by copying the recipient's digest into the supplier's manifest. That would remove the disagreement without explaining it. The supplier should identify the intended release and issue a replacement or clarification through the agreed process. The recipient then performs a new check and records how the earlier attempt was resolved.

Define who can release the data for use while a disagreement remains open. A buyer may decide that unresolved integrity prevents downstream processing; a technical reviewer may separately identify a quality issue in a package that transferred correctly. The contract should state the applicable decision rule. Neither outcome should be hidden inside an informal message saying that the files look fine.

Bind approval to revised deliveries

Suppose, in another hypothetical example, a contractor corrects an attribute table after a review. The corrected package needs a new delivery identity and a clear statement of what changed. The previous approval should not silently migrate to the new files. Ask the reviewer which checks must be repeated and record the answer against the replacement revision.

A concise revision table can show the superseded package, replacement package, reason for change, affected outputs and current approval state. Keep superseded files distinguishable from current working data without implying that deleting them is always appropriate. Retention, confidentiality and contractual obligations should govern that choice. The immediate aim is to prevent a colleague from selecting an obsolete file because it has a familiar name.

Package identity also matters when accepting derived outputs. A simplified viewing layer may have different permitted uses from its source geometry. The discussion of simplification tolerance and retained GIS detail explains why a derivative needs its own purpose and review. Similarly, horizontal and vertical units in slope processing concern technical interpretation, not whether a transfer completed unchanged.

Ask for evidence that survives staff handover

Consider a recipient who receives an archive and an additional loose report through separate messages. The transfer record should make clear whether they belong to one release or whether the report supersedes an item inside the archive. Otherwise, a reviewer can approve a combination that the supplier never intended to issue. Ask the delivery coordinator to reconcile that ambiguity before technical sign-off.

For a multi-party project, identify the authoritative delivery location and the person who may issue a replacement manifest. Copies forwarded by a colleague can still be useful, but they should retain the release identity and not acquire a new approval state merely through forwarding. This is an administrative control proposed for clarity; the parties should adapt it to their own document system and contractual responsibilities.

The editorial lesson is practical: put the accepted revision beside the digest, not just the filename. A colleague joining the project should be able to identify the received release, the integrity result, the technical reviewer and the authorized use without reconstructing a conversation. This is a proposed control based on the distinction above, not a report of a customer incident or personal field experience.

Make the evidence proportionate. A straightforward delivery may need a short manifest and a linked review record, while a changing multi-output project may need a more detailed register. More paperwork is not the goal. Clear ownership and an unambiguous connection between the evidence and the deliverable are more useful than a large collection of disconnected screenshots.

For procurement, ask the supplier to demonstrate the record using a representative package. Does it distinguish receipt from approval? Can it identify an output excluded from acceptance? Can it show which revision a later correction replaced? These questions expose gaps that a generic promise of secure file delivery may leave unanswered.

Place UVH1 in the correctly scoped inquiry

The UVH1 product listing provides the starting product identity for a configuration discussion. This article does not establish that a particular payload, processing service, survey accuracy or checksum utility is included. Confirm the aircraft configuration and every data-service responsibility separately. The VTOL and fixed-wing collection can support a broader product discussion without replacing that project-specific qualification.

Before requesting a quote, identify the intended survey deliverables, the people who will receive and review them, and the downstream decisions they support. Share the proposed package structure rather than confidential operational data. Ask which party creates the manifest, which party performs the receiving check, and how technical acceptance is bound to the same revision.

Use the project inquiry channel to request a revision-bound file manifest and a separate data-quality sign-off plan alongside the UVH1 configuration discussion. Ask for unresolved responsibilities to be listed, not assumed. A useful response will tell you what is being supplied, what evidence will accompany it and who decides that the delivered information is ready for its intended use.