The Verification Gate: A Work Method for Generative AI in Consequential Engineering Practice

1. Introduction

A split air-conditioning unit shows fault code E3. A technician asks a generative AI tool what E3 means. The manufacturer tables give three answers. Daikin lists E3 as actuation of the high-pressure switch (Daikin n.d.). GREE lists E3 as low pressure (GREE n.d.). Mitsubishi Electric lists E3 as a remote-controller transmission error (Mitsubishi Electric n.d.). The first two are opposite faults. A technician who acts on the wrong one adds refrigerant to an overcharged system, or recovers charge from a system that is already short. A tool that answers from memory, without the unit's own manual in front of it, cannot show which table it used. Its answer carries no marker of origin.

3. Definitions

Table 1. Definitions.

4. Failure Taxonomy

Table 2. Seven failure classes.

Figure 2. Published evidence behind three classes. (a) F1: accuracy on two table-reading tasks inside building codes, by table format, nine models (Liang et al. 2026). (b) Error type on two national engineer exams for building mechanical equipment that the model passed 5 of 5 times (Choi, Lee, and Kim 2025). Each error type maps to a question type. (c) Effect of tool design and of tool removal on learner grades (Bastani et al. 2025). Values are as reported in the sources' abstracts.

The seven classes share one property. In every case the output carries no external marker of error. So verification cannot depend on suspicion. It runs on every item and leaves a record.

5. The Method

5.1 Axiom

A number that has not been verified does not exist.

Operational meaning: a value that originates in tool output has no standing as data until someone checks it against an authoritative source. Until checked, the value is a draft. It may not enter a signed or submitted document, or a decision. The item types covered are those of Table 4, field 6.

5.3 Three steps and one gate

Figure 1. The process. Three steps in fixed order. The gate sits between tool output and any commitment. One unverifiable item blocks the whole output.

Step A. Do it yourself. A first pass at the task with no tool. An estimate, a manual reading, a written hypothesis, a rough draft. Step A takes five to twenty minutes. Its purpose is a recorded independent judgment, not an accurate one. The engineer writes the estimate down before opening the tool. An unwritten estimate does not count as Step A.

Step B. Ask the tool. A structured prompt with six mandatory parts:

1. Role: who the tool simulates (for example, a senior maintenance technician).
2. Context: equipment type, site, environment, which values come from measurement and which do not.
3. Task: what to produce, in a defined format.
4. Constraints: units, governing standard, length.
5. Source: the authoritative document, attached when relevant.
6. The missing instruction: "Do not invent. Write MISSING. If you lack a datum, ask before you write."

A prompt without parts 4 and 6 is not a prompt under this method.

Step C. The gate: compare, find the gap, log. The engineer checks every item in the output against an authoritative source, records the gap, and writes the result in the verification log. Table 3 gives the decision rule.

Table 3. Gate decision rule.

Gate rule. An output with one blocked item is not a deliverable. Partial verification is not a state in Table 3. One blocked item holds the whole output at draft.

5.5 Which control catches which failure

Figure 3. Coverage matrix. Rows are failure classes. Columns are controls in the method. Primary: the control is designed to catch that class. Secondary: it catches the class as a side effect. This is a design mapping, not a measurement. We plan to test it against logged gaps in version 1.0.

6. Instruments

6.1 The verification log (Appendix A)

Table 4. Verification log fields.

7. The Five-Level Scale

Figure 4. The five-level scale. Level follows the consequence of an error, not the difficulty of the task.

Table 5. Levels and requirements.

8. Installation in an Organisation

Figure 5. Five-step installation. Training is step 4, not step 1.

Table 6. Installation steps.

9. Boundaries

The method applies under three conditions. Outside them it gives no assurance.

9.1 The method does not apply when:

• There is no authoritative source. If no document with an owner exists, there is nothing to verify against. The gate blocks the item. That is the specified outcome, not a failure of the method.
• The task is creative or open-ended and leads to no commitment. Examples: brainstorming and personal study. These are level 1 tasks, and the gate does not apply.
• The "tool" is a validated deterministic system. Certified engineering calculation software is not a tool in the sense of this method.

9.2 The method does not promise:

• That the deliverable is correct. It promises that someone checked every item against a source and recorded the result. If the source is wrong, the deliverable is wrong, and the log shows exactly where.
• Speed. Step C adds time per deliverable. Field 13 records it, and we plan to report it (Section 10). Whether it is less than the cost of a signed error is an empirical question.

9.3 The method does not replace:

• Professional competence. Verification requires the competence to read the source. The method assumes that competence and does not supply it.
• Professional responsibility. Responsibility stays with the signer. ASHRAE (2025) and ASTM (2025) take the same position.

10. Evaluation Protocol for Version 1.0

10.1 Who may submit a log

Figure 6. Evaluation timeline. Consent and tagging at log point 1. Pre-test without tools at intake. One verification log per participant per task at log points 3–13. Post-test without tools at the endpoint.

11. Limitations

F7 is not yet measured. Right answer with wrong reasoning enters the taxonomy from field observation. It is the class most likely to change in version 1.0.