Writing Material Specifications

A specification is a written contract document. Alongside the drawings it defines the quality of the work: it names materials and products, sets grades and finishes, references the standards a material must meet, and describes how it is stored, prepared, installed and tested. On a well-run project the drawings say where and how big, and the specification says what and how good. When a client disputes a floor that has cupped or a paint system that has failed, the specification is the document that decides who pays.

That is why specification writing rewards two qualities at once: rigour and consistency. Every clause must be correct, and the whole document must speak in one voice, use terms the same way throughout, and leave no gap a contractor can exploit. Doing that by hand, section after section, is slow and error-prone - which is precisely the profile of work Claude accelerates. It never tires of boilerplate, it keeps terminology consistent across forty clauses, and it remembers the standard sub-headings a rushed junior drops.

So the division of labour is clear and it never changes. Claude drafts; you decide and verify. You bring the design intent - the actual material, the performance you need, the context of this project - and Claude turns it into a properly structured, properly worded section fast. Then you read it as the professional whose seal goes on it, checking every factual claim against a real source. Think of it as handing a superb junior your marked-up notes and getting back a typed, ordered draft: enormously useful, and worthless if it goes out unread.

The payoff is real. A section that took an afternoon of copy-pasting from an old project can take twenty minutes: ten for Claude to draft, ten for you to verify and correct. But the twenty minutes only works if the ten minutes of checking is real checking - which is the skill the rest of this lesson builds.

The fastest way to a good draft is to give Claude the structure you want, not to hope it guesses. Most specifications follow a three-part logic for each work section, and it is worth teaching Claude yours explicitly. The widely used pattern is: Part 1 - General (scope, related sections, submittals, samples, references, quality assurance, delivery and storage, warranties); Part 2 - Products (materials, manufacturers or approved equivalents, grades, finishes, accessories, mixes); and Part 3 - Execution (examination, preparation, installation, tolerances, testing, cleaning, protection). Whether you use that convention, an SBC/NBSG-style layout, or your own office template, name it in the prompt.

A strong prompt looks like this:

Act as a senior architect writing a material specification section for an
Indian project. Draft the section for external wall cladding in fibre-cement
board. Use a three-part structure: PART 1 GENERAL, PART 2 PRODUCTS, PART 3
EXECUTION. Under each, use the standard sub-headings. Leave any grade,
standard number, or test value I must confirm as [VERIFY: ...] rather than
filling it in. Match the clipped, imperative tone of a contract spec.

Two moves in that prompt matter enormously. First, the explicit structure gives you a complete, consistent skeleton every time. Second - and this is the single most valuable habit in the whole module - you instruct Claude to flag anything factual it would otherwise invent as [VERIFY: ...]. Instead of a confident but fabricated "IS 14862", you get [VERIFY: fibre-cement board standard number], which is an honest to-do list rather than a landmine. It turns Claude from a source of plausible facts into a structurer of your facts.

Use a Project to make this repeatable. Load your office's specification template, your preferred clause library, and a custom instruction that says "always use our three-part structure and always mark unconfirmed data as [VERIFY]". Every spec chat then starts already knowing your house style, and the drafts come back closer to signable. Keep the specimen tight: give Claude a real, correct past section as an example and it will match its rigour far better than any description can.

Here is the failure that will cost you if you let it. Ask Claude for a concrete specification and it may cheerfully write "concrete shall be grade M30 conforming to IS 456:2000, with minimum cement content of 320 kg/m3 and maximum water-cement ratio of 0.45". Every part of that reads correct. Some of it may be correct. But Claude did not look it up in IS 456 - it predicted the most plausible string of characters, and standard numbers, clause references, grades and numeric limits are exactly where plausible and true come apart. It can cite a withdrawn code, transpose a figure, attach the right-sounding number to the wrong material, or invent a standard whole.

Treat every one of the following as unverified until you confirm it against the actual source: standard and code numbers (IS, ISO, ASTM, EN, NBC clauses); grades, classes and designations; numeric limits (strengths, thicknesses, tolerances, fire ratings, U-values); product names, model numbers and manufacturer data; and any "conforming to" or "tested to" claim. The rule is blunt and non-negotiable: Claude may draft the sentence, but the standard and the number in it are yours to prove.

How you verify depends on the claim. For a code or standard number, check the issuing body - the Bureau of Indian Standards for IS codes, the National Building Code for building provisions, the manufacturer's current technical data sheet for a product. Note that Claude's training has a cutoff and, without live web access, it will not know a standard was revised or withdrawn last year; a number that was right in 2019 may be wrong now. This is where a designer's judgement is irreplaceable - you know which claims are load-bearing and must be checked hardest, and which are boilerplate.

A useful discipline: after Claude drafts, ask it to "list every standard number, grade and numeric value you used in that section, as a checklist, and mark which you are confident about and which I should verify". It will surface its own factual claims into one table you can walk through against sources. It cannot tell you which are true - but it can gather them so none slips past you unread.

Put it together into a loop you run for every section. One: brief. Give Claude the design intent, the material, the performance you need and the context, and tell it the structure and the [VERIFY] rule. Two: draft. Let it produce the full section as an Artifact so you can edit it in place rather than re-pasting. Three: harvest the facts. Ask for the checklist of every standard, grade and number. Four: verify. Confirm each factual claim against BIS, the NBC, or the manufacturer's current data sheet, correcting the draft as you go. Five: read for the professional. Now read the whole thing as the person who signs it - is the scope complete, the tone contractual, the terminology consistent, are there gaps a contractor could exploit? Six: keep the good clauses. Save verified, corrected sections back into your Project so the next draft starts better.

Two honest cautions. First, decide the specification type yourself: a prescriptive spec names exact products and grades and puts the performance risk on you; a performance spec states the outcome required and lets the contractor propose how to meet it. Claude will happily write either, but which is right for this clause, this client and this procurement route is a professional decision, not a drafting one. Second, a beautifully written spec can still be the wrong specification - fluency is not correctness. Claude makes bad specs read as well as good ones, so your judgement matters more, not less.

Done this way, Claude gives you back hours per project and, just as valuably, a more complete document - because it does not forget the storage clause or the testing sub-head the way a tired human at 9pm does. You supply the design intent, the verified facts and the accountability; Claude supplies the speed and the structure. That is the whole bargain, and it is a good one - as long as you never, ever let the standard or the number go out unchecked.