Knowledge / AEC-native data
Employer's requirements
The client's statement of scope, performance and quality requirements under a design and build contract, against which the contractor's proposals are measured.
The Employer's Requirements are the client's side of a design and build contract: scope, performance, quality standards, deliverables, the approvals procedure, and the design the client has already done for the contractor to complete. An employer's requirements AI has to read each requirement in its place, because the ERs arrive as narrative, tables, appendices and incorporated documents, and a requirement's force depends on where it sits. They go out with the ITT, are answered by the Contractor's Proposals, and become a contract document read with the proposals, usually under a bespoke order of precedence; after that, changing them is a variation. Structured knowledge makes the ERs something the precon team can question, with each answer traceable to the paragraph, the appendix and the proposal that responded to it.
What teams need to ask of it
Which requirements in the ERs do the Contractor's Proposals not answer, or answer with a qualification?
Which requirements are performance-based and which prescribe a product, a system or a standard?
What is the client's approval procedure for design information, and what does it treat as deemed approved?
Which drawings, specifications and reports are incorporated into the ERs, and at which revision?
What design responsibility do the ERs pass to the contractor, and which consultants are to be novated?
Which appendices have been superseded by an addendum or a post-tender clarification?
Which requirements would become a variation if the client's brief changed, and which are already covered by the proposals?
Why generic AI gets it wrong
A requirement in the ERs carries different weight depending on where it sits. A sentence in the preamble saying the building "should achieve an excellent standard of sustainability" is not the same as a scheduled requirement for a named rating under a named assessment method, and neither is the same as a clause in an incorporated specification. Flatten the document into text and the three read alike. The appendices are where most of the substance lives, and they are separate files with their own revisions, so a text reader sees a reference to Appendix F without seeing Appendix F, or sees an old Appendix F that the addendum replaced.
The larger problem is precedence. The ERs do not stand alone; the Contractor's Proposals answer them, sometimes qualify them, and the contract, where it has been amended to say so, states which document prevails when they disagree; the unamended form is often silent. A generic tool reading the ERs reports a requirement as binding without knowing that the proposals qualified it and the contract lets the proposals prevail, or reports a proposal as agreed without knowing the ERs override it. Either way the commercial team gets a fluent statement of an obligation that is not the obligation in the contract. It reads like the contract, which is the problem: a reader in a hurry acts on it, and the argument about what was agreed surfaces at final account.
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
The ERs are issued as part of the tender packs and ITT documents, become one of the construction contracts (NEC, JCT, FIDIC) on execution, and incorporate construction specifications and drawings by reference. Tender document review starts from them when the pack is being assembled or priced, and contract obligation extraction returns to them after award, reading the ERs, the proposals and the conditions as one set of obligations.
Does it read the Contractor's Proposals alongside the ERs?
What about the appendices and incorporated documents?
How do we see it on our own ERs?
Related pages
Tender packs and ITT documents
The invitation to tender and its enclosures: employer's requirements, drawings, specifications, pricing documents, conditions and returnable schedules.
Construction contracts (NEC, JCT, FIDIC)
The conditions of contract, particulars, amendments and schedules that define obligations, risk allocation, notices and payment between the parties.
Construction specifications
The written performance and prescriptive requirements for materials, workmanship and systems, organised by work section (NBS, CSI MasterFormat, Uniclass).
Tender document review
Reading the full tender pack within the tender window to surface scope, risk, contradictions and qualifications before pricing is committed.
Contract obligation extraction
Extracting obligations, notice periods, risk allocations and deliverables from the executed contract into a structured register the project team can act on.