Instead, the actual evidence consists of quoting one researcher from a 1993 newsletter, referencing an old experiment by an engineer who sold his company, and a single anecdote about blowing smoke at a bathroom fan.

When you execute an argument that poorly and try to mask the lack of hard data with a self-appointed "Principal Scientist" title, the article fails just as spectacularly as a ridge vent installed over solid plywood. Thin, transparent smoke.

😆

The Proposal

Home inspectors are hearing about artificial intelligence from every direction right now. Conference keynotes describe it. Vendors demonstrate it. The trade press covers it. At the same time, ASHI's membership is in the process of adopting the recently approved update to the Standard of Practice, one that expands reporting requirements across dozens of systems and components.

This paper proposes an artificial intelligence tool built to check a submitted home inspection report against the Standard of Practice, item by item, for compliance. What follows is that proposal in full: what the tool would do, how it could be built, and what it would take to make it trustworthy enough to use. It is offered here as a real design worth ASHI's consideration.

What Such a Tool Would Do

The basic design. A compliance tool of this kind would take a submitted report, compare its language against the Standard of Practice section by section, and flag places where a required item appears to go unaddressed. Stated plainly, that is the entire function: read a report, read a standard, find the difference between them.

How it might be built. Several architectures could carry out that same function: comparing a report against the Standard to find where the two differ. It could run as an interactive aid a reviewer uses while reading a report, with a person present at every step. It could run as an automated process that produces a finished compliance summary without a person involved until the results are read. It could combine both, with routine checks automated and harder judgment calls routed to a person. The choice between these matters less than it might seem. The harder and more valuable work is translating the Standard's language into specific instructions, so the report can be compared against them as an indication the inspection met the Standard.

Choosing the right technology. Choosing which AI system performs this work matters less than choosing one honestly: a system willing to say a report is unclear rather than guess at what it probably means. That choice can be made once ASHI decides the effort is worth pursuing. It does not need to be settled here.

Testing the Design Against a Single Requirement

Consider a single, concrete case: a requirement that a specific system or component be inspected. Checking compliance with that requirement means looking for an indication, in the report, that this specific item was inspected, not merely an indication that an inspection took place. And this concern is not limited to one item. The same question applies to every item the Standard requires an inspector to inspect, across the entire report.

Here my proposal runs into a real problem, and I do not have a solution for it. When a report contains no statement about a required item, that silence could mean either of two things: the inspector looked at the item and found nothing wrong, or the inspector never looked at the item at all. The words on the page are the same in both cases: the same blank space where a statement about that item would otherwise appear. Because the wording does not change between those two situations, no reviewer, human or artificial, can look at the report and determine which one actually happened. And this is true for every required item in the report, not only the one used here as an example.

What the Attempt Shows

This limit is not a defect in any particular tool. It traces back to the Standard itself. Neither the current Standard of Practice nor the approved 2026 update states that reports should follow a report-by-exception convention, where an unaddressed item is understood to mean nothing was found. Neither requires the report to offer an indication that an item found to be in sound condition was actually inspected. The question of what an inspector's silence is supposed to mean is not answered either way.

This is not an abstract concern, and it is not limited to one or two overlooked items. Sections of the Standard already contain no requirement to say anything at all when a component shows no deficiency, and a citation-by-citation review of the Standard's own text, published separately, identifies ten components the Standard requires an inspector to examine where no requirement, conditional or otherwise, ever calls for a word to be written about them. The result is a report that meets the Standard's written requirements while offering no indication that certain systems/components were inspected.

The same limitation already exists in the current report review process used for certification. A reviewer checking a submitted report faces the identical question an automated tool would face: is an unaddressed item a sign the inspector missed it, or a sign the inspector found nothing worth reporting? Nothing in the current process asks whether the report actually gives any indication of which possibility occurred before a determination is made. Building an AI tool on top of that process would not introduce a new weakness. It would inherit one that already exists, and very likely apply it at greater scale and with greater apparent authority than a person's judgment carries today.

What Would Make This Possible

A reliable compliance tool depends on the Standard first, and the review process second. The sophistication of the technology chosen comes third, if it matters at all.

Asking whether certain systems/components were inspected, rather than guessing at an answer, would resolve the problem this paper describes. That question does not require any change to the Standard, and the certification review process could start asking it today, before any tool like the one proposed here is ever built.

The larger fix does require a change to the Standard. What indicates that an item was inspected must be stated clearly in the Standard. That has to be settled before any technology can be built to check for it. Compliance is not only a property of the inspection performed. It depends on the report as well, since the report is the only indication available to anyone reviewing it after the fact. A report with nothing wrong written in it does not automatically indicate that every required item was inspected. Right now the Standard does not say what a report must contain to serve as that indication, and the certification review process has never stated its own criteria for judging whether a report provides it. Both would need to exist before a compliance tool, of any design, could do the work this paper set out to test.

Closing

The tool described here is buildable and worth building. I have tried to show that a small refinement of the Standard must be done before any technology would be able to accurately review inspection reports for compliance. This is the work of deciding what a home inspector's silence is allowed to mean.

I'm interested in knowing what are the top features you feel are important to have in reporting software, and what platform you use and why.

Thanks!!