Don't Wait for Perfect Data: Phased Gates for Ontology Pilots

Clarify What Data Is Missing

The article opens with a common dilemma: "Govern data first, then build ontology" sounds safe, but waiting for all data to be accurate, complete, and timely may stall pilots indefinitely. Conversely, "Build ontology first; large models will understand dirty data" ignores that a model cannot replace the quality department's authority to decide whether a batch can be issued.

A practical alternative is "use to drive governance" (以用促治): define the task clearly, then identify which data gaps affect judgment and which can be deferred. Ontology modeling helps list these conditions, but quality requirements must be confirmed by the business and validated with real samples. This is not about tolerating errors; it's about focusing governance effort on the immediate task.

Define 'Sufficient' First to Know What Data to Supplement

In the hypothetical warehouse shortage assistant case, material codes are unified and unit conversions verified. However, some in-stock batches migrated from a legacy system lack quality restriction statuses, which the quality department has not yet cleared. These records may still serve for historical inbound analysis but are insufficient to decide today's issuance.

Missing a generic remark differs vastly from missing a quality status. The W3C Data Quality Vocabulary (DQV) adopts the same principle: provide quality information so users can judge fitness for their purpose, rather than issuing a universal "quality pass" for all uses. [Reference 1]

How Far Can the Same Data Go? Four Phases of Data Usage Thresholds

Projects often conflate "start modeling" with "go live"; the required conditions differ greatly. The following "Data Usage Phased Thresholds" table lists check items for four work stages. Checks cover evidence, timeliness, permissions, and verification results—not model confidence scores. This is the article's engineering recommendation, not a DQV-mandated process.

Phase 1: Concept Verification — What : Organize materials, batches, requirements, and judgment conditions. Conditions : Concrete questions and discussion materials; simulated data and unconfirmed definitions marked separately. Boundary : Diagram connected, but real data usability unproven.

Phase 2: Sample Verification — What : Verify identities, units, and calculation results. Conditions : Samples approved for use with traceable source and timestamp; rules and expected results confirmed by a person. Boundary : Sample pass does not generalize to entire inventory.

Phase 3: Continuous Query — What : Assist shortage verification within agreed scope. Conditions : Sample tests passed; update, permission, missing-data identification, and manual evidence-supplement mechanisms verified. Boundary : Return "pending verification" when data expires or key evidence is insufficient.

Phase 4: Business Execution — What : Perform reservation or issuance via the original system. Conditions : Explicit authorization; at execution time re-verify object, quantity, quality restrictions, and permissions; handle concurrency and indeterminate results. Boundary : Query showing sufficient does not mean reservation succeeded.

Approved for query ≠ approved for reservation or deduction. Queries must meet the phase's data requirements; read-only is not a license to conclude arbitrarily. Before execution conditions are met, the assistant can list verification results and pending evidence, but cannot write to inventory based on a query list alone.

Not every project must complete all phases. A task needing only concept clarification can deliver at phase 1; a historical analysis app need not add issuance capability. But if the goal states "query current shortage status," continuous update and exception handling must be verified—hand-corrected samples cannot substitute.

Ten Materials, Only Eight Verified: How to Display the Order

Materials with verified identity, quantity, unit, and quality status can enter trial use. The rest must be visibly flagged so users see them.

Assume a requirement has 10 materials; 8 are verified, 2 lack critical status. The system must not show only "8 verified items satisfied" and mark the whole order as no-shortage. It should display: "8 items satisfied per current records, 2 pending verification, cannot confirm full order fulfillment." If a verified item is actually short, indicate current inability to fulfill the whole order while listing remaining pending items.

This requires a three-state expression: Satisfied, Unsatisfied, Unknown . "Unknown" is not "Unsatisfied," nor can it default to "Satisfied." Each unknown must state what evidence is missing and who is responsible for supplementing it—not just show an unattended yellow light.

When a person manually clears the 2 items, don't just reply "can issue" in chat. Record the evidence, applicable time, and confirmer, and feed it back via the original process. For temporary supplementary records that cannot be written back immediately, agree on who maintains them, when they expire, and how to resolve conflicts with the source system—preventing them from being overwritten on next sync.

Query data can be synchronized over, but require periodic reconciliation and a clear source of truth. Don't let the ontology platform quietly spawn an unreconciled inventory ledger.

Time Requirements Cannot Just Say 'Real-time'

Daily reports and issuance cannot share a vague "data updates in real-time" promise. The former may only need last night's closing balance; the latter must handle how many are issuable right now.

Example: two orders query the same batch and both see sufficient stock, but that doesn't mean stock covers both simultaneously. Between query and request submission, quantity may change. This is the TOCTOU (Time-of-check Time-of-use) race condition: conditions true at check time may be invalid at use time. [Reference 2]

Re-querying before submission still leaves a window where another request can snatch the stock. The inventory-owning business system must embed condition validation and reservation in reliable concurrency control—locks, version checks, or other mechanisms—rather than letting the assistant bypass it with its own deduction.

"Interface syncs every minute" only states planned frequency, not whether the last sync succeeded or whether source data was timely. Page data timestamps must reflect actual update status; beyond the task's allowed freshness, stop giving definitive "currently available" conclusions.

Testing must go beyond normal queries: stop sync, leave quality status empty, see if the assistant still says "can issue." When execution is added, test two orders contending for stock, submission timeout with unknown result—check for over-reservation or duplicate processing.

These capabilities need not be rebuilt in the ontology platform. Reuse the original warehouse system's existing reservation, permission, and concurrency control: the model clarifies judgment conditions; the original system handles actual validation and execution.

Don't Just Write 'Data Pending Governance' on Task Orders

"Data pending governance" is unactionable. Replace with "Verify quality status of these specific batches," adding owner, deadline, confirmation evidence, and how the assistant responds before clearance.

Two ways to write the same dispatch differ greatly (owner and deadline are examples):

Unacceptable: "Material master data quality pending governance." Actionable & Auditable: "Quality Dept. Zhang by Wednesday EOD verify whether batch 2026A currently allows issuance; check valid inspection, release, and restriction records; note evidence and effective time; feed quality status back via original process. Before clearance, assistant returns 'pending verification'; after update, pilot verifier re-runs the issuance check for that batch, confirms result, then closes task."

Later, expanding from single-warehouse query to cross-warehouse transfer requires re-checking transport time, cross-warehouse permissions, etc. The original acceptance conclusion only covers the original task scope.

If a critical fact remains unobtainable long-term, adjust the goal, narrow scope, or pause dependent judgments. Drawing more concepts won't solve the problem of batch status never being confirmed.

Summary

Don't wait for company-wide data governance to finish before starting the pilot at hand. But for this issuance order, which items are cleared and which are not must be transparently shown to the user. Achieving this lets the pilot provide help while surfacing the next data gaps to fill.

Who does this work—especially how to schedule business experts' time—will be discussed in the next article.

References

W3C, Data on the Web Best Practices: Data Quality Vocabulary, Abstract and Section 1. This document is a Working Group Note illustrating the idea of judging data quality by purpose; it is not the normative source for the phased thresholds in this article. https://www.w3.org/TR/vocab-dqv/

MITRE, CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition. Used to explain the problem of resource state changing between check and use, invalidating the original check; the inventory example is designed for this article and does not imply a specific warehouse system has been confirmed with this defect. https://cwe.mitre.org/data/definitions/367.html