Freeze the classification decision threshold before using the final acceptance set to judge a mapping workflow. A supplier can change predicted class labels by moving a cut-off even when the underlying model stays the same. For a UG25 project inquiry, request separate records for model fitting, threshold selection and final evaluation. The relevant purchase is an agreed decision process with auditable evidence, not a favorable score found by repeatedly adjusting the rule against the same test results.

When an unchanged model produces a different map

Imagine reviewing a proposal that identifies areas for a follow-up survey. The bidder presents a scored map and a rule for turning those scores into a yes-or-no class. During the meeting, someone moves the cut-off and the map changes. That adjustment may be legitimate development work, but it changes the decision process the buyer is being asked to accept.

The distinction becomes important when a report says the model was not retrained. A buyer may reasonably hear that as meaning the complete workflow stayed fixed. Ask a more precise question: did the transformation from score to decision change? If it did, the resulting evidence should identify the new rule and explain how it was selected.

This is editorial analysis for civil mapping procurement, not a claim that UG25 includes a classifier, analytics package or automated acceptance system. Any proposed camera, processing service or software integration must be confirmed separately. The discussion concerns how to review a contractor's classified deliverable when such a deliverable is part of the requested project scope.

The documented distinction

The scikit-learn threshold guide separates learning a predictive model from choosing an action based on its scores. It shows that a changed threshold can alter labels without altering the probability outputs. The guide also warns against fitting a classifier and tuning its threshold on the same data because of overfitting risk. Its software examples are not performance evidence for any aircraft or mapping service.

Our procurement recommendation follows from that distinction: record the threshold as part of the offered workflow. Do not hide it in an analyst's notebook while the contract names only the model. A reviewer should be able to reconstruct which rule produced the delivered classes and which evidence was available when that rule was chosen.

Give each dataset a declared role

Before evaluating bids, ask the analyst to describe the data used for fitting, tuning and final assessment. The description should explain how examples are grouped, who can inspect the labels and what changes are permitted after each stage. The appropriate validation design depends on the project; a generic split ratio is not a substitute for that design.

The buyer does not need to prescribe a particular software library. A supplier may use a different supported toolchain and still provide a clear decision record. Focus on evidence roles and reproducibility: what was optimized, against which objective, using which data, and what remained untouched until the workflow was fixed?

Where resources are limited, acknowledge the limitation rather than pretending that the same small dataset provides independent evidence for every decision. Ask the responsible specialist to propose a proportionate assessment and describe its uncertainty. A candid limitation is more useful than an impressive-looking test label attached to data that repeatedly guided development.

Define the decision cost in buyer language

Different buyers can prefer different trade-offs. An internal screening map used to prioritize manual review has a different purpose from a final inventory delivered without that review. Explain what happens after a positive classification and what happens when a relevant area is missed. These consequences belong in the scope discussion before anyone optimizes a metric.

Keep hypothetical costs separate from measured project costs. A team may use an illustrative comparison to clarify its preference, but it should not present assumed reinspection time or assumed missed-area expense as observed evidence. Ask the supplier to label assumptions and show which decision would change if those assumptions were wrong.

The selected metric should answer the stated business question. A single aggregate score can conceal the errors the buyer most wants to understand. Request the agreed error breakdown, sample context and review limitations alongside the summary. Do not demand every possible chart; choose the evidence that will support the actual acceptance decision.

An illustrative threshold review

Suppose a hypothetical contractor uses a binary classification to nominate locations for manual checking. It selects a cut-off during development, then evaluates the fixed workflow on the agreed held-out evidence. The buyer can review the result against its stated criteria, including how many nominations require review and which relevant locations were missed.

Now suppose the contractor inspects the final results, changes the cut-off several times and reports only the most favorable outcome. The final set has influenced the rule. The buyer should treat that activity as additional development, not silently accept the best result as an untouched final evaluation. The appropriate next assessment should be agreed and documented.

This example does not imply misconduct whenever a threshold changes. Adjustments can be useful when a project's objectives change. The problem is an undocumented transition between development and acceptance. Keep a revision record so commercial discussions are based on the workflow actually being offered, including any new evidence needed to support it.

Do not confuse threshold selection with calibration

A threshold is a decision boundary. A buyer may also need to understand what the underlying scores mean, but that is a separate review question. Ask the supplier to explain whether it is changing the score-producing process, the interpretation of the scores or the cut-off used for action. Naming the change helps prevent unrelated evidence from being used to justify it.

Similarly, a well-organized separation of sites does not automatically settle threshold selection. A project can avoid placing the same site in multiple subsets and still repeatedly tune its rule against the nominal final test. Review both issues. They protect different parts of the evidence chain and neither should be used as a blanket substitute for the other.

Make the handover usable outside the analyst's session

Request a delivery that identifies the input dataset, processing version, decision rule and class legend. The person receiving the files should not need to recover a missing parameter from a meeting transcript. Include a short explanation of how uncertainty or unresolved cases are represented, especially when the contract requires human review before an operational decision.

Ask for a representative sample before scaling the delivery. The sample should use the same export structure intended for the final package. Confirm that its metadata survives transfer into the buyer's working environment. This is an administrative acceptance check, not proof of classification quality; the quality evidence still needs its own evaluation.

Related data-governance questions appear in the UG62 non-detect reporting guide and the UIV2200 forward-fill provenance review. Those articles address qualified and propagated values rather than classifier thresholds. Together they help a buyer ask what each delivered field actually represents.

The field-oriented lesson

The editorial lesson is to stop calling evidence independent after it has repeatedly shaped the decision rule. Record the moment the workflow is frozen, what remains open and who may authorize a revision. This makes the review easier to explain to a project manager who did not attend the development meetings.

Keep rejected alternatives in a concise decision log. The buyer does not need every experimental output, but it should know whether the reported choice emerged from a declared development process or from repeated inspection of final results. A supplier's willingness to explain that distinction is more useful than an unexplained claim of optimal performance.

Questions for the proposal meeting

Is the default cut-off always wrong?

No. A default may be acceptable, but it should be an explicit choice evaluated against the project's objective. Do not replace one unexamined default with an equally unexamined custom value. Ask why the proposed rule is appropriate and what evidence supports that conclusion.

Can a threshold be changed after purchase?

Yes, where the project permits it, but treat the change as a versioned decision. Record the reason, responsible reviewer and reassessment needed. Do not reuse an earlier acceptance statement as though it automatically covers every later cut-off or class definition.

Does this establish aircraft suitability?

No. Analytics acceptance and aircraft configuration are separate decisions. The image acquisition requirements, operational permissions and proposed equipment must be reviewed on their own evidence. A favorable classification result does not establish any unverified UG25 capability.

Bring the decision record into the UG25 inquiry

Start with the UG25 product page and the VTOL and fixed-wing drone collection. State whether you are asking about an aircraft configuration, a separate processing workflow or both. Do not assume analytics, training, validation work or reprocessing is included in an aircraft offer.

Request configuration details with a sample class definition and your proposed acceptance decision. Ask the responsible provider to identify the threshold-selection data, the final evaluation plan and any exclusions. That brief gives the quotation a concrete purpose without inventing accuracy, savings or mission results.