Knowledge / AEC-native data
Submittals
Contractor-issued product data, shop drawings and samples submitted for review against the specification before procurement or installation.
A submittal, a technical submission on many UK jobs, is the contractor's proof that what it intends to procure and install matches what the specification and drawings require. Product data, shop drawings and samples arrive as loose PDF packages, and the reviewer has to reassemble the chain by hand: which specification clauses govern this product, which drawings and schedules show where it goes, and what the last revision said. Structured knowledge turns that package into something a team can question directly, with every answer traceable to its source.
What teams need to ask of it
Which specification clauses does this submittal have to comply with, and does it address all of them?
Does the product on the data sheet match what is scheduled on the drawings, item for item?
What changed between this revision and the one we returned with comments?
Is this product being submitted against the right section, or has it been filed under the wrong package?
Which other submittals, RFIs or variations touch the same element?
Has the manufacturer's certification been checked against the performance the specification actually asks for?
What is outstanding across the whole submittal register, by section and by trade?
Why generic AI gets it wrong
A submittal package is several documents pretending to be one. A transmittal sheet, a manufacturer's data sheet written for every project in the world, a highlighted page or two, a shop drawing with its own title block, and the Status B comments from the last round. A general-purpose model reads the whole thing as one flat run of text and loses the structure that carries the meaning: which page is the contractor's proposal and which is boilerplate, which highlighted value is the one being offered, which revision is current.
The harder problem is that the answer is never inside the package. Compliance is a relationship between the submittal, the specification clause it was raised against and the drawings that show where the product is used. A model that has only been handed the PDF will confidently declare a product compliant because the data sheet says the right words, without ever checking the clause, the schedule or the fire rating on the door it is going into. The failures are quiet: a plausible summary, no source, and a review response that reads well and is wrong.
One question, answered
QUESTION
ANSWER
SOURCES
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
A submittal is raised against a specification section and answers to the drawings and schedules that call for the product. Its history runs through the RFIs that clarified the requirement and the variations that changed it, and the review itself is a workflow of its own.
Can AI review a submittal without the specification?
What does traceable to its source mean for a submittal?
Does this replace the reviewer?
Related pages
Construction specifications
The written performance and prescriptive requirements for materials, workmanship and systems, organised by work section (NBS, CSI MasterFormat, Uniclass).
Construction drawings
The 2D graphical record of design intent: plans, sections, elevations, details, schedules and title blocks, issued as sheets with revisions.
RFIs
Formal requests for information raised during construction to resolve ambiguities or conflicts in the drawings and specifications, with their responses.