A mapping subcontract is not complete when it names an aircraft, a site, and a delivery date. It should define what files arrive, how they are organized, which coordinate-reference declaration accompanies them, how completeness is checked, what creates a rejection, and who signs the accepted package. Lock those terms before mobilization. Otherwise the buyer may receive a technically impressive folder that cannot be reconciled with the project grid, control record, segment list, or customer acceptance process.

The practical goal is a reproducible handoff. A reviewer who did not attend the field work should be able to identify the project, capture event, aircraft and payload configuration, source files, processing state, coordinate reference, quality record, open exceptions, and final authority. Aircraft specifications can frame procurement questions, but they cannot define mapping accuracy, control, processing, file formats, or acceptance tolerance for the contract.

Start With an Enumerated Deliverable Schedule

List each required deliverable as a separate line with a stable identifier. Use plain descriptions that distinguish source data, derived data, reports, logs, declarations, and supporting records. State the expected format, naming pattern, responsible producer, delivery channel, reviewer, and acceptance status. If an item is optional, label the condition that makes it required. If the buyer does not know which format is needed, keep that question open rather than allowing the subcontractor to choose silently.

The schedule should also identify exclusions. A promise to provide mapping data does not automatically include control establishment, coordinate transformation, surface modeling, orthomosaic production, classification, accuracy reporting, source imagery, flight logs, or long-term storage. Those are examples of questions, not assumptions about the UG21 or a supplier package. The signed scope should say what is included, what is not included, and what requires a change instruction.

Define the File Structure Before Capture

Choose a folder and filename structure that reflects the buyer's project identity. A practical hierarchy may separate administration, field records, source data, processing inputs, derived outputs, quality review, customer releases, and superseded material. Whatever structure is chosen, document it and provide an example before the first field day. Avoid personal desktop conventions or abbreviations that only one technician understands.

Require a manifest that lists each file, its role, its size or another integrity reference when appropriate, the creation or export time, the producing tool or process, and the related capture event. The manifest should show whether the file is authoritative, derived, superseded, or pending review. A folder count alone cannot reveal that a required log is missing or that two similarly named outputs came from different revisions.

Make the Coordinate Reference a Declaration

The coordinate-reference statement should be explicit, reviewable, and tied to the delivered data. It should identify the horizontal and vertical reference choices used by the qualified survey team, any relevant transformation or geoid references, units, epoch or date relevance when applicable, and the source of control. The precise technical content belongs to the project survey authority. The subcontract should require the declaration without pretending that the aircraft product page supplies it.

Do not accept a map looks right statement as coordinate evidence. A preview can align visually while the underlying reference, units, or elevation basis remains wrong. Conversely, a declared difference may be intentional and resolvable through the approved project workflow. The reviewer should compare the declaration with the contract and control record, then document the result rather than editing metadata until software displays the expected location.

Separate Capture, Processing, and Acceptance Roles

Name the field capture lead, data custodian, processing owner, coordinate-reference authority, quality reviewer, customer representative, and final acceptance signatory. One person may hold several roles, but the record should show which decision they made. This matters when a subcontractor can confirm that files were produced but cannot accept them on behalf of the buyer, or when a project manager can approve scope but is not the qualified authority for survey control.

Write the handoff sequence. The field team closes its data inventory, the custodian verifies transfer, the processing owner produces or receives the agreed outputs, the qualified reviewer checks the declared criteria, and the acceptance authority records the disposition. If a step is skipped, the package should remain in a visible intermediate state. Email delivery is not the same as verified transfer, and verified transfer is not the same as technical acceptance.

Build Completeness Checks That Can Be Repeated

Turn the deliverable schedule into a review checklist. Verify the package identifier, manifest, expected folders, expected file types, readable files, consistent naming, declared coordinate reference, capture-event links, processing notes, quality record, exception list, and sign-off fields. Record the reviewer and time. If an automated check is used, preserve its configuration or version so another person can understand what passed.

Completeness is not quality. A package can contain every listed file and still fail a contractual test; it can also contain a quality result that cannot be traced to the source data. Keep inventory checks, technical validation, customer acceptance, and commercial approval separate. That separation prevents a green folder checklist from being used as proof for a claim it never examined.

Define Rejection and Correction Handling

Write the rejection categories and response path before the deadline. A defect may involve missing material, unreadable material, wrong identity, inconsistent naming, undeclared reference information, failed agreed validation, or an unresolved exception. State what evidence supports the rejection, who receives it, how the subcontractor acknowledges it, and whether the correction is a new version or a replacement of the same delivery.

Never overwrite the rejected package. Preserve the received version, review record, notification, response, corrected package, and final decision. The revision relationship should be visible. If a correction changes processing assumptions, coordinate handling, or source selection, the buyer should know which earlier checks must be repeated. A clean revision history protects both parties from arguments built on different copies.

Use UG21 Product Facts as Procurement Context

The current UG21 product page describes a VTOL fixed-wing platform for mapping, inspection, and surveillance. The approved product record lists a 2.5 kg maximum payload, up to 240 minutes of no-load flight time, a 20 m/s cruise speed, and a 4800 m maximum service ceiling. Preserve maximum, up-to, and no-load qualifiers whenever those values appear.

These facts do not prove mapping accuracy, sensor compatibility, coordinate systems, deliverable formats, loaded endurance, route coverage, project permission, or customer acceptance. A buyer should ask for configuration-specific documentation and test evidence. The subcontract should refer to the proposed aircraft and payload configuration but keep the product record separate from the deliverable specification.

Run a Handoff Rehearsal

• Provide a sample project and segment identity.
• Ask the subcontractor to build the proposed folder structure.
• Include a sample manifest and declaration.
• Introduce one missing file and one revision.
• Have the buyer record a rejection.
• Have the supplier return a corrected package.
• Confirm who may sign each acceptance state.
• Archive the rehearsal outcome with open questions.

The rehearsal is not evidence that future work will pass. It tests whether the handoff language is understandable and whether both sides can use the same identifiers. Record any terms that caused confusion and revise the schedule before mobilization. A short dry run can expose more contract risk than another page of generic quality language.

Connect Deliverables to the Wider Operating Picture

Use the same-day corridor exception register to manage defects that need recapture or escalation, and use the same-day procurement quote review to keep delivery scope, support, and unknown commercial terms from being merged into the aircraft price. Each record should link to the same project and configuration identity without duplicating authority.

Close the subcontract deliverable only when the manifest, coordinate-reference declaration, completeness review, technical review, exceptions, revision history, and named sign-off can be traced. Reopen it when scope, control, processing method, aircraft or payload configuration, customer criteria, or file structure changes. Browse the VTOL and fixed-wing drone collection only when a documented requirement justifies comparing platforms. Use the UNITED UAV contact page for configuration questions, and ask responses to distinguish published product facts, proposed configurations, required tests, and unresolved items.

Create an Acceptance Certificate That States Its Limit

The final certificate should identify the project, delivery revision, manifest, coordinate-reference declaration, review method, exceptions, accepted purpose, signatory, and date. It should also say what the sign-off does not cover. File completeness, technical validation, customer release, invoice approval, and permission for future reuse may be separate decisions. A precise certificate protects both the buyer and subcontractor from later claims that were never reviewed.

Archive the accepted package as read-only or otherwise protected according to the buyer's information policy. Preserve the rejected and superseded revisions with clear status labels. Record retention, access, confidentiality, and transfer obligations in the subcontract rather than assuming the delivery platform will remain available. Test restoration of a sample package so the archive is more than a folder that nobody has tried to reopen.

Review the Contract Language After the Rehearsal

Convert every rehearsal finding into a defined term, deliverable row, responsibility, or review step. Remove duplicate labels and clarify which document controls when the schedule, technical specification, and commercial order differ. Confirm that the field team, data team, procurement lead, and acceptance authority can all find the current version. A contract is operationally useful only when the people performing the handoff can follow it without inventing missing rules.