Define the crop observation before selecting a payload or ordering an NDVI deliverable. NDVI requires red and near-infrared inputs; an RGB image is not proof that those inputs exist. A UG62 inquiry should therefore ask about the proposed sensor, integration evidence and processing scope without assuming that any particular multispectral system is included. Start with the agricultural decision and have the intended recipient specify what evidence could support it.

A brief can become confused when its heading requests NDVI but its example is simply a colorful aerial view of a field. The buyer may want to identify areas for a closer ground inspection, compare observations over time or create a general visual record. Those are different requests. Calling all of them crop health mapping does not tell a supplier what to acquire or tell an agronomist how the result will be used.

Ask the recipient to name the observation

Begin the discussion with the person who will receive the map. What question are they trying to investigate? What decision could follow, and what further evidence would they need before acting? A short statement of purpose is more useful than choosing a color palette at the beginning. It also gives the buyer a way to distinguish a desired observation from an unsupported promise of an outcome.

Keep the request within the evidence that can actually be reviewed. A proposed mapping package might support a structured conversation about where to investigate next, but that does not make it a diagnosis or a treatment instruction. Ask the responsible agricultural professional to define the interpretation and any ground review. The aircraft supplier should not be expected to resolve agronomic questions merely because the project involves a drone.

The US Geological Survey's NDVI explanation defines the index using near-infrared and red measurements, with the expression (NIR - red) / (NIR + red). This is the limited technical point being carried into this article. The source concerns Landsat products; its satellite band identifiers, scaling and product characteristics are not specifications for a UG62 payload or a UAV processing service.

Do not approve an index by its colors

The buyer's first evidence request should identify the information used to produce the proposed output. Ask the provider to name the sensor configuration, relevant inputs and processing product. Then ask the receiving professional whether that package addresses the intended question. A picture with green and red areas is not, on appearance alone, a sufficient explanation of how an index was produced.

For an RGB deliverable, use language that describes the requested visual record honestly. For an NDVI deliverable, ask for evidence of the required spectral inputs and processing. If the provider proposes a different vegetation measure, have them identify it rather than silently treating the names as synonyms. This is a scope-control recommendation, not a claim that one type of deliverable is always the better purchase.

A hypothetical buyer might only need a clear record for planning a ground visit. Another may have an established workflow that calls for a named index and a specific review package. Their aircraft inquiries should not be identical simply because both concern crops. The useful comparison is between each proposed package and its own intended use, including any interpretation that remains the buyer's responsibility.

Write down what the supplier is being asked to demonstrate

Separate the configuration discussion from the output review. For configuration, ask which sensor and integration details can be confirmed for the proposed system. For output, ask what representative files, processing explanations and documentation are available. A supplier may be able to answer one set of questions before the other. Make that status visible rather than filling missing details with assumptions drawn from a product category.

Ask whether the proposed scope includes aircraft supply, sensor supply, integration, data processing, interpretation, or some defined subset. Record who provides each part and who will review it. This avoids treating a broad mission description as a complete contract specification. It also allows a buyer with an existing processing team to explain which services they do not need.

Where a sample output is offered, ask the provider to explain what it demonstrates and what it does not. A sample from a different configuration or context may still be useful for discussing format, but it should not quietly become evidence that the proposed system has already met the buyer's requirement. Keep demonstration context and project acceptance separate.

Use a small review package to clarify the handover

Our editorial recommendation is to agree the handover contents before discussing a full production campaign. Ask the recipient what they need to identify the output, understand its intended interpretation and locate any limitations. The answer might include a clearly named file, a method summary, an acquisition record and an explanation of who will conduct further review. The exact package should be determined by the project team.

Have the agricultural reviewer explain how the information would enter their workflow. If they cannot connect the proposed map to a decision or a follow-up question, pause the specification and clarify the purpose. Do not resolve the uncertainty by adding more visual detail or choosing a more dramatic palette. Better presentation can help communication, but it does not replace a defined use.

If repeated observations are intended, ask how the team will document the basis for comparison. Do not assume that similarly colored maps from different dates are automatically comparable. The relevant specialist should identify what must be held consistent or reported as a difference. The procurement brief should preserve that requirement without claiming a universal method for every crop, sensor and season.

A practical lesson for the first project meeting

Ask the agronomic recipient to describe one decision the proposed map could inform and one conclusion it should not be used to make. This is a suggested meeting exercise, not an account of a customer project. It gives the supplier a clearer target and helps the buyer avoid purchasing an attractive deliverable whose limitations nobody has agreed.

Write those two answers next to the output name. Keep them visible when the configuration, quote and review plan are discussed. If the intended decision changes later, revisit the requirements rather than assuming the original package still fits. A concise change record can be more useful than a longer brief that quietly mixes several different purposes.

Where UG62 belongs in this discussion

The UG62 hybrid VTOL drone product page is a starting point for a platform and integration inquiry. It is not evidence that an NDVI-capable sensor, a particular processing application or an agricultural interpretation service is included. No specific sensor compatibility, numerical performance or crop outcome is asserted here. Contact UNITED UAV for configuration details and identify the specialist evidence needed for the intended payload workflow.

Buyers looking across the VTOL and fixed-wing drone collection should retain the same observation brief while comparing possible systems. Ask each proposal to state its confirmed scope and unresolved dependencies. A wider platform shortlist does not remove the need to understand the spectral inputs or the deliverable review; it simply creates more proposals to evaluate against the same requirement.

Once the output is specified, processing and project costs still need their own checks. Our UG32 guide to category codes and resampling addresses a different kind of raster handover. Our UG82 guide to cost assumptions offers a way to organize uncertain project inputs without inventing a total. These are supporting buyer questions, not evidence that the aircraft models share a sensor package.

A concise inquiry checklist

One practical way to prepare the inquiry is to divide a single page into three columns: requested observation, evidence to be supplied, and person who will review it. Put a named output in the first column rather than a color description. Put a document or sample request in the second rather than a general assurance. Put a responsible role in the third rather than leaving review to whoever happens to receive the email.

Leave a row open when the team has not agreed on the requirement. That visible gap is a prompt for discussion, not a defect to conceal. The worksheet should help a buyer ask better questions before purchasing a system, including the possibility that the current brief needs more specialist input before a configuration can be evaluated.

• What crop observation is requested, and who will interpret it?
• Is the output RGB imagery, NDVI or another explicitly named product?
• What inputs and processing evidence does the recipient require?
• Which configuration and integration facts remain unconfirmed?
• What sample package will be reviewed, and what conclusions are excluded?

Use the checklist to expose unanswered questions, not to manufacture certainty. A provider should be able to distinguish a confirmed fact from an option requiring further assessment. The buyer should be equally clear about which requirements are essential and which are exploratory. That makes a configuration conversation useful even before the full project scope has been agreed.

To start a bounded discussion, send UNITED UAV your UG62 payload inquiry with the intended crop decision, named output and required input evidence. Include the recipient's sample-file expectations and identify any separate integration or agronomic reviewer. The next step is to confirm a suitable scope, not to assume that a green map or a platform description establishes an NDVI workflow.