A Cloud Optimized GeoTIFF should be accepted through the delivery path the buyer will actually use, not only by opening a downloaded copy. For a UG73 mapping proposal, distinguish the raster file, its hosting arrangement and the receiving software. Ask for evidence that the agreed file organization and authorized HTTP access work together. Keep transfer speed, availability and support commitments explicit; the COG label alone does not settle them.

A supplier can show a raster opening on a laptop while the customer's remote workflow remains untested. That demonstration answers a useful but limited question. It does not establish that the proposed endpoint, permissions and client configuration will support the way the recipient intends to work. The gap belongs in the delivery specification before the project reaches its final acceptance meeting.

Separate the file from the service around it

Start by naming what is being purchased. Is the supplier delivering a file for the buyer to host, providing a temporary download, or operating an ongoing hosted service? Each arrangement assigns responsibility differently. A quotation that says cloud delivery without explaining the arrangement leaves the buyer unable to evaluate retention, access and future maintenance.

Then name the intended receiving environment. A desktop GIS client, an internal web application and a public map are different acceptance contexts. You do not need to expose sensitive configuration details during early procurement, but the supplier needs a sufficiently clear description to say whether the proposed delivery has been considered for that use.

The questions in this article concern data handover. They do not establish that UG73 includes a particular mapping payload, raster processor, hosting subscription or software integration. Those elements must be confirmed separately. A product inquiry can connect the parties, but an aircraft listing is not a service-level agreement for a geospatial endpoint.

What the OGC standard contributes

The OGC Cloud Optimized GeoTIFF Standard, version 1.0, addresses tiled TIFF organization, reduced-resolution imagery, georeferencing and HTTP range delivery. Its design supports accessing relevant portions of a raster rather than treating every interaction as a full-file transfer. The standard separates requirements into conformance classes, so a conformance claim should identify its scope.

That is the technical reference for the distinction here. It does not guarantee a particular download time, a customer's network performance, an application's behavior or an aircraft's output quality. The acceptance exercise and commercial questions below are editorial recommendations. They should be adapted by the people responsible for the actual hosting and GIS environment.

Write a delivery record with named owners

Ask the proposer to describe the whole route from accepted raster to recipient. This does not require a complex architecture diagram for a simple delivery. A short record can identify the file revision, storage owner, endpoint owner, approved users, receiving application and support contact. It should also say where the authoritative copy will be kept.

For a file-only purchase, make that limit explicit. The buyer may own hosting and client validation, while the supplier owns the file and its agreed validation evidence. For a hosted purchase, identify whether the supplier is responsible for the endpoint itself or is merely placing a file into a third-party service selected by the buyer.

• Which exact raster revision is the acceptance exercise using?
• Who controls the storage account and the recipient-facing endpoint?
• Which users or roles are authorized to access the delivered data?
• Which client and version represent the intended recipient?
• What evidence will show the file and delivery-path checks?
• Who investigates a failure after the initial handover?

These answers prevent one supplier's completed task from being confused with the customer's completed workflow. They also help separate a technical defect from a missing commercial service. If ongoing hosting was never purchased, an expired temporary delivery link may be a scope issue rather than a failure to produce the raster.

Run a small, authorized acceptance exercise

Choose non-sensitive data or an approved project subset and agree who may access it. Avoid testing against unrelated infrastructure or distributing live credentials in the acceptance notes. The intended exercise is a controlled check of your own delivery arrangement, performed by the authorized technical team. It is not a security assessment of someone else's systems.

Ask the team to record the file identity and the endpoint used, then open the raster through the intended client. They should retain enough evidence to explain whether the agreed checks passed. Where the specification includes range-request behavior, the responsible engineer should verify that behavior rather than inferring it from a quick visual display.

Next, repeat the relevant check using the recipient's approved access rather than only the supplier's account. This catches a basic responsibility gap: a supplier demonstration can succeed without proving that the customer has the access arrangement promised in the quote. Do not solve that gap by placing a shared password in the project report.

Keep performance expectations separate. If the project needs a specific response under a defined workload, describe that requirement and its test conditions. Do not invent a universal speed threshold for every COG file or assume that one successful connection proves continuing availability. A technical acceptance note should report what was tested and what was outside the exercise.

Finally, agree the result categories. Passed, failed and not tested should remain distinct. A screenshot of the right area might support a visual check while leaving other checks unresolved. The buyer can accept a limited scope when that is the agreed purchase, but should not rename an incomplete exercise as comprehensive validation.

A hypothetical handover disagreement

Consider a GIS team that receives a valid-looking file and a link labeled for remote use. The file opens after a complete download, but the proposed client workflow does not behave as the team expected. The supplier points to the successful local opening. The buyer points to the promised remote use. Both parties may be discussing different acceptance questions.

A useful review preserves the original delivery and compares the contract with the evidence. Was hosting included? Which client was agreed? Who was responsible for access configuration? Which checks were performed on the file, and which on the endpoint? Answering those questions is more constructive than asking the operator to regenerate the raster before the cause is understood.

This is an original editorial scenario, not a reported incident involving UG73 or a named provider. The lesson is to test the contracted path rather than a convenient substitute. It also avoids unnecessary rework: the file, endpoint, permissions and client should be considered as separate investigation areas, with the responsible people deciding what evidence is needed.

Plan for retention and changed versions

Decide how long the delivered endpoint should remain usable and what happens at the end of that period. A buyer may need an archive copy even when the main workflow is hosted. Name who retrieves that copy, where it is retained and which files constitute the final accepted package. Do not leave archive ownership to whichever employee remembers to download something.

Ask how corrections will be communicated. A replacement raster should have an identifiable revision and a record of the reason for change. If the endpoint stays the same, the recipient still needs a way to know that the content has changed. If the address changes, identify which downstream users or systems require notification.

Access ownership also deserves a separate handover discussion. The UVH-PNP guide to software secret provisioning offers questions about account and credential responsibilities in ground-side integration. Its relevance here is organizational, not a claim that a particular airframe includes the hosting software under discussion.

Likewise, a working endpoint does not resolve the reference basis of the raster. The UG21 guide to coordinate epoch and acquisition date separates those records. Treat delivery access and coordinate documentation as complementary checks instead of allowing one successful demonstration to stand in for both.

Make the UG73 inquiry specific

Before closing the project, ask a person who did not prepare the delivery to follow the handover record. They should be able to locate the accepted revision, identify the support owner and understand the retention arrangement. Record unanswered questions as handover exceptions instead of relying on informal knowledge that may disappear when staff change.

Use the UG73 product page to begin a platform discussion, then identify the separately required data workflow. Describe the intended recipient, file format, hosting arrangement and acceptance owner. Ask which parts the proposed supplier can quote directly and which require another provider or an integration review.

Request separate lines for aircraft configuration, raster processing, hosting and acceptance support where those responsibilities differ. This makes comparison more useful than a single bundled total with unclear exclusions. It also gives the receiving GIS team an opportunity to identify a missing service before the commercial decision is made.

Browse the VTOL and fixed-wing drone collection and contact UNITED UAV with your UG73 delivery requirements. A focused inquiry should ask for a file-and-endpoint evidence plan, not a blanket promise of fast cloud access. The objective is a delivery the intended recipient can verify, maintain and archive within a clearly agreed scope.