The UG73 product record states a 100 km full-load flight radius. That is a product fact, not a guarantee that a crew can inspect 100 km of corridor, return with the required reserve, maintain the necessary communications, capture acceptable data, or operate from a specific site. Flight radius and inspectable route length use different evidence. Route geometry, payload, turns, climb, terrain, weather, recovery options, fuel planning, communications, approvals, data-quality settings, and contingency policy can all change the usable plan.

A buyer can easily copy the radius value into a proposal and present it as coverage even though the route may require return legs, offsets, repeated segments, holding, alternate recovery, or stricter data capture. The operating team therefore needs a record that separates observed evidence, approved product facts, configuration-specific statements, buyer assumptions, and unresolved questions. That separation matters because a successful flight can still leave the next crew unable to reproduce the result, while an interrupted flight can still produce useful evidence when the record identifies what happened and who owns the next decision.

Define the Decision Before the Aircraft Moves

Define whether the review is screening UG73, planning a demonstration, sizing a corridor segment, or accepting an operational route. State the required reserve and recovery authority before calculations begin. Write the decision states in the briefing rather than inventing them during the debrief. A useful set may include pass, monitor, repeat, stop, or escalate, but the organization should define each term for its own workflow. Name the person who can assign a state and the evidence required to change it later.

The approved radius claim remains bounded by its product-page wording; route coverage, communications, payload integration, fuel plan, regulatory approval, and customer deliverable remain separate questions. This boundary prevents commercial language, training observations, and field improvisation from being treated as interchangeable proof. It also gives the crew permission to record an unknown without filling the gap from memory. Unknown does not mean unsuitable; it means the question still needs an identified source, test, or accountable owner.

Lock Product Facts and Configuration Identity

The relevant approved claim is a 100 km full-load flight radius, described as flight radius rather than communication range. These values belong to the current approved product record and should keep their qualifiers. They do not automatically describe a proposed payload, a site-specific route, a regulatory permission, a reserve policy, or an accepted customer deliverable. Any calculation built from them should be labeled as a buyer model until a controlled exercise supports the intended use.

Open the current UG73 fuel-powered fixed-wing VTOL product page at the start of the review, then record the aircraft identity, payload or accessory identity, installed software or firmware references when applicable, power arrangement, data-storage media, configuration revision, and responsible technician. Record the payload and fuel planning basis, route revision, launch and recovery sites, and any alternates used by the planning model. A generic model name is not enough when a wiring change, payload change, settings change, or document revision can alter the evidence.

Capture Conditions Without Guessing Causation

Keep the product fact, buyer calculation, route assumptions, field observations, and accepted operating limit in separate fields. Record time, location, crew, mission-plan revision, configuration identity, relevant environmental observations, warnings, operator actions, and the resulting files or logs. Use direct descriptions such as what the crew saw, heard, measured, or recovered. Keep causal theories in a separate field so a plausible explanation cannot silently become the official finding.

A route may fit a radius circle on a map yet fail the mission review because terrain blocks communications, a recovery site is unavailable, or the data plan requires repeated passes. The record should show the first known deviation, every material action after it, and the condition at recovery. If an item cannot be confirmed, mark it unavailable and explain why. A short, honest gap is safer than a detailed reconstruction that blends memory with evidence, especially when another team will use the packet for training, maintenance, procurement, or supplier support.

Build a Radius-to-Route Evidence Matrix

The matrix should show how each mission assumption converts a headline radius into a conservative route decision. Use a controlled form or digital entry with a stable identifier, revision, author, reviewer, and closure date. The following fields create a practical minimum; organizations can add requirements that reflect their approvals, safety system, customer contract, or data policy.

• decision and customer deliverable
• aircraft and payload configuration
• approved radius claim and qualifier
• route geometry and required offsets
• launch, recovery, and alternate sites
• reserve and contingency policy
• terrain and elevation context
• communications evidence
• data-capture settings and repeat rules
• weather and operational limitations
• approvals and site controls
• accepted segment length and review triggers

Do not make every field mandatory in every circumstance. Instead, identify which omissions block a decision and which can remain open with an owner and due date. The final route length should be traceable to the controlling assumption rather than copied from the product claim. The goal is a compact evidence chain that a second reviewer can understand without interviewing the original crew.

Assign Roles and Protect the Handoff

Give the mission planner, payload specialist, maintenance or fuel-planning owner, communications reviewer, remote-pilot authority, and customer-quality reviewer defined inputs. Separate the person who performs the task from the person who accepts the evidence when independence matters. The handoff should state what is complete, what remains uncertain, which files are authoritative, and whether the next team may continue operations. A shared folder with unexplained files is storage, not a controlled handoff.

The flight crew should receive the accepted segment and recovery rules, while commercial staff receive a clearly qualified coverage statement. Confirm that copies are readable, filenames and timestamps can be reconciled, and access is available to the named reviewer. Protect raw evidence from accidental alteration. If a derived file is used for a decision, keep the method and relationship to the source visible. This is especially important when coaching notes, technical logs, customer deliverables, and maintenance records live in different systems.

Use a Field Exercise That Can Fail Safely

Validate a conservative permitted segment with the proposed configuration and recovery plan instead of trying to demonstrate the published maximum. Brief stop conditions and recovery actions before launch. A useful exercise should test the workflow, not encourage the crew to push through an uncertain condition just to obtain a pass. Capture deviations from the plan and distinguish a limitation of the exercise from a limitation of the product.

Compare planned and observed timing, reserve, communications, payload operation, data completeness, and recovery, then state which assumptions remain untested. Review the evidence immediately enough that missing files or unclear notes can still be resolved, but do not change the acceptance criteria after seeing the result. If the team repeats a step, preserve the first result and explain the reason for repetition. This makes improvement visible and prevents the final successful attempt from erasing the path that produced it.

Escalate With a Reproducible Packet

Ask configuration-specific questions about payload, route, recovery, communications, maintenance, and fuel planning rather than requesting a universal coverage number. Use the UNITED UAV configuration inquiry when a supplier answer or configuration review is required. State the desired decision, attach or reference the controlled evidence, and ask which response is a published fact, a configuration-specific statement, a diagnostic hypothesis, or a request for another test. That classification keeps support communication useful for future reviewers.

Ask the supplier to distinguish published product facts from configuration proposals and mission estimates. Record the response date, author, affected configuration, attachments, commitments, and follow-up owner. Do not turn a preliminary support suggestion into a permanent procedure without the organization’s required review. If the response changes the configuration or test method, identify which earlier evidence may no longer be comparable and which acceptance steps must be repeated.

Turn the Record Into Operational Knowledge

Use completed matrices to teach sales and planning teams why radius, range, endurance, and accepted route coverage are not interchangeable terms. Remove personal commentary that does not help the decision, but preserve the technical sequence and uncertainty. Training material should teach how to recognize, capture, and escalate a condition; it should not imply that one example predicts every mission. Procurement summaries should cite the controlled record rather than paraphrase a remembered outcome.

Schedule a periodic sample review for completeness, decision consistency, open actions, and repeated failure patterns. Trend categories carefully: several records can reveal a process weakness, but they do not by themselves prove product performance. Use the broader VTOL and fixed-wing drone collection only when the documented requirement justifies comparing another platform class.

Close the Decision and Define Review Triggers

Approve only the segment supported by the current route, configuration, reserve, communications, recovery, approval, and data-quality evidence. Record the rationale, evidence references, limitations, owner, and effective configuration. Define the events that reopen the decision, such as a payload change, wiring change, software or firmware change, revised route, new customer deliverable, different crew qualification, unresolved discrepancy, or updated product information. A pass without review triggers can become an unsupported permanent assumption.

Attach the matrix to the request for quotation and require every coverage statement to cite its assumptions and review owner. Continue with the UVH2 link-and-endurance boundary review and the multi-payload qualification workflow to connect this record with the same-day planning and qualification workflows. Together, the documents should make clear what is verified, what is assumed, what remains unknown, and who can authorize the next step.