A database can pass a structural integrity check while still containing broken references between related records. When reviewing a UG21 mapping proposal with SQLite-based deliverables, ask for separate evidence of structural integrity, declared foreign-key consistency and the project's own relationship rules. A single green result should not stand in for all three questions, and a successful check does not by itself establish complete GeoPackage conformance or survey quality.

What does integrity mean in the purchase?

The receiving team opens a survey package and sees a table of observations, another table of assets and a status message that says integrity passed. It is tempting to assume every observation belongs to a valid asset. But that conclusion depends on what the check actually examined. A readable database, a valid relationship and a correct real-world association are different properties. The purchasing specification should name each one it expects the supplier to demonstrate.

This matters when an operational team will act on the relationships rather than merely view a map. An observation attached to a missing parent may be omitted from a report or require manual interpretation. The correct response is not to invent a replacement parent during receiving. First preserve the delivered evidence and identify the unresolved relationship. Then ask the accountable supplier or data owner to explain it through the agreed correction process.

The important SQLite distinction

The SQLite PRAGMA documentation explicitly separates these checks: integrity_check does not find foreign-key errors, while foreign_key_check reports violations of declared foreign-key constraints. A receiving report should therefore identify which check ran and what it returned. The generic phrase database integrity is too broad to communicate that distinction reliably.

There is another boundary: a relationship that exists only in a project convention is not necessarily a declared foreign key. A clean foreign-key result cannot demonstrate compliance with rules that were never represented as those constraints. Ask the analyst which relationships are declared in the database and which need a separate project-specific review. This article offers a procurement framework, not a replacement for format validation or a complete database testing procedure.

Start with a relationship inventory

Request a concise inventory of the tables that matter to the delivered workflow. For each relationship, name the child table, parent table, linking fields and business meaning. Explain whether the relationship is optional, whether one parent may have several children and how historical records are represented. These definitions help the buyer distinguish a genuine exception from an allowed state that merely looks unusual in a spreadsheet.

The inventory should also say where the rule is enforced or checked. A declared database constraint, an application check and an analyst's manual review are not interchangeable forms of evidence. They may all contribute to a defensible handover, but the receiver must know their scope. An undocumented assumption that a field always contains a valid identifier is not an inspectable control, even when earlier deliveries happened to work.

A fictional orphaned observation

Suppose a fictional observation table contains a record referring to asset P, but the delivered asset table does not contain P. The observation may be perfectly readable. Its description may even look plausible. That does not resolve the missing parent. The reviewer needs to determine whether the package omitted a required record, used an obsolete identifier, intentionally delivered a subset or followed a documented historical-data convention.

Those explanations lead to different actions. A missing required parent may need a corrected package. A deliberately scoped subset may need an explicit external-reference contract. An obsolete identifier may require an approved mapping supplied by the data owner. The receiving analyst should not choose among these merely to make a check return no exceptions. The example is illustrative buyer analysis, not a reported customer incident or a claim about UG21 equipment.

Check the same snapshot throughout

Make the delivery identity part of every result. If the structural check ran against an earlier database and the relationship review used a later copy, the combined report may describe no single delivered artifact. Ask for the package identity, check time, software context and report location. These records let the receiving team connect each finding to the file it actually received rather than to a familiar project name.

Keep the original delivery unchanged during review. Use the agreed read-only inspection approach and retain any diagnostic output. Where a tool or process requires a working copy, document that copy and its relationship to the incoming file. Do not convert a receiving check into an undocumented repair. Any corrected delivery should have a distinct identity and an explanation of what changed, who authorized it and which checks were repeated.

Preserve useful exceptions

An exception report should help someone resolve a problem, not merely count it. Ask for enough information to locate the affected relationship, understand the violated rule and identify the responsible owner. Protect sensitive project information when sharing examples outside the receiving team. A redacted sample can demonstrate the reporting structure without disclosing customer assets, locations or operational details that are unnecessary for the procurement discussion.

Separate unresolved, accepted and corrected exceptions. An accepted exception needs a reason and an authorized decision, not just a changed status. A corrected exception needs a new delivery or an auditable correction record. An unresolved exception should remain visible in the handover. This keeps the reporting process from rewarding silence and makes it possible to distinguish technical completion from a commercial decision to accept a documented limitation.

No exceptions is not always the same as broad coverage

Ask what population the check examined. Were all relevant tables included? Were some relationships excluded because they are optional or handled elsewhere? Did the report cover only declared constraints? A narrow check can be entirely correct while leaving important questions unanswered. The buyer should require a scope statement beside the result so that a future reader does not extend the conclusion beyond the evidence.

Also ask what the check cannot know. A reference may point to an existing parent and still identify the wrong real-world asset. That problem requires a different source of evidence and a different review responsibility. Database consistency is valuable, but it is not a substitute for the project's survey, attribution or asset-management acceptance. Keeping these distinctions explicit helps avoid both false reassurance and unnecessary rejection of a useful technical check.

A receiving exercise for the project team

Our editorial field lesson is to ask the reviewer to explain one relationship from end to end. Begin with an observation, locate its parent according to the documented rule and identify the evidence that the relationship was included in the review. Then choose a documented exception and trace its disposition. The exercise tests the clarity of the handover, not the operator's ability to remember an undocumented database convention.

Agree the expected explanation before the exercise. Otherwise an experienced analyst may quietly compensate for missing documentation and make an incomplete package appear usable. Record where the written material was sufficient and where clarification was needed. These findings can inform a modest, specific revision request rather than a vague demand for more documentation. They also clarify which tasks belong to the supplier and which remain with the buyer.

Keep joining and packaging questions separate

Relationships may be created during table integration. The UG32 review of missing identifiers in attribute joins addresses a different risk: software can report a match even though the inputs do not identify an asset. A relationship that resolves in the final database does not explain how that association was created. Retain the relevant transformation evidence when it forms part of the contracted workflow.

Some packages also reference external raster data. The UVH1 VRT dependency guide explains why receiving a descriptor is not necessarily receiving all its sources. A structurally sound database cannot make an unavailable external resource accessible. List those dependencies and their owners alongside, rather than inside, the relationship acceptance decision.

What to ask about UG21

The UG21 product listing identifies the model for a configuration conversation. The VTOL and fixed-wing collection provides category context. Neither establishes that database design, GIS processing, software licensing or validation services are included. Confirm the proposed aircraft configuration and any data-service responsibilities independently; do not infer them from a discussion of a useful receiving check.

Prepare a short relationship inventory and an anonymized exception example before contacting the supplier. Through the UNITED UAV inquiry page, ask who will produce the final database, which relationship rules will be checked and how the recipient will receive separate structural, foreign-key and project-rule results. A clearly scoped evidence request makes it easier to compare proposals without turning a software status message into an unsupported promise.