Skip to content

Design basis (also: Basis of design)

Last reviewed:
The documented set of requirements, criteria, codes, site data and assumptions from which a design is developed — the premises of the project, written down.

Every design answers to something: the owner's functional requirements, the governing codes and their editions, the site's climate, geotechnical and utility data, capacity and performance targets, and the assumptions standing in for facts not yet known. The design basis is that material captured as a controlled document at the start of design, so that a thousand subsequent decisions are made against the same premises.

Usage varies, and the variation is worth knowing. Many organisations use design basis and basis of design interchangeably. Others split them: the design basis as the owner's statement of requirements and constraints, and the basis of design as the designer's response — the document recording which systems, standards and approaches were selected to meet those requirements, and why. On a project where both documents exist, confusing them means confusing the question with the answer.

The document fails by standing still. Assumptions get resolved, criteria get renegotiated, codes get updated — and if the basis is not revised with them, the project ends up with disciplines designing to different premises, each of them traceable to an edition of the truth. An out-of-date design basis is worse than none, because it is authoritative and wrong.

See this workflow in practice.

Book a demo to see how Armeta applies this concept across the drawings, standards, specifications, and project data that define the work.