Basis-of-design is one of those documents every firm produces and almost no firm produces the same way twice. The design criteria — loads, redundancy, setpoints, code references, the assumptions everything downstream rests on — get written under deadline, by whoever has the file open, from memory and whatever the last similar project happened to say. Each one is defensible on its own. Lined up next to each other, they drift.
For a single project, the drift is invisible. Across several projects for the same client, it isn't — and that's exactly where it costs you. The client starts to notice that the firm documents the same kind of decision three different ways, and the quiet impression forms that nobody's quite holding the standard.
Here's how to think about keeping it consistent without turning documentation into a chore nobody has time for.
Why it drifts in the first place
It helps to be honest about the cause, because it isn't carelessness:
- Different authors, same document. Two competent engineers will document the same criteria with different structure, different emphasis, and different defaults — unless something keeps them aligned.
- Deadline pressure. Basis-of-design is rarely the billable star of the project. It gets done quickly, often by copying the nearest previous one, which propagates whatever that one happened to say.
- No single standard that's easy to follow. Most firms have a standard somewhere, but if following it means remembering it, it won't be followed consistently.
None of that is a discipline problem. It's a structure problem, and structure problems are fixable.
Consistency is a documentation problem, not a design problem
The important distinction: the goal is not to standardise the design. Two projects should reach different criteria when the requirements differ — that's the engineering. The goal is to standardise how the criteria are captured and checked, so that two engineers documenting the same decision produce comparable records, and a decision that falls outside your standard gets noticed.
That splits the work cleanly:
- The judgment — what the loads should be, how much redundancy, which code governs — stays entirely with the engineer.
- The routine — capturing those decisions in the same shape every time, and flagging where they diverge from your standard — is the part worth handling for them.
What "checking against the standard" actually looks like
The most useful thing a tool can do here isn't writing the basis-of-design — it's catching the parts that don't line up:
- A criterion that falls outside the range your firm normally uses, surfaced for a second look.
- A required section that's missing, before the document leaves the office.
- A requirement from the brief that the basis-of-design never actually addressed.
- A divergence from how the same client's previous projects documented the same thing.
In every case the tool's job is to flag, not to decide. The engineer looks at the flag and either fixes it or confirms it's a deliberate, correct difference. What you get is fewer things slipping through — and a clearer record of how each design meets its requirements.
Built on your standards, not a generic template
A consistency check is only useful if it's checking against your way of working. Built on your own design standards and past project documentation, it reinforces the conventions your firm already holds. Built on a generic template, it just imposes someone else's conventions and creates friction. The point is to make your standard easy to follow — not to replace it.
Keep the engineer in charge
This is the throughline in everything we build: the routine, error-prone part gets handled, and the judgment stays with the person. A basis-of-design tool that quietly "corrected" criteria would be worse than useless — it would launder a machine's guess into an engineering decision. The right version documents consistently, flags divergence, and leaves every actual decision to the engineer.
Where Honewright fits
Consistent basis-of-design is one of the workflows we build for directly: documenting design criteria the same way every time, checking decisions line up with your standard, and keeping things consistent project to project and client to client. Less drift, less rework, a clearer record of how the design meets its requirements — built on your own standards, and kept in Canada.
If your basis-of-design documents would embarrass you a little lined up side by side, tell us what's eating your time and we'll tell you honestly what it would take to fix.