Correcting a coordinate-system label and transforming stored geometry are different jobs. Before asking a supplier to fix a spatial file for a proposed UG25 survey project, establish what its existing coordinates mean and what the receiving team needs. A map that appears misplaced is not enough evidence to choose the correction. Preserve the received original, document the source reference and require an explanation of whether the proposed operation changes the numbers or only their declared meaning.

Two requests can sound identical and mean different work

A project manager might ask a subcontractor to put a file into the right coordinate system. One subcontractor understands that as repairing missing metadata. Another understands it as producing transformed geometry in a specified output system. Both can respond confidently while proposing different work. The purchasing problem is the ambiguous request, not necessarily the competence of either supplier.

For US and UK mapping teams exchanging survey outputs, this ambiguity can spread across several handovers. The person receiving a file may not be the person who captured or processed it. An explanatory email can become detached from its attachment. The acceptance brief should therefore ask for the coordinate definition and transformation record as part of the deliverable, not as knowledge retained by one operator.

The narrow distinction supported by the tool documentation

Esri's Define Projection documentation, accessed October 1, 2026, distinguishes changing coordinate-system information from changing geometry. Define Projection updates metadata; Project is used to transform geometry. The documentation does not tell a buyer which reference system an unidentified file actually uses. That source evidence must come from the file's provenance and competent technical review.

The following procurement framework is United UAV analysis, not a software procedure or a survey certification. It deliberately avoids selecting a reference system, datum transformation or numerical tolerance for an unknown project. Those choices require the actual input, output requirements and a qualified owner. The useful commercial question is whether the proposed work is supported by evidence and described precisely enough to review.

Begin with a receipt record

Keep the supplied original in a read-only location and record who supplied it, when it was received and what files belong together. Include accompanying notes and reference information. Ask the technical reviewer to identify the file they inspected, not merely a similarly named copy in a working folder. A later correction should be traceable to this received set.

Separate what is known from what is assumed. The file may declare a system, the supplier may describe a different one, or the declaration may be absent. Record those conditions without silently choosing whichever makes the preview look convenient. Where evidence conflicts, ask the originating supplier for clarification. A temporary visual alignment should not be used as a substitute for identifying the source reference.

State the intended receiving workflow as well. The required output may be a coordinate file, an analysis layer, a drawing reference or a presentation map. Ask the recipient to specify the needed reference information rather than letting a generic request for compatibility drive the transformation. This reduces the chance of commissioning work that technically completes but does not satisfy the next handover.

Use an evidence-led triage conversation

• If the geometry is understood and only its declared reference information is wrong or absent, ask the reviewer to explain the evidence for a metadata correction.
• If the source reference is established and the recipient needs a different output reference, ask for a documented transformation proposal.
• If the source reference is uncertain, keep the item unresolved and request provenance evidence before authorizing either operation.
• If several files disagree, review their identities and histories separately rather than assuming one correction fits the entire folder.

This is a decision structure for the contract owner, not a substitute for technical judgment. It prevents the word fix from concealing uncertainty. A supplier should be able to describe why a proposed operation is appropriate, which input it applies to and what its expected output represents. The buyer should be able to see where an assumption remains unverified.

Ask what will change and what will remain unchanged

For each proposed correction, request a plain-language change statement. Does it alter the stored geometry, the declaration attached to it, or both as part of a documented workflow? Which file is the new deliverable? Which earlier review results still apply? The statement should refer to the actual files, not only to a software menu name.

Also ask what will not be established by the work. A coordinate-reference correction is not automatically evidence of capture accuracy, completeness or suitability for every downstream calculation. The supplier should identify the scope of its validation and any decisions left to the receiving specialist. This keeps a narrowly successful processing task from acquiring broader claims as the deliverable moves through a project.

Make the comparison reviewable

Request an input-and-output record that a second authorized reviewer can understand. It should identify the accepted source, proposed output, responsible person and method record. Agree which project-specific checks the competent reviewer will use and how exceptions will be reported. Do not choose a universal tolerance simply to make the acceptance sheet look complete.

A visual overlay can be useful in the discussion, but ask what it is being compared against and what conclusion the reviewer is drawing. An image shown at one scale should not stand alone as proof that all relevant reference questions are resolved. The acceptance note should name the evidence that supports the decision and preserve unresolved limitations rather than letting them disappear beneath a green status label.

Where the output will feed another analysis, include that analyst in the handover. The person commissioning the file may not know every assumption of the receiving workflow. Asking for those requirements before delivery is usually more concrete than promising general interoperability. The contract can then distinguish an accepted file format from an accepted reference definition and an accepted analytical use.

A field lesson: ask whether the numbers moved

During the review meeting, ask the supplier to explain whether the proposed correction changes the coordinate numbers or only their declared meaning. Then ask why that is the right operation for this input. This editorial habit gives a non-specialist project manager a clear way to surface ambiguity without pretending to perform the technical review. An unclear answer is a reason to request clarification, not a reason to guess.

Keep the explanation with the corrected file. If a later recipient cannot tell what happened, the correction history has not been handed over effectively. A brief record naming the original, corrected output and decision owner can be more useful than a long software export log with no explanation of purpose. Retain both where the contract calls for technical reproducibility and accessible review.

Connect coordinate decisions to the rest of the package

The consequences do not stop at a map preview. A terrain derivative may need its own interpretation rules once the reference question is settled. The companion aspect-map acceptance guide explains why flat, missing and north-facing categories need separate treatment. That is a different review from deciding what coordinates mean; completing one does not complete the other.

The corrected project records also need to remain recoverable after handover. The second-workstation project restore review provides a way to define a bounded recovery exercise for offline records. A perfectly documented correction is of limited practical use if the agreed files and their explanation cannot be recovered by the next authorized team.

Keep the UG25 purchase scope explicit

Use the approved UG25 listing to begin a configuration discussion. Nothing in this coordinate-handoff framework establishes an included sensor, processing license, transformation service or survey qualification. Ask which responsibilities sit with the aircraft supplier, integrator, processing contractor and receiving survey professional. Obtain configuration details directly where the approved information does not answer a necessary question.

The VTOL and fixed-wing collection can support a broader hardware comparison, but hardware selection should not be treated as a remedy for undocumented reference information. Keep aircraft requirements and data-delivery requirements connected through the project brief while retaining separate evidence for each. This makes a quote easier to compare without allowing an attractive model specification to answer the wrong question.

Send an answerable handoff brief

Consider a proposed handover containing a declared reference system that conflicts with the supplier's notes. The acceptance action should be to resolve that conflict and identify the evidence, not to select the declaration that produces the most attractive overlay. Ask who can answer for the original processing and what record will confirm the correction. If that evidence cannot be recovered, the buyer should receive an explicit limitation and a proposed next step rather than a silently relabeled file.

Prepare a short request naming the incoming data, known source reference, intended recipient and required output. State any conflicting declarations rather than hiding them. Ask for the proposed operation, its evidence, the responsible reviewer and the acceptance record that will accompany the result. Specify that the received original must remain identifiable throughout the work.

Use the United UAV inquiry page to discuss the proposed UG25 configuration and the boundaries of any associated delivery scope. The desired outcome is not a generic assurance that the map will line up. It is a documented decision about metadata correction or geometry transformation, with unresolved provenance questions addressed before the output becomes an accepted project input.