You can paste a certified payroll report into a general-purpose chatbot and ask if it is compliant, and it will give you a confident answer. The problem is that the answer is often wrong, and worse, it is wrong in a way that looks right. Auditing a payroll is not a language task that a capable model can reason through from the document alone. It requires the specific wage determination that governs the project, the state overtime and fringe rules, the apprenticeship registry, and a process that refuses to guess when it does not have the data. A chatbot has none of those by default.
The audit needs data the model does not have
A prevailing wage audit compares each worker against a rate table that is specific to the project: the county, the trade classification, the effective date of the determination, the base rate, and the fringe amount. That table is not in the model's general knowledge, and it changes. Determinations are updated on a schedule, and the one that governs the job is fixed by the contract, often a specific determination locked at bid or award. A chatbot asked to audit a payroll without the governing determination is not auditing. It is inventing a plausible rate and checking against that, which is worse than not checking at all because it produces false confidence.
Confidently wrong is the dangerous failure
A tool that says "I do not have the wage determination for this project" is useful. A tool that invents a rate and tells you the payroll passes is dangerous, because you will file it. In compliance, a confident wrong answer is worse than no answer.
The rules are jurisdictional and mechanical
Prevailing wage compliance is a stack of jurisdiction-specific rules. Federal Davis-Bacon overtime differs from California daily overtime after 8 hours. Fringe credit rules differ by benefit type and by whether the plan is bona fide. Apprentice rates depend on registration in an approved program and on a ratio measured against journeyworker hours. These are not judgment calls a model should improvise. They are lookups and calculations against authoritative sources, and the correct behavior is to apply the rule exactly, not to approximate it. A system that treats the rules as a matter of reasoning will drift. A system that treats them as deterministic checks will not.
Does giving the chatbot the determination fix it?
Handing the model the wage determination, the approach usually called retrieval augmented generation, helps, but it does not close the gap on its own. Two problems remain. First, retrieval has to fetch the right determination and the right revision, the one locked to the contract, not a similar-looking one for a neighboring county or a newer publication, and a model choosing among near-identical documents will sometimes choose wrong. Second, even with the correct determination in the prompt, a language model applies rules probabilistically. It will usually add base and fringe correctly and occasionally will not, and across a crew of fifty workers and a project of many weeks, occasionally is often. Compliance does not tolerate a small error rate on arithmetic, because each error is a real underpayment.
Where does hallucination actually bite?
The dangerous failures are not the obvious ones. A model rarely invents a wildly wrong rate that a reviewer would catch at a glance. It produces a plausible one: an operating engineer rate from the wrong equipment group, a fringe figure that is close but not the listed amount, an overtime calculation that used the federal weekly rule where the state daily rule applied. Each is subtle enough to pass a quick human review and wrong enough to be an underpayment. And because the model states it with the same confidence as a correct answer, there is no signal telling you which lines to double-check. A tool that is right most of the time, with no way to know which times, is not usable for something you sign under penalty.
What does a real compliance system do differently?
- It loads the actual governing wage determination for the project, not a general idea of the rate.
- It reads the payroll into structured data, worker by worker, line by line, rather than skimming the document.
- It applies the correct jurisdiction's overtime, fringe, and apprentice rules as deterministic checks.
- It tracks apprentice and journeyworker hours over the life of the job, because ratios are cumulative.
- It says clearly when it lacks the data to decide, instead of guessing, so a missing determination is flagged, not filled in.
Where does the AI actually add value then?
The place AI earns its keep is reading the messy input, not deciding the rule. A certified payroll arrives as a scanned PDF, a photographed form, a subcontractor's idiosyncratic spreadsheet. Turning that into clean, structured data that can be checked against a determination is genuinely hard, and it is where a strong model helps enormously. The judgment about whether the numbers comply then runs against authoritative rules and real determinations, deterministically. The model does the reading. The system does the auditing. Blurring those two is exactly why a general chatbot gets it wrong.
Is it ever fine to use a general chatbot here?
Yes, for the right questions. A general chatbot is genuinely useful for understanding a rule, drafting a plain-English summary of how fringe credits work, or getting oriented on an unfamiliar form. Those are learning and explanation tasks, where an approximate answer that a person then verifies is fine. The line is crossed when the output becomes a decision you act on without checking: whether a specific worker on a specific project was paid correctly, whether this payroll can be filed, whether the credit is safe. For those, the tool has to hold the governing determination, apply the exact rule, and be able to show its work. Using a chatbot to learn is smart. Using one to certify is the mistake.
Why does this generalize beyond payroll?
The payroll example is specific, but the principle applies to every place a general chatbot meets a regulated construction document. A schedule of values, a lien waiver deadline, a wage determination, a Section 3 benchmark: each is governed by an authoritative source and a mechanical rule, and each punishes a confident wrong answer. In all of them the same division holds. Use the model for what models are genuinely good at, reading messy inputs into clean structure and surfacing what a person should look at, and use deterministic logic against real sources for the part where being approximately right is the same as being wrong. A construction intelligence layer earns trust by knowing which half of a problem is which.
This is also why a system that can verify its own answers is worth more than one that merely sounds authoritative. A finding that cites the exact rule and the exact line it came from can be checked. An answer that arrives as a confident paragraph with no traceable basis cannot, and in a domain where you sign the result under penalty, an unverifiable answer is not an answer you can use.
Buildalytic is built on that separation. It uses strong models to read certified payroll and wage determinations into structured data, then audits that data against the governing determination and the jurisdiction's rules with checks that do not guess. When it does not have the determination for a project, it says so, because in compliance the honest gap is the safe answer.
