A headline accuracy percentage does not explain the review workload created by an inspection classifier. For a UIV2200 project that may use a separately supplied offline analytics service, ask what counts as a positive finding, how reference labels are agreed and what precision and recall count. Keep the analytics evidence separate from the aircraft configuration. Nothing here establishes included AI software, observed UIV2200 classification performance or permission to automate a safety-critical decision.

Which items will people actually review?

An analytics proposal may promise to identify records that deserve attention. The buyer's practical question is what happens next: who receives the proposed findings, what they inspect and how missed items are handled. Begin with that workflow rather than a percentage. A classification result is useful to procurement only when the supplier can explain its relationship to the buyer's actual review task.

Imagine a hypothetical civilian asset-documentation team considering an offline service that sorts already collected images into a human review queue. The service is not controlling an aircraft or making final engineering decisions. The team wants to understand the cost of unnecessary reviews and the consequence of overlooking a relevant record. This is an editorial purchasing example, not an account of a deployed system or a claim that UIV2200 includes such a service.

Three metrics answer different questions

Google's classification metrics lesson distinguishes precision, recall and accuracy. Precision concerns correct positive predictions among predicted positives; recall concerns detected positives among actual positives. Accuracy considers correct classifications overall. The lesson cautions that accuracy alone can mislead when the classes are imbalanced. These definitions help a buyer ask what a reported score means; they do not establish the performance of any particular inspection model.

United UAV's recommendation is to ask for the underlying counts and their definitions alongside the chosen metrics. A percentage without a clearly defined set of examples leaves the buyer with little to review. The analytics provider should explain its evaluation, while the project owner should explain which errors matter in the proposed workflow. Those are related responsibilities, but they are not the same responsibility.

Google lists January 12, 2026 as the lesson's update date; it was consulted on September 27, 2026. This guide addresses global-English buying discussions, including United States and Singapore teams, without asserting local demand or a jurisdiction-specific approval standard.

Define a positive finding in project language

Before evaluating a classifier, ask the responsible specialist to define the item of interest. A category name may sound obvious while covering several different situations. The buyer should identify what a reviewer would consider a relevant record, what is outside scope and how uncertain cases will be handled. Do not let the supplier's convenient label become the project's definition without discussion.

Also identify the unit being counted. A photograph, a marked region, an asset and a review event are not interchangeable business objects. The proposed evaluation should state which object receives the label and how the result relates to the receiving workflow. Procurement need not invent a technical matching method; it should require the provider to explain the method and obtain review from the appropriate specialist.

Agree who owns the reference labels

A comparison needs an agreed basis for deciding what an example represents. Ask who provides the reference labels, what instructions they follow and how disputed examples are resolved. If the buyer does not yet have a suitable labeled set, the quotation should identify that work rather than treating it as a free assumption. Label preparation is a distinct project activity with its own scope and responsible people.

Keep uncertain examples visible in the evaluation plan. A provider should explain whether they are excluded, reviewed separately or treated according to another agreed rule. The buyer should not accept an unexplained disappearance of difficult cases from the final report. Nor should procurement force a specialist to label an ambiguous record with false certainty just to make the evaluation table look complete.

Ask for counts that connect to the queue

Request a report that lets the reviewer trace proposed findings to the agreed examples. The team should be able to inspect records that were correctly flagged, records flagged unnecessarily and relevant records that were missed. These groups make the discussion concrete. They help the buyer ask whether the service is assisting the intended workflow or merely producing a score that looks persuasive in a presentation.

Do not substitute invented counts for an unavailable evaluation. If the provider has no evidence for the proposed use, record that limitation and ask what a bounded evaluation would involve. An educational example can explain a metric, but it cannot become a result for the buyer's assets. This article intentionally supplies no performance percentages because no evaluated model or project dataset has been established.

Compare errors in terms of actual work

The buyer should describe what an unnecessary review would require and what process exists for finding missed relevant records. Ask the operations owner to explain these consequences without assuming every item has the same cost or importance. The result may be a qualitative priority list rather than a numerical business case. That is acceptable when the evidence does not support precise estimates.

Have the analytics provider explain the supported tradeoffs in its proposal. A project may prefer a different review arrangement depending on staff capacity, the task and the consequence of a missed item. Procurement should not select a decision threshold from a generic article or treat a single metric as sufficient for approval. The responsible specialist should evaluate the actual proposed workflow and document the limitations of the recommendation.

Make the evaluation representative of the inquiry

Ask why the proposed evaluation examples are relevant to the buyer's intended records. A provider may have a useful demonstration from another context, but the buyer should understand the relationship and the differences. The inquiry should identify known variations that the specialist considers important and ask how the evaluation addresses them. Avoid turning a familiar product category into an assumption that every image source produces interchangeable analytics evidence.

Keep the purpose of the evaluation explicit. An early feasibility review may identify whether further work is worth considering; it is not automatically final acceptance. A demonstration used for sales explanation may be informative without supporting a deployment claim. The report should state the stage, the question answered and the work still required. This prevents a limited result from expanding through repeated retelling.

Preserve human review and accountability

Define who receives the classifier's output and who can make the subsequent decision. A proposed queue of records for review should not silently become an automated instruction to act. The commercial scope should explain how the human reviewer sees the relevant material, records a decision and raises an exception. These are workflow requirements to discuss with the provider, not claims that a particular software interface already exists.

For safety-related or regulated decisions, retain the appropriate qualified review and applicable processes. This article does not diagnose infrastructure, authorize maintenance, approve aircraft operations or propose autonomous targeting. It concerns the evidence needed to purchase a bounded civilian analytical service. A buyer should reject any attempt to use a procurement metric as a substitute for the professional judgment required by the underlying task.

The field lesson is to review the disagreements

United UAV's editorial lesson is to ask the supplier to walk through missed and unnecessary review items from the same agreed evaluation set. The discussion should explain how each group affects the receiving team's work. This is a proposed review habit, not a story about a successful customer trial. It keeps attention on the buyer's problem rather than rewarding whichever summary graphic appears most favorable.

Document questions that the walkthrough cannot resolve. A disagreement about a label may require the domain specialist; a mismatch in counting may require the analytics provider; an unclear receiving process may require the project owner. Assigning the question to the correct person is more useful than debating a headline percentage before the participants agree what was counted. Keep the unresolved items attached to the evaluation record.

Separate the analytics offer from the aircraft offer

The approved UIV2200 product page identifies an aircraft for a configuration inquiry. It does not establish an included classifier, a particular analytics subscription or a measured precision or recall result. Ask the aircraft supplier to confirm its offered configuration and ask the analytics provider to support its own claims. Where one organization offers both, the quotation should still identify the scope of each responsibility.

The VTOL and fixed-wing drone collection can help frame the wider aircraft discussion, but it is not an analytics benchmark. Unknown compatibility or service details must be confirmed before the buyer relies on them. A complete project may require several suppliers, and a clear boundary between their offers is a strength of the specification rather than evidence that the project is already integrated.

Keep the surrounding records interpretable

The guide to preserving attribute meaning during shapefile export addresses records that may accompany a wider inspection handover. The discussion of thermal sensitivity and temperature accuracy concerns evidence for a proposed sensor rather than its downstream classifier. These adjacent questions should remain separate in the project plan. Good labeling cannot repair an undefined sensor claim, and a clear sensor quotation cannot establish classifier performance.

Send United UAV a UIV2200 configuration inquiry that describes the proposed acquisition role, the human review queue and any separately proposed offline analytics provider. Ask which configuration details can be confirmed and which questions belong to the downstream service. The next useful deliverable is a scoped evidence plan with named owners, not a broad promise of accurate AI derived from an aircraft's product identity.