A field domain describes permitted attribute values, but its presence does not prove that every delivered record complies. For a proposed UG32 inspection-data workflow, request a final-record validation report against the agreed domain version, with exceptions and missing values identified separately. Establish which software enforces the rule and which merely carries its definition. Do not treat a domain label, a tidy dropdown, or a successful file export as equivalent evidence.

Why can a permitted-value list coexist with an invalid value?

Consider a hypothetical asset register whose declared condition values are review, accepted, and deferred. A delivered row contains pending. The file still includes the declared list, and a reviewer can see that list in the metadata. The list's presence answers what was intended, not whether the row conforms. Before correcting anything, ask whether the delivered record is wrong, the declared list is outdated, or the producer used a different approved version.

This is a receiving-data question rather than a claim about UG32 sensors, flight capability, or included software. An inspection buyer may be purchasing a platform, a processing service, or a combined arrangement. Each has different responsibilities. If the expected deliverable includes a structured asset register, its value rules deserve a written acceptance condition. Leaving that condition implicit makes it easy for an export to be called complete even though the receiving system cannot use some of its records.

What does the technical documentation actually say?

The GDAL vector data model documentation describes coded, range, and glob field domains. It also states that GDAL itself does not enforce those constraints, so values violating a domain can still be written. Other applications may apply their own enforcement. The narrow conclusion is that domain metadata and actual validation are separate evidence items; it is not a claim that all GIS applications behave alike.

Ask the workflow owner to identify the component that rejects or reports inadmissible values. Is it an editing form, an import step, an application-specific validator, or a final delivery check? A description such as domain-enabled is not enough. The buyer needs to know where the rule is applied, which version is applied, and what happens when a record fails. If no component performs that check, the proposal should make the gap visible instead of implying that the file format closes it.

What belongs in the agreed value rule?

Define the field, its intended meaning, its storage type, and the applicable domain. For a coded list, distinguish the stored code from any display label. For a range, state the bounds and how the boundary values are treated. For a pattern, provide representative permitted and rejected strings. These are acceptance-design recommendations, not universal implementation instructions. The proposed software and delivery format still need to demonstrate that they interpret the agreed rule in the intended way.

Handle missingness deliberately. An absent value, an explicit unknown code, an empty string, and a text label saying not inspected may carry different meanings for the asset owner. Do not silently merge them to make a report look cleaner. Decide which states are permitted and when they require explanation. The domain rule can then be paired with a completeness rule without confusing the two. A value can be admissible yet still fail to provide the information the project requires.

How should the final-record report be structured?

Start with the exact delivered artifact, its checksum, the layer or table, and the domain revision. Record the inspection tool and the time of the check. Summarize how many records were examined, how many passed the stated value checks, and how many require review. Those counts must come from the actual inspection; the examples in this article are not project results. The report should also disclose any fields or records excluded from evaluation and why.

For each exception, retain a stable record identifier, the field name, the delivered value, the applicable rule, and the reason it was flagged. Preserve enough context for the producer to investigate without exporting unrelated sensitive attributes. A report that lists only a total leaves the buyer unable to assess whether the problem is concentrated in one imported batch or spread across the delivery. The exception register should support a decision, not merely announce that something is imperfect.

Can a small sample expose a misunderstood rule?

Before the full delivery, propose a deliberately small acceptance sample containing a permitted value, an out-of-domain value, a missing value, and a value whose interpretation depends on the domain revision. Label the sample as synthetic. Ask the producer and receiver to evaluate it independently, then compare their dispositions. The purpose is to reveal different interpretations early, not to claim that four examples prove the correctness of an entire production dataset.

For the fictional condition list above, accepted may pass membership, while pending may be flagged. A null value needs the separately agreed missingness rule. If a later domain revision introduces pending, the same text may receive a different disposition under that revision. A useful test records both the value and the rule version. Without that pairing, a disagreement can appear to be a software defect when the parties are actually applying different contracts.

Who decides whether to correct data or revise the domain?

The data producer should not broaden the allowed list solely to remove exceptions. The asset owner should not demand arbitrary replacement codes solely to achieve a zero-error report. First determine what each exception represents. It may be a spelling inconsistency, a legitimate new category, an import artifact, or an unresolved observation. Those cases call for different decisions. Preserve the original value and the rationale for any change so the accepted dataset remains explainable.

If the domain changes, issue a controlled revision and identify which records were reevaluated. If the records change, retain the correction mapping and validate the replacement delivery. Do not overwrite the original package before the discrepancy is understood. This editorial lesson is practical rather than autobiographical: a clean report is useful only when the path to that result is documented. Otherwise, the buyer cannot distinguish improved data from a rule changed merely to accommodate it.

Does passing a domain check establish factual accuracy?

No. A permitted condition code can still describe the wrong asset, refer to an outdated observation, or reflect a mistaken interpretation. Domain membership concerns whether the value belongs to the agreed set or satisfies the agreed rule. Evidence for the observation and its association with the asset remains a different requirement. Do not use a successful attribute check to imply that an inspection finding is correct, complete, or suitable for a safety-critical decision.

The same separation applies to geometry and indexing. The UG39 GeoPackage consistency discussion examines whether a spatial index corresponds to its features. That does not validate their condition codes. The UVH-PNP configuration-default discussion addresses another common confusion between a declared rule and an effective value. A procurement team can reuse the habit of asking what was tested while keeping the technical conclusions distinct.

How can this improve a UG32 scope discussion?

Use the UG32 product page to anchor the platform identity, then supply a short example of the desired asset-data structure. Ask which proposed software, processing service, and delivery responsibilities are actually included. This article does not establish that a particular configuration produces the example register or supports the receiving application. Those details need written confirmation based on the proposed equipment and workflow, rather than inference from a product category.

When comparing the VTOL and fixed-wing range, keep the data acceptance requirements consistent across offers. A proposal that includes field-domain metadata but no record validation is different from one that includes both. Either may be appropriate depending on the buyer's internal capability, but the difference should be priced and assigned openly. Ask who resolves exceptions and who approves a revised domain, rather than assuming that every issue belongs to the aircraft supplier.

What should the receiving team accept?

Accept the attribute portion of the delivery when the final records have been evaluated against the agreed rules and every exception has an approved disposition. That may mean no exceptions, or it may mean a documented set of accepted limitations. The important condition is an explicit decision by the responsible owner. Avoid treating an unexplained exception as acceptable simply because a file opens, and avoid rejecting a documented permitted exception because an automated summary lacks context.

For US and Australian asset teams, this provides a common technical conversation without inventing market demand or assuming identical procurement rules. Bring the project-specific schema and review obligations to the discussion. A concise evidence package can include the domain revision, synthetic test rows, final validation report, exception register, and replacement history. Keep each artifact tied to the accepted file so later imports can be investigated against a stable baseline rather than memory.

Send a small, non-sensitive schema sample through the UNITED UAV inquiry page with your UG32 configuration questions. Include an allowed-value list and ask who will validate the final records, resolve exceptions, and confirm compatibility with the proposed receiving workflow. That request produces a more actionable scope discussion than asking whether the system supports GIS in general. It also makes clear which assurances are being requested and which still require evidence.