A GIS layer can contain every expected feature while its inspection photographs are missing, inaccessible or linked to the wrong records. For a UG32 inspection inquiry, accept the handover only against an agreed test of records, media and their relationships in the receiving environment. A feature count alone cannot establish that the supporting evidence survived export.

The layer opens, but the evidence does not

Consider a fictional handover in which an asset manager opens a delivered layer and sees all the expected locations. The attribute table looks complete. Clicking the photograph link, however, opens nothing on the receiving computer. The supplier can still demonstrate the images on its own workstation. The disagreement is not necessarily about whether photographs were captured; it is about what was actually delivered and whether the recipient can use it.

This example is original procurement analysis, not a reported UG32 customer experience. It illustrates why inspection scope should identify the supporting media separately from the spatial layer. A buyer paying for reviewable evidence needs more than a map that looks populated. The handover should make it possible to move from a particular feature to the appropriate supporting material without relying on undocumented access to the supplier's working environment.

Attachments are a relationship, not just another column

Esri's ArcGIS Pro attachment documentation describes a separate attachment table connected to parent records through a one-to-many relationship. A unique identifier provides the connection. This explains one implementation, not every GIS storage format. It also does not promise that an arbitrary export command will preserve all attachments. Confirm the behavior of the actual export route being proposed.

For acceptance, turn that technical distinction into three questions: are the parent records present, are the media present, and does each relationship still lead to the intended material? An affirmative answer to one question should not be used as the answer to the others. Ask for evidence that a recipient can inspect, rather than an assurance that the exporter ran without displaying an error.

Agree what belongs to each record

Not every feature necessarily needs the same number of photographs. Some assets may have several views, while others may legitimately have no media under the agreed scope. The buyer should therefore define expected relationships rather than impose an unexplained universal attachment count. Record why a feature is exempt and how an unavailable view will be identified. Otherwise, a deliberate omission and an accidental loss look the same.

Specify whether captions, observation dates, reviewer notes or file descriptions belong in the delivery. These may be important to the customer even when they are not embedded in the photograph itself. Do not assume that a file's name explains its purpose. A photograph linked correctly but stripped of the context needed for interpretation may still leave the asset manager unable to make the intended decision.

Build a small receiving-system trial

Our editorial recommendation is to test a small package before agreeing the full handover method. Include a record with multiple attachments, a record with an approved absence and a record whose name resembles another asset. These are deliberately chosen acceptance cases, not claims about failure rates. They help the parties expose assumptions about identity, absence and navigation while changes are still inexpensive to discuss.

Run the trial through the same export and delivery route intended for production. Testing a native project on the supplier's workstation does not test the recipient's package. Ask the receiver to start from the delivered files and documented access instructions. Where remote hosting is part of the offer, name the service owner, access conditions and retention period rather than treating a working link today as a perpetual delivery.

Record the observed outcome for each case. A screenshot can support the record, but it should identify which delivered artifact and asset were tested. Avoid collecting a large gallery of screenshots with no connection to the acceptance list. The goal is a repeatable demonstration of the handover relationship, not visual proof that someone once opened a photograph somewhere.

Look for wrong links as well as broken links

A missing attachment is easy to notice once someone tries to open it. A photograph that opens successfully but belongs to a different asset can be harder to catch. Include a few cases with recognizable distinctions in the trial and ask the supplier how the relationship was established. An attachment count can remain unchanged even when the relationship is incorrect.

Do not make the aircraft model the explanation for a database relationship. The capture configuration, file handling, processing workflow and export method all need their own scope. A buyer should ask who is accountable for preserving the link through those stages. The answer may involve several organizations; responsibility should still be clear enough that a failed acceptance case has an owner and a proposed remedy.

Make exception handling visible

Classify exceptions in ordinary language: expected media not delivered, file delivered but unreadable, association uncertain, or media deliberately excluded from scope. Avoid one generic missing flag if different actions are required. An inaccessible hosted file may need an access correction, while an uncertain association needs evidence review. A filename change alone may not resolve either problem.

Keep the exception list with the package revision it describes. When the supplier sends a correction, identify which records and files changed and rerun the affected acceptance cases. Preserve the original delivery for comparison. This is a practical way to avoid a situation in which both sides discuss different versions while using the same folder name and the same statement that the issue was fixed.

Define portability without promising universality

Portable should mean usable in a named receiving workflow, not compatible with every tool. A procurement request can specify the required software context, the permitted dependencies and whether the receiver needs an offline package. The supplier can then propose a delivery method and demonstrate it. Where an export loses a capability, disclose the limitation rather than assuming the recipient will discover it during an urgent review.

Numerical fields may need a separate import agreement even after attachments work. The UG35 guide to decimal and grouping separators examines how a value can be interpreted differently across receiving applications. Similarly, a package's spatial boundary needs a distinct check; see the UVH1 polygon-versus-bounding-box discussion. Passing one handover test does not automatically pass the others.

UG32 is the product inquiry, not the software guarantee

Use the UG32 product listing as the starting point for aircraft configuration questions. The approved product identity does not establish that a particular inspection camera, GIS platform, attachment exporter or hosted evidence service is included. Request explicit confirmation of the proposed payload and scope of supply. For unknown integration requirements or specifications, contact us for configuration details.

For a US or Irish inspection program, explain the receiving organization's evidence workflow without assuming that the same contract, access arrangements or operating permissions apply in both places. This guide does not provide a jurisdictional approval or a flight procedure. Its narrower purpose is to help a buyer distinguish a deliverable that opens from a deliverable that supports the intended review.

Short answers for the handover meeting

Is a matching feature count sufficient?

No. It addresses only one part of the package. Ask for the agreed media inventory and relationship checks as well. The count may be a useful first check, but it cannot replace opening and identifying the supporting material.

Must every attachment be embedded?

Not necessarily. An agreed external delivery method may be appropriate. State how the receiver obtains the files, what dependencies remain and who maintains access. The important point is that the delivery promise is explicit and tested, rather than implied by the word attachment.

Can the supplier demonstrate only a live project?

A live demonstration can explain the workflow, but the acceptance sample should exercise the proposed recipient delivery. Ask for a small package that the receiver can inspect independently. Record any supplier service that remains necessary to make it usable.

Request a testable evidence package

When browsing the VTOL and fixed-wing drone collection, keep the aircraft shortlist separate from the evidence handover decision. Prepare a small list of asset records, expected media relationships and the receiving software environment. Include one approved absence and one multiple-attachment case. That brief gives the supplier something concrete to demonstrate instead of a general request for a complete inspection solution.

Send those examples through the UNITED UAV contact form with your UG32 configuration inquiry. Ask which organization supplies each part of the capture, processing and export workflow, and request an attachment-preservation trial before full delivery. The useful outcome is a package the intended receiver can inspect, with exceptions named and responsibilities assigned, rather than a feature layer that merely contains the expected number of rows.