The Office Master Specification: A Technical Director's Guide
How UK practices build, own and maintain an office master specification: what goes in it, who controls it, how it stays current, and how every project spec gets checked against it.
What an office master is
An office master specification is a practice's own edited version of a commercial master. It records the decisions the practice has already made: the systems it prefers, the products it trusts, the wording it uses, the preliminaries it issues, and the clauses it has learned to leave out.
It sits between two other documents. Above it is the commercial master, such as NBS content arranged by CAWS or Uniclass 2015, written by specialists to cover every reasonable option. Below it is the project specification, which selects from the office master and adds what the project needs. The commercial master tells you what could be specified. The office master tells your teams what this practice specifies. The project spec says what this building gets.
Each layer narrows the one above it. The office master is where the practice's judgement lives.
A good office master makes the next spec faster and the one after that more consistent. A neglected one does the opposite: it quietly copies old standards, discontinued products and last decade's prelims into every new job.
Who should own it
Every office master needs a named owner, usually the technical director or the practice's lead specifier. Ownership means three things: deciding what goes in, approving what changes, and answering for its quality when a project spec goes wrong.
Most masters fail on ownership, not on content. The pattern is familiar. Someone builds the master carefully, then moves on to projects. Teams start copying the last job's spec instead because it feels more current. Within two years the master is out of date and nobody trusts it, so nobody uses it, so nobody updates it.
One owner, a small group who propose, and everyone else drafting from what was approved.
Give the owner time, not just the title
Ownership without hours is decoration. Allocate the owner a fixed review slot, even half a day a month, and treat master maintenance as fee-earning work that protects every future project. Practices that do this find the master stays useful; practices that don't are back to copying old jobs within a year.
What goes in it
An office master is more than a set of clauses. It is every reusable decision a spec writer would otherwise have to make again on each project.
| Content | What it records | Example |
|---|---|---|
| Preliminaries | The practice's standard A-section clauses, by contract form | A30 to A37 set up for JCT Intermediate and JCT Design and Build |
| Preferred systems | Default build-ups the practice has resolved and detailed | K10 plasterboard linings, H21 rainscreen, M60 intumescent coatings |
| Preferred products | Products the practice trusts, with the evidence behind them | A named membrane with current BBA certificate and DoP |
| House style | Wording rules applied to every clause | "shall" not "must"; never "or equal approved" |
| Prescription level | How much to name products vs. specify performance | No proprietary names in Systems clauses on public work |
| Numbering | Clause numbering and structure conventions | /1 Prelims, /2 Systems, /3 Performance, /4 Execution, /5 Completion |
| Exclusions | Clauses the practice has decided never to use | Options that caused disputes on past jobs |
| Guidance notes | Why a decision was made, for the next writer | "Specify Class A2 here on residential over 11 m; see AD B" |
The guidance notes matter more than most practices think. A clause without its reasoning gets edited by the next person who doesn't know why it says what it says. A clause with a one-line reason survives.
Locking and approval
Not every clause deserves the same protection. Treat the master in three tiers, and tell project teams which tier each clause sits in.
Lock the clauses where a well-meant edit creates liability. Leave the project-specific parts open.
The approval route
- Propose. A contributor or project team flags a clause that should change, with the reason and evidence.
- Review. The owner checks it against current standards and the practice's past decisions.
- Decide. Accept, reject or adapt, and record why.
- Publish. Issue a new version of the master with a short note of what changed.
The point of the route is not bureaucracy. It is that every change to the master is deliberate, visible and reversible, so teams can trust what they draft from.
Keeping it current
A master goes stale in five predictable ways. Watch for each one and give it a trigger, so updates happen when something changes rather than when someone remembers.
| Trigger | What to do |
|---|---|
| A standard is revised or withdrawn | Update every clause that cites it and note the edition change |
| An Approved Document is amended | Review affected Performance clauses, especially fire and energy |
| A product is discontinued or its data changes | Replace or re-verify the product and its evidence |
| A certificate lapses | Remove the reference until a current certificate is confirmed |
| A site lesson or RFI exposes a weak clause | Rewrite it and add a guidance note explaining why |
Each trigger runs through the same route, and every published version feeds the next round of projects.
Alongside the triggers, set a full review once a year. Read the master end to end, delete what nobody has used, and check that every guidance note still holds.
Rolling changes out to live projects
When the master changes, live projects don't all follow automatically. Whether a project adopts a change depends on where it is in the RIBA Plan of Work and what has already been issued.
| Project stage | Adopt the change? | How |
|---|---|---|
| Stages 2 to 3 | Yes, by default | Update the draft spec when the new master version is published |
| Stage 4, before tender | Yes, if it affects compliance or risk | Owner and project lead agree; record it in the spec revision notes |
| After tender issue | Only through change control | Treat it as a design change with cost and programme assessed |
| Stage 5 onwards | Rarely | Only where safety or compliance requires it; instruct formally |
| Issued records | Never | Issued revisions stay as they were; the record shows what was current at issue |
The rule that protects you is the last one. A specification issued for tender or construction is a record of what was required at that moment. Never let a master update silently rewrite it.
Checking each spec against the master at issue
The master only protects the practice if project specs actually follow it. Before each issue, run a short gate against the master as well as against the drawings.
- Every locked clause appears unchanged, or the owner has approved the change in writing.
- Every departure from a preferred system or product has a recorded reason.
- No clause cites a standard edition or product the master has since replaced.
- House style rules hold throughout: no banned phrases, consistent numbering.
- Preliminaries match the contract form actually being used on the project.
- Any improvement found on this project is sent back to the owner as a proposed master change.
The master is only as good as the last spec that was checked against it.
A static master vs. one enforced while drafting
Most UK practices keep their office master inside their specification software as a set of template clauses. That works when someone remembers to start from it and keeps it maintained. Its limit is that the master is copied in at the start and then left behind: nothing checks a project spec against it as the spec develops.
| Static template master | Master enforced while drafting | |
|---|---|---|
| Starting a spec | Copy template clauses into the project | Spec is drafted from the project drawings with the master applied |
| House style | Relies on the writer remembering it | Rules applied to every clause as it is written |
| Departures | Visible only if someone compares documents | Flagged against the master as they happen |
| Superseded standards | Found at the annual review, if at all | Flagged in live projects that cite it |
| Who can change it | Anyone with edit access to the template | Set per practice |
Avoice treats the office master as part of how a spec is written, not just where it starts. Practice Voice holds the practice's approved clauses, section templates and preliminaries in one versioned library, applies house rules to everything the spec agent drafts, and learns from edits so a correction made once stays made.