AI for Specifications

A specification is one of the most templated documents in practice. Systems like CSI MasterFormat and UniFormat in North America, NBS in the UK, NATSPEC in Australia and CPWD specifications in India all exist precisely because spec text is standardised, sectioned and reused. Each section follows a predictable rhythm - scope, referenced standards, products, execution, quality - filled with the same phrasing project after project. That regularity is what makes it slow and tedious for a human and effortless for an LLM: pattern-rich, prose-heavy, low on genuine invention.

So the upside is real and immediate. You can ask an LLM to convert a rough intent into properly structured spec language, to adapt a section from one project to another, to reconcile the tone of clauses written by three different people, or to explain what a dense clause actually requires. Used this way it removes drudgery, not judgement.

The danger is the flip side of the same coin. Spec language sounds authoritative even when it is wrong, and an LLM is a fluent generator of authoritative-sounding text. It will happily write to comply with IS 4671 or ASTM C1048 Class 2 whether or not that standard exists, is current, or is the right one - because it is predicting plausible spec prose, not checking a database. A hallucinated product code or a withdrawn standard reads exactly like a correct one. The spec is where the course's rule - scrutiny scales with the stakes - reaches its maximum: this document is as high-stakes as it gets.

None of this is an argument against using AI on specifications. It is an argument for a specific shape of use: let the model do the mechanical, prose-heavy labour it is genuinely good at, and never let it be the source of a fact. Once you internalise that split - fast on the wording, immovable on the truth - specs become one of the biggest, safest time savings in your whole week. The rest of this lesson is simply how to hold that line reliably, every time, without slowing back down to hand-writing speed.

The best AI spec workflow almost never starts with an open-ended prompt. It starts with your known-good material. Paste in your office master spec section, a previous project's approved spec, or a manufacturer's validated text, and ask the LLM to adapt it to this project - not to write one from scratch. This single move changes everything: instead of the model inventing content from its training data (where hallucination lives), it is transforming text you have already vetted. The facts come from you; the LLM does the editing labour.

This is a lightweight form of what the course calls grounding - giving the model the source material to work from rather than relying on its memory. In more advanced setups (Module 8) you can wire a whole spec library into a retrieval-augmented custom assistant, but you do not need any of that to start. Copy-paste is grounding. A shared project folder of approved sections is grounding.

Be deliberate about what you feed it. Give it the room or element it is specifying, the performance requirements, the selected products with their real model numbers, the relevant local standards you have already confirmed, and the house style. Then it has everything it needs to draft well and little reason to fabricate. Contrast that with a bare write me a spec for external glazing - a prompt that forces the model to guess your products, your standards and your climate, and guess it will.

Weak:  "Write a specification for the external timber cladding."
Better: "Here is our office master section for timber cladding [paste].
         Adapt it for THIS project: species is thermally-modified ash,
         open-jointed rainscreen, coastal exposure, 20mm boards.
         Keep our clause numbering and house style. Mark anything
         you are unsure about with [VERIFY] instead of guessing."

A few habits make LLM spec drafts far more useful and far safer. First, ask for placeholders, not guesses. Instructing the model to insert [VERIFY] or [TBC - confirm standard] wherever it is unsure turns its biggest weakness - confident fabrication - into a visible to-do list. A draft peppered with honest [VERIFY] tags is worth ten that read as finished but hide three invented codes.

Second, separate drafting from fact-supplying. Let the model handle structure, phrasing and completeness; keep the facts (products, figures, standards) as things you provide or confirm. A good pattern is to ask it to draft the section and produce a companion list of every product name, standard number and performance figure it used, so you can check them in one pass.

Third, use it to interrogate, not just to write. Some of the highest-value spec uses are analytical: read this spec section and my drawings and list any contradictions; what have I forgotten to specify for this assembly?; rewrite this clause in plainer language so I can check it says what I mean. These lean on the model's strength (pattern-matching across long text) while leaving the truth-judgement with you.

Strong follow-up prompts:
  "List every standard number and product code you used above,
   as a table, so I can verify each one."
  "Compare this drafted spec against the attached drawing notes
   and flag any conflicts or gaps. Do not fix them - just list them."
  "Rewrite clause 2.3 in plain English so I can confirm intent,
   then give me the formal version back."

Notice that none of these ask the model to be right about the world. They ask it to organise, compare and rephrase - and then hand the verdict back to you.

No AI-drafted spec leaves the office unread. Build a fixed verification gate and run every section through it, the same way every time. The essentials: does every named product actually exist and is it the one you selected? Is every standard current - not superseded or withdrawn (in India, for instance, several familiar codes have been revised, and NBC 2016 has been superseded by SP 7:2026)? Do the clauses match this project rather than a generic template left half-adapted? Is there any contradiction with the drawings, the schedule or another spec section? Are performance figures and tolerances correct? And the embarrassing one: has any `[VERIFY]` or `[TBC]` been left in by mistake?

The reason to be this disciplined is liability, not perfectionism. A specification is a contract document. A confident-wrong clause does not stay on a screen - it gets priced, ordered and built, and unwinding it costs real money that lands on someone, quite possibly you and your professional indemnity cover. The LLM carries none of that responsibility. You sign the document; you own every word in it.

A practical tip: verify against sources, not against the model. If you are unsure whether IS 2645 is the right waterproofing standard, do not ask the LLM to confirm - it will often just agree with you. Check the standard itself, or your firm's validated master. The model is excellent for surfacing what to check and hopeless as the authority that settles it.

Speed at drafting only pays off if the rest of your spec discipline holds. Coordination is where AI can quietly help and quietly hurt. It helps when you ask it to cross-check consistency - the same product named the same way everywhere, drawing references that match, no clause specifying a finish the drawings do not show. It hurts when a fluent draft lulls you into skipping the coordination you would have done on a hand-written spec. The output looks finished, so it feels finished. It is not finished until you have made it yours.

Keep your firm's voice and structure. If your practice writes tight, performance-led specs, tell the model that and hold it to the standard; generic AI prose tends toward the bloated and the hedged. Trim it. A spec is judged on precision and enforceability, not word count.

Finally, think about confidentiality. Specs can contain client and project detail you should not paste into a consumer chatbot that may train on it (Module 9 goes deeper). Prefer tools with a business or no-training setting, or strip identifying detail before you paste. Treat the AI as a capable junior you would not hand confidential files to without thinking. One more habit pays off over time: keep a short, reusable prompt that encodes your house rules - use my pasted master section, keep my numbering, flag uncertainty with [VERIFY], list every code and product used - so every spec you draft starts from the same disciplined footing rather than a fresh improvisation. That small piece of standardisation is the bridge to the prompt libraries and custom assistants of Module 8.

Do all this and specifications become one of the clearest wins in the whole course - hours saved on drudgery, quality held or improved, and you firmly the author of a document you can defend line by line.