By tool
ChatGPT and building codes: verify the source before using the rule
A plausible clause number is a research lead. A usable requirement needs the actual source, the applicable edition and the project facts that trigger it.
Contents · 7
Start with a question the source can answer
An architect checking an access route may ask a chat assistant for a minimum clear width. Before using a number, define the building use, project location, stage, relevant authority and route function. Requirements for one type of route may not answer the question for another.
Use ChatGPT to structure the research: identify missing project facts, organize supplied documents and draft a requirement register. The deliverable is a path back to evidence, not a persuasive paragraph about what is “usually required.”
Avoid asking for a global code answer. Countries, local authorities and adopted editions differ. Contract standards and client requirements may add obligations, while existing-building work may follow a different approval route from new construction.
Distinguish five possible errors
A reference can fail even when its title is real. Check each of these independently:
- The document exists, but the clause does not.
- The clause exists, but the wording or threshold is misquoted.
- The quote is accurate, but an exception or definition changes its meaning.
- The source is current generally, but a different edition applies to this project.
- The source applies somewhere else or to a different building condition.
A hyperlink alone settles none of these. Open the document, locate the relevant passage and read its surrounding definitions, notes and cross-references. For a table, retain headings and footnotes; an isolated cell can lose the condition that makes its value meaningful.
Ask for evidence before interpretation
OpenAI’s accuracy guidance identifies fabricated references as a possible error. Search can find real documents, but the returned edition and passage still need inspection. A confident answer and a familiar document title are insufficient checks.
Anthropic’s guidance on reducing hallucinations recommends grounding answers in supplied text and allowing uncertainty. In a project workflow, ask for the passage before the conclusion and permit an explicit “not found in these sources.” Test the process with a question the supplied documents do not answer; it should expose the gap rather than manufacture a clause.
Build a compact requirement record
For each proposed requirement, keep a source title, issuing body, edition, clause or table, exact short quotation, applicability facts and a reviewer’s status. Distinguish authoritative wording from the assistant’s explanation. If the source is a translation, record whether it is an official edition or an explanatory aid.
| Field | Example of useful content |
|---|---|
| Question | Clear width at a defined route segment |
| Source | Publisher or authority document link and edition |
| Passage | Clause, table row and relevant notes |
| Project facts | Use, route type and relevant dimensions |
| Conclusion | Confirmed, unresolved or not applicable |
| Action | Survey, clarification or design review |
Do not fill gaps with a remembered threshold. A visible “source not established” keeps the research actionable and stops an unsupported number spreading into drawings and specifications.
Worked example: compare two supplied passages
Suppose the project team has an adopted code extract and a client access brief. Both discuss circulation, but they use different terms. The task is to identify whether they address the same condition and what needs clarification, rather than choosing whichever width is larger without analysis.
Using only the two supplied documents, compare requirements for the identified route. Quote the relevant short passages with page and clause references. Preserve units and defined terms. Separate source wording from explanation. List exceptions, unresolved applicability facts and any conflict requiring the project reviewer’s decision. If a requirement is absent, say so.
Check every quotation against the original. Then ask the relevant reviewer to resolve scope and conflicts. Where a drawing measurement is needed, record its endpoints and units separately from the required threshold. A measured width and an applicable minimum are different pieces of evidence.
Know what the file route actually reads
A scanned code extract may contain no selectable text. A table may become detached from its footnotes during extraction. Verify the passage the assistant received before evaluating its reasoning.
OpenAI’s PDF input documentation explains how supported API models receive text and page images. For a particular ChatGPT workflow, check its current file-handling documentation and test a known passage rather than assuming all uploads behave identically.
Record the date of research and retain the reviewed source version according to your project’s document rules. If the publisher updates the document, revisit affected requirements; an old chat response does not update itself.
Keep the result useful to the design team
Return a short conclusion plus the requirement record and open actions. Avoid burying unresolved applicability beneath a long narrative. The next person should be able to open the passage and understand why it was considered relevant.
Bring one drawing-evidence task to ARAI: inspect DWG/DXF geometry and report a specified distance or bounded area, with units and object identifiers. Compare that measurement with the applicable requirement from your separately verified project sources.
Prepare a measurement request in ARAI. Review the draft, attach the drawing and name the objects before sending.
Ask ARAI about your project
Prepared by ARAI’s editors with AI assistance. Product information was checked against official sources as of the update date. Report an error at hello@arai.build.