AI-Generated Ontologies: What Experts Must Review Beyond Syntax

First, Ensure Experts Understand What the Rule Is For

The quality manager does not need to read every link in the draft, but must know: what the draft says, where its evidence comes from, what the system will use it to judge, and who is affected if the judgment is wrong.

For example, if the draft states: "Batches with a qualified inspection report can be released," the reviewer must see who issued the report, which procedure version accepts it, and how the report is linked to the specific batch. Only then can the expert decide whether the rule misses conditions.

Material that is not verbatim from source documents but is an AI summary should be marked "to be confirmed." Even when original text is found, its version, scope, and context must be verified; copying an old clause does not mean it still applies. Conflicting statements from different sources should be listed together, not left for the model to pick the easiest one.

Changes the model made to existing definitions — such as adding an "inspection completion time" attribute or altering the "qualified batch" decision condition — must be highlighted separately. Their review focus differs and they cannot be buried in a single new diagram.

Using OPM (Object-Process Methodology), the reviewer can follow the state changes of batches and records through "submit for inspection, produce result, review, release." Any representation method should let business people verify in their own terms, not force them to read technical files line by line.

Block Machine-Detectable Issues First

Engineering teams should handle problems the machine can catch: unopenable model files, duplicate identifiers, missing references, and conflicts with existing definitions that tools can detect. How far automated checks go depends on the representation and tooling; do not treat one check as complete.

For instance, projects using RDF graphs can apply SHACL to validate data against written constraints and obtain a validation report. Checks such as whether inspection records contain a batch number or whether date fields have the correct type can be encoded as constraints.

"A batch number is present" is far from "this report actually belongs to this batch." Constraints may be wrong or incomplete; passing validation does not prove the report is genuine or the rule is valid.

AI can help explain errors and prepare counterexamples, but raw check results must be retained. Each failed item should be listed explicitly; a summary must not turn them into "overall compliant." This preparation saves experts from hunting format errors and lets them focus on business judgment.

Use Four Candidate Rules to See What Experts Actually Review

Assume the enterprise's confirmed procedure distinguishes supplier certificates, enterprise inspection results, and formal release decisions. The candidate model, however, collapses them into a single "qualified" state.

Extracting four problematic expressions makes the review concrete.

Candidate 1: Supplier certificate equals enterprise inspection pass

Business Question: Who issued the certificate? Can it replace enterprise inspection per our procedure?

Disposition: Rejected; separate the two evidence types and link each to the batch.

Candidate 2: No non-conformance record means the batch is qualified

Business Question: Is it truly qualified, or was it not inspected, not recorded, or not synchronized?

Disposition: Rejected; when unclear, retain as "to be verified."

Candidate 3: Any related report qualified allows full batch release

Business Question: Which samples or batches does the report cover? Does the procedure allow judging the whole batch on this basis?

Disposition: Revised after evidence supplementation; clarify coverage scope and applicable rules.

Candidate 4: Meeting release conditions automatically generates formal release result

Business Question: Who approves? Has the original system completed the processing?

Disposition: Modified; separate condition judgment, approval, and actual release.

These links may look clean in the diagram, but once in the system they would let unqualified batches through. Checking only naming and format cannot catch these issues.

Well-supported content should still pass quickly. If materials clearly distinguish "batch" from "inspection record," data correspondence and examples back it up, there is no need to re-debate those terms just to appear thorough.

Items involving business definitions go to the authorized business owner; items about identifiers and sources go to the data owner. Disagreements must be documented with the dispute and handler; the model must not vote for the team.

After Rejection, Make Changes Traceable

Take the rule "no non-conformance record means qualified" forward.

Rejection feedback must be specific, not just "rule not rigorous." Example: "Current data may not have synchronized inspection results; absence of a non-conformance record cannot justify a qualified judgment. Please revise and check whether batch filtering, alerts, and release recommendations use the same judgment."

When revising, distinguish two things: how far the batch's actual inspection has progressed, and how much evidence the assistant has. "Pending inspection" needs process records; "result not yet found" may only be a sync gap and must not rewrite the batch's actual state.

Inspection pass and release permission must also be expressed separately. Which states belong to the inspection task, which to the batch, and whether they can coexist must be confirmed per the procedure, not merged into one state list.

For this error, the revision can first be written as a business-verifiable statement:

For this query, per the applicable procedure verify whether inspection results cover this batch and remain valid. With a clear qualified conclusion, show "inspection passed"; with a clear non-conformance conclusion, show "inspection failed"; when evidence is insufficient or valid records conflict, show "inspection result to be verified" and list the gaps or conflicts. Whether release is permitted is checked separately against the procedure's required approval and processing records.

This revision goes to the quality manager for confirmation, then is implemented in the model, mappings, and judgment logic. It fixes "on what basis inspection pass is judged," not the full release procedure.

Validate with examples per the procedure: truly uninspected batches must not be filtered as releasable; valid non-conformance conclusions must show "failed" clearly, not ambiguously become "to be verified"; mislinked reports or conflicting records must trigger a check; missing results stay "to be verified." Batches that passed inspection but lack completed approval must not show "released"; batches with conditions met, approvals complete, and source system confirmation must show release normally, not be blocked across the board.

Keep the original candidate, rejection reason, revision content, test results, and confirmer together so future reviewers see why it changed, who approved, and where the approval applies.

If the enterprise procedure itself is unclear, ask the authorized business owner to confirm. Engineering can propose options, but must not write the easiest implementation as the formal rule just to meet a deadline.

When Time Is Limited, Prioritize High-Impact Reviews

Reused definitions that have not changed meaning need only a scope check. Merging two batches, treating "not found" as "none," changing report coverage or release conditions must be reviewed first because they directly affect which batches get released.

High confidence scores from AI cannot replace these checks. When ordering reviews, look at what happens if the judgment is wrong, how many applications are affected, and whether evidence is sufficient — not at how confident the model claims to be.

Large volumes of report-to-batch links can be sampled by agreed risk, source, and anomaly types, but the sampling plan must state what was checked and what remains uncovered. Critical business definitions and approval conditions still require sign-off by authorized personnel; a high sampling pass rate cannot substitute for that.

When measuring review efficiency, include preparation, confirmation, rework, and re-review time. Saving ten minutes on draft generation but costing the expert half a day to find errors is not a net gain.

Approve Only the Version Reviewed

If inspection record queries are cleared but release rules are still under debate, the query capability can be delivered after its own deployment checks. However, the output must only state what was found; it must not return an unconfirmed "release permitted" tag while claiming "read-only."

At release, align the versions of the model, data mappings, rule implementations, and tests. The content the expert confirmed must be the exact version the application uses. Approval records must specify scope, effective time, and permitted uses. A later AI-generated revision cannot reuse the previous approval.

Approval here means a specific rule version may be used within an agreed scope; it does not sign a release for every batch. At actual processing, the batch's facts, authorizations, and source system results must still be verified.

Testing must not let the same generation process both create test cases and provide expected answers. AI can help prepare cases, but business people must confirm expected results from source, and a held-out set of examples not used in debugging must be tested. Switching the model that generates cases does not remove this step.

If errors appear post-launch, first determine which results are affected, restrict the corresponding capabilities by risk, then revise and re-review. Do not let the model overwrite already-published rules just to fix quickly.

Summary

Back to the quality manager at the start: instead of hundreds of model elements, he needs to see the few judgments that affect release, their evidence, and before/after example results. Expert time spent there makes AI draft generation truly save effort.

If two experts disagree but each has evidence? The next article discusses how queries and applications choose the right interpretation when multiple perspectives are allowed to coexist.

References

W3C, Shapes Constraint Language (SHACL), Section 3 Validation and Graphs. Used to illustrate data validation against given constraints and reporting; the candidate review checklist and business dispositions in this article are author-designed. Passing SHACL checks does not mean business definitions are confirmed or factual truth verified. https://www.w3.org/TR/shacl/