Specifications, RFIs, and Submittals: The Document Machine

Before automating specification writing it is worth being clear what a specification is, because treating it as descriptive prose is how practices get into trouble.

The drawings show quantity, location and relationship. The specification states quality: what the materials are, what standards they must meet, how the work is executed, and what the contractor must submit to prove it. Together they form the contract documents, and a contractor prices and builds from them.

That has a consequence people underestimate. Every sentence in a specification is potentially an obligation someone is paid to fulfil, and an ambiguity is not a stylistic flaw. It is a claim waiting to happen, or a cost the client pays twice.

Most offices work in a structured format, commonly MasterFormat in North America, which organises the work into divisions and sections with a consistent three-part structure: general, products, execution. That structure is what makes the document navigable to a contractor who needs one section at three in the afternoon.

And specifications come in kinds. A prescriptive specification names the product. A performance specification states the outcome the product must achieve and leaves the choice open. Which one you use is a design and risk decision, because a performance spec transfers selection responsibility to the contractor and a prescriptive spec keeps it with you.

None of that is a formatting concern. It is why a generated specification section cannot simply be adopted, and the next step is about what does work.

The workflow that works puts the tool after the decisions rather than in place of them.

What you supply. The system or product you have selected. The performance criteria it must meet. The standards you are invoking. The office master section, if you have one, as the format to follow. And the project-specific conditions that differ from your standard.

What comes back. A section in the correct three-part structure, in your office's language, with your criteria expressed consistently and the submittal requirements enumerated.

Why that is a real saving. Specification writing is largely the mechanical work of expressing decisions consistently across dozens of sections, and consistency is exactly what a tired human at the end of a project fails at.

The three checks that matter, and they are specific.

Invented standards. A model will produce standard designations that look right and do not exist, or that exist and cover something else, or that were withdrawn and replaced. Every standard cited gets verified against the issuing body, because a contractor cannot comply with a standard that is not real and will price the ambiguity.

Invented products. Manufacturer names, product lines and model numbers are generated fluently and are frequently wrong or discontinued.

And scope creep in the execution clauses. Generated text tends toward completeness, which in a specification means requiring things you did not intend to require. Every added requirement is a cost, and it is your client who pays it.

The general rule: the tool expresses your decisions. It does not make them, and it does not add any.

The most common documentation failure in the profession is not an error in either instrument. It is a disagreement between them.

The drawing says one thing about a finish; the specification says another. The schedule lists a door type the spec does not cover. A product named on a drawing was changed in the spec after a value engineering exercise and the drawing was never updated.

When the documents conflict, the contract usually has an order of precedence, and a contractor is entitled to price the ambiguity or claim for it later. Coordination failures are a significant source of change orders on real projects, and they are almost always the result of documents evolving at different rates under time pressure rather than of anyone being careless.

This is where language tooling has an unglamorous and genuinely valuable use, because it is a comparison problem at a scale humans do badly.

Given the drawing schedules and the specification sections, the task is to list every product, finish, standard and assembly mentioned in one and check whether it appears consistently in the other. That is tedious, mechanical, and exactly the kind of cross-referencing that gets skipped in the last week before issue.

Two cautions. A report that something is absent is the least reliable output, since establishing absence requires exhaustive coverage; treat any claimed omission as a lead to verify rather than a finding. And the tool produces candidate discrepancies, some of which are intentional differences it does not understand.

Still, a list of forty candidate conflicts of which twenty-five are real is far better than the current state, which is finding them during construction.

Submittal review is the highest-volume recurring task during construction, and it has a shape that suits assisted review well.

The contractor submits a product data sheet, a shop drawing or a sample, proposing what they intend to install. The design professional reviews it for conformance with the design intent expressed in the contract documents, and returns it approved, approved as noted, revise and resubmit, or rejected.

Where the tool fits is the comparison step in the middle. Given the submittal and the relevant specification section, it extracts each specified requirement and reports what the submitted product claims against it. That is a structured comparison across two documents, and doing it by hand for a fifty-page datasheet is where the hours go.

What it produces is a candidate list of conformances and deviations, which the reviewer then verifies.

What stays human is the judgement at the end. Whether a deviation matters is a design decision, not a comparison: a substitution that fails a stated criterion may still be acceptable, or may be unacceptable for a reason not written in the spec at all. And the stamp on the returned submittal is an act of review with liability attached.

The shape is the same as everywhere else in this cursus. The tool reads and compares. The professional decides and signs.

The request for information is the running conversation of a construction project, and it carries more risk than its routine appearance suggests.

A contractor asks a question because something is unclear, missing, conflicting, or impossible as drawn. The answer becomes part of the project record, and it can have cost and schedule consequences. Answer too slowly and you delay the work, which is a claim. Answer carelessly and you may have changed the design, directed the means and methods, or accepted a condition you did not intend to accept.

That middle one deserves emphasis. Design professionals are generally responsible for design intent, and contractors for construction means and methods. An RFI response that tells the contractor how to build something rather than what the design requires can shift responsibility in a direction nobody wanted.

Where assistance genuinely helps.

Finding the answer. Many requests are answered somewhere in documents that already exist, and locating the relevant drawing, detail or specification clause across a large set is a search problem.

Triage. Sorting incoming requests into already answered in the documents, needs a design decision, needs a consultant, and this is a change in scope. That sorting determines who does what next and is currently done by whoever opens the email.

Drafting the routine response, where the answer is a reference to an existing document.

What does not get automated. Anything requiring a design decision, anything with cost or schedule implications, and any response that would touch means and methods. And every response is read by a person before it goes, because it is going into the project record.

A large share of professional time goes into reading long documents produced by other people, and this is the least controversial win available.

What lands on a design professional's desk. Geotechnical reports. Consultant reports from structural, mechanical, acoustic, fire and facade specialists. Planning conditions and their attached obligations. Leases and development agreements with design implications. Local authority design guidance. Product literature. Existing building surveys and condition reports. Client briefs that are frequently long, internally inconsistent, and written by a committee.

Each of these has the same shape: mostly irrelevant to your immediate question, with a handful of passages that determine what you can do.

Assisted reading turns that into a shortlist. Ask what this geotechnical report implies for foundation selection and you get the relevant passages far faster than skimming.

The disciplines, which apply to all of them.

Read the passages it surfaces, not the summary of them. A summary of a geotechnical recommendation is not a substitute for the recommendation, and the qualifications in the original are usually the important part.

Treat claimed absences as unverified.

And watch for interaction. A planning condition three pages later can modify the one you are reading, and consultant reports frequently contain caveats in a different section from the recommendation.

The honest framing. You now read the ten pages that matter instead of skimming eighty. That is more coverage than most professionals previously had, not less, and it is a genuine improvement in care rather than a shortcut around it.

Anything numeric in this profession needs the same hard line drawn elsewhere in this catalogue, and it is worth being explicit about why.

A language model asked for a quantity, an area, a load, a U-value, a cost estimate or a schedule duration will produce a number. It will be formatted correctly and stated with confidence, and there is nothing on the page distinguishing a correct calculation from an incorrect one.

In a profession where numbers determine whether a structure stands, whether a project is affordable, and whether a client's budget is real, that is not an acceptable failure mode.

So the rule. Quantities come from the model of the building. Structural numbers come from analysis software and a licensed engineer. Thermal and energy numbers come from the calculation tool built for it. Costs come from a cost plan, a quantity surveyor, or real pricing. Programme durations come from the schedule.

The language tool explains those numbers, drafts the narrative around them, and reformats them for a client. It does not produce them.

The one genuinely useful numeric adjacency is extraction rather than calculation: pulling numbers out of documents into a structured table, checked against the source. That is a reading task with a verifiable output, and it is different in kind from computing a value.

And a related caution about anything that looks like a calculation in generated prose. A model will sometimes show working, which is persuasive and does not make the result correct. Reasoning presented in steps is still generated text, and an arithmetic slip inside a plausible derivation is exactly the error nobody catches.

Each document type fails differently, so a single generic check catches none of them. The specific ones.

Specification sections. Every standard verified against the issuing body. Every product and manufacturer verified as real and current. And a scan for requirements you did not intend, since generated text drifts toward completeness and every added requirement is a cost your client pays.

Drawing and specification cross-checks. Treat the output as candidate conflicts, not findings. Treat claimed omissions as leads. Expect intentional differences to be flagged as errors.

Submittal comparisons. Verify each claimed conformance against the actual datasheet, and make the does-this-deviation-matter call yourself, because a spec-compliant product can still be wrong for reasons the spec never stated.

RFI responses. Check that the answer references the documents rather than inventing a new requirement, and specifically that it has not strayed into means and methods.

Document reading. Read the surfaced passages, not the summary. Watch for caveats in other sections.

Anything numeric. It came from the tool built for it, or it does not go out.

What unifies all of these is the seal from lesson one. Everything above is preparation, comparison and drafting, and each check exists to convert an unverified draft into something a licensed person is willing to stand behind. That conversion is not overhead attached to the work. It is the work, and it is what the licence is for.