Knowledge / AEC-native data

Construction specifications

The written performance and prescriptive requirements for materials, workmanship and systems, organised by work section (NBS, CSI MasterFormat, Uniclass).

The specification is where the project's requirements are actually written down: the performance a system has to achieve, the products that are acceptable, the standards workmanship is held to, and the evidence required to prove it. It arrives as hundreds of pages organised by work section, referencing standards and drawings that live elsewhere, and it is amended at tender by addenda and after award by instructions, re-issues and RFI responses. Most teams read the clauses they need and trust the rest. Structured knowledge makes the whole document something a team can question, clause by clause, with every answer traceable to its source.

What teams need to ask of it

  • Which clauses govern this product, this system or this trade, across every work section that touches it?

  • Is the requirement performance-based or prescriptive, and which standards does it invoke?

  • Which clauses have been changed since tender, by which addendum, instruction, re-issue or RFI response?

  • Where does the specification contradict the drawings, the schedules or the employer's requirements?

  • What evidence does the specification ask for: certificates, samples, test results, warranties?

  • Which clauses carry a design responsibility that has been passed to the contractor or a specialist?

  • What is still marked to be confirmed, or left blank, in the issued revision?

Why generic AI gets it wrong

A specification is not a narrative. It is a set of numbered clauses whose meaning depends on the hierarchy they sit in: the preliminaries, the work section, the system clause, the product clause, the execution clause, and the standards each of them pulls in by reference. Flatten that into text and the structure goes, so a model cannot tell whether a tolerance belongs to the render or the blockwork behind it, or whether a requirement applies to the whole system or to one component.

The second problem is that the specification is never the latest word. Requirements move through addenda at tender, then instructions, re-issued sections and RFI responses that live in other documents. A model handed the specification alone will quote a clause that was superseded weeks ago, confidently and with the right clause number. And because the answer reads like the document, nobody checks. The failure is not a wrong fact but the right fact from the wrong revision.

One question, answered

QUESTION

ANSWER

SOURCES

See it on your data.

See it on your data.

We onboard a focused slice of your project data, configure the ingestion paths, extract a structured context graph, and build a workflow against the resulting structured knowledge layer.

Related to

The specification is the reference point for almost everything else on the project. Drawings and schedules show where its requirements apply, submittals are raised against its clauses, RFIs clarify it, and the tender pack is where it first appears. The specification-to-drawing consistency check and submittal review both start from it.

Frequently asked questions

Frequently asked questions

Which specification formats does this apply to?

Does it handle amendments and addenda?

Can it tell us where the specification and the drawings disagree?

Related pages