How to Keep an Office Master Specification Up to Date

What actually changes in an office master, and who notices?

A master changes for six reasons: standards, regulations, products, project lessons, practice decisions and housekeeping. Give each stream a person who watches it and a date on which they report.

This guide assumes the master already has a named owner, a clear structure and a decision about which clauses are protected, controlled or open. The Office Master Specification: A Technical Director's Guide covers those foundations, including who should own the master and how live projects adopt changes by RIBA stage. What follows is the part that happens afterwards, week after week, for as long as the master exists.

A master changes for six reasons, and it helps to treat them as separate streams because each has a different trigger and a different person who is best placed to notice it. Standards and regulations change outside the practice, on the publisher's or government's schedule. Products change on the manufacturer's. Project lessons, practice decisions and housekeeping originate inside the practice and only arrive if there is a route for them to arrive.

Give each stream an owner and a cadence

The owner of the master does not need to watch all six streams personally. Assign a person to each, and agree when they report. A senior technologist who follows standards watches the standards register. A building regulations lead watches the Approved Documents. A sector lead or specifier watches products in their area. The owner triages the reports, decides what enters the master and releases the changes. This is the same ownership model that works for the wider framework in How to Set and Enforce Technical Standards Across a Multi-Office Practice, applied to one document.

Fix the rhythm so it survives busy periods

Maintenance gets cancelled when it is optional. Put it in the diary in the same way as a financial year-end. A quarterly slot for watch reports, a decision meeting after it, and a full review once a year are enough for most practices. Between the slots, define the triggers that justify an immediate change: a withdrawn standard cited in a mandatory clause, a regulatory change that makes a clause wrong for projects starting now, a safety-critical product withdrawal. Everything else waits for the next cycle.

How do you keep up with withdrawn and superseded standards?

Keep a register of every standard the master cites, with its edition and status, check the priority entries against the publisher each quarter, and trace every change to the clauses that cite it. Superseded standards need a comparison. Withdrawn ones need a decision.

A standards watch is a routine for noticing that a standard cited in the master has been revised, superseded or withdrawn. The tool is a register, the check is a status lookup against the publisher, and the output is a list of clauses that need review. It is mechanical work and a good candidate for software, but the judgement about what to do with each change belongs to the owner.

Withdrawn and superseded are different problems

A withdrawn standard has been removed with no direct replacement, or its content has moved into other documents. A superseded standard has a successor. The treatment differs. For a superseded standard, compare the successor with the clause: scope, test methods and performance classes often change, and a clause that simply swaps the number can specify something different from what it did before. For a withdrawn standard, decide what the clause should say instead, which may mean referring to a different document or writing the requirement out in the clause.

The structural design codes are the standard illustration. BSI withdrew a large group of national structural design standards on 31 March 2010 when the Structural Eurocodes replaced them, including BS 5950-1 for structural steel and BS 8110 for concrete, and government guidance at the time was updated to match. Specifications that still cite those standards today are citing documents that the publisher no longer maintains. That example is old, which is the point: references to withdrawn standards often survive for many years in masters because nobody was assigned to look.

Decide a policy on dated and undated references

A dated reference names an edition and holds the requirement still. An undated reference follows the latest edition and moves with it. Neither is always right. Contractually, a dated reference is clearer about what was priced, and it needs to be refreshed by someone. An undated reference stays current by default and can change the requirement after the contract is signed. Pick a policy for each class of clause, record it in the register and apply it consistently. Mixed practice inside one section is a common source of contradictions and of disputes about which edition applies.

Check the standards that matter most first

A master may cite hundreds of standards. Checking all of them every quarter is wasteful. Rank them by how many clauses cite them and by how serious a wrong reference would be. Check the top tier each quarter, the rest on the annual review, and the whole register after any major change such as the move from one standards family to another. Pick up status changes as they happen where you can, using publisher alerts for the standards you rely on most, and treat the quarterly check as a backstop and not the primary method.

How do you track Approved Document changes in the master?

Assign a regulations watcher, follow the GOV.UK Approved Documents collection and the circulars, and mark affected master clauses with the edition and date they apply from. Hold both regimes until the commencement and transitional dates settle which projects follow which.

For a UK practice the Approved Documents are the other main source of change. They are statutory guidance on how to meet the Building Regulations, and they change in stages: a new edition is published, a commencement date is set, and transitional provisions say which projects follow the old rules and which follow the new. A master that cites the regulations or repeats their numbers needs a person who watches the GOV.UK Approved Documents collection and the circulars that accompany each change.

The recent run of changes is a good test of whether a practice is set up for this. In March 2026 the Building Regulations etc. (Amendment) (England) Regulations 2026 were laid together with new editions of Approved Document L (volumes 1 and 2) and Approved Document F (volume 1), supporting the Future Homes and Buildings Standards. They come into force on 24 March 2027, with 24 September 2027 for higher-risk building work and work to existing higher-risk buildings, in each case subject to transitional provisions. Approved Document L was corrected on 8 September 2026, and Approved Document B was updated on 16 September 2026. Each change has a different date and a different set of projects it touches.

Hold both regimes until the dates settle

A master used on live projects has to serve projects under the old edition and projects under the new, sometimes in the same month. Rather than replace a clause overnight, mark the clauses affected, keep the existing text for projects under the old rules and add the new text for projects under the new rules. Record on each project which regime applies and why: the date of the building notice or initial notice, the transitional provisions that apply, and the person who decided. The decision matters later if the project is queried. Part L and Approved Document L and Approved Document B cover the documents themselves, and Gateway 2 submissions and higher-risk buildings cover where the higher-risk regime changes what the specification must show.

Do not copy the regulations into the master

The simplest way to keep a master current against regulatory change is to cite instead of copy. A clause that says "comply with the current Approved Document" will be right until the document changes and then become ambiguous. A clause that repeats a figure from the Approved Document will be wrong on the day the figure changes, and nobody will know. Prefer a clause that states the project requirement and names the regulation it meets, with the edition recorded. Keep the figures in the Approved Document, and keep the practice's own requirements, which may exceed the minimum, in the master.

Regulations are not only for England

Practices working in Wales, Scotland, Northern Ireland or Ireland have separate regimes with their own change cycles. A master that serves several jurisdictions needs a variant for each, or a clear marker on each clause saying where it applies. Treat each jurisdiction's regulatory watch as a separate stream with its own owner.

How do product changes and project lessons reach the master?

Review preferred products on an annual cycle and on a trigger, and give project teams a short route to flag a clause that caused a problem. The section owner triages every flag, verifies it and records the decision, including when the decision is to do nothing.

Products and lessons are the two streams that depend most on people. Nothing publishes a notice that a product guarantee has been rewritten, and no register tells you that a clause caused three RFIs. Both only reach the master if someone sends them.

Review products on a cycle and on a trigger

A master's preferred products and systems age in several ways: a product is discontinued, a manufacturer renames a range, a test certificate expires, a warranty changes, a supplier leaves the market, or a better option appears. Two routines keep this under control. An annual product review asks the person responsible for each section to confirm that the preferred products are still available, still certified for the use and still on the terms the clause assumes. A trigger route takes notice from a supplier, a rejected submittal or a failed product on site and brings it to the owner promptly. Where a clause names a proprietary product, check also that the equivalence wording still works. Specification Writing for Beginners explains why proprietary clauses need a defined test of equivalence.

Build a lessons-learned intake that people use

The best source of improvements to a master is the work already done. An RFI that asked what a clause meant, a site finding that showed a detail was not buildable, a contractor's query about a missing requirement and a submittal rejected for a reason the clause did not state are all evidence. The route should be short enough to use in the middle of a busy week: a single form or message that records the project, the clause, what happened and what should change. Without a short route, lessons remain in project folders.

Triage and verify

The owner of each section reviews flags on the cycle and sorts them into four outcomes: change the clause, add guidance, refer to the forum because the change affects more than one section, or take no action and record why. Verify before changing. Check whether the problem was in the master or in the way the project used it, whether it will recur and whether the fix would create a conflict elsewhere. A change made on the strength of a single project is the commonest way a good master gets worse. Feed the outcome back to the person who raised the flag, because people stop flagging when nothing seems to happen.

Do not let the master become the lessons archive

A lesson is not always a clause. Some are guidance for the specifier, some are a standard detail change and some belong in a project start checklist. Keep the master for requirements and give the rest a home of their own, linked from the relevant section. A master that carries explanatory notes, project histories and "see also" commentary in the clause text becomes long, and long masters go stale faster.

How do you control versions, release changes and retire stray copies?

Version the master and every section, record each change in a log with a reason and an adoption rule, send a short release note to every office on the day, and retire local copies so that the controlled master is the only starting point.

A change that is made but not released has not happened. Version control gives each state of the master a name, and the release note tells project teams what changed and what they must do. Without both, teams work from whichever version they last copied, and the practice cannot tell which projects carry which text.

Version the master and every section

Give the master a version number that changes whenever any section changes, and keep the version history. Record the last review date on each section as well, so the oldest content can be found. A simple scheme is enough: a minor number for each release and a major number for the annual version or for a structural change. What matters is that every specification starts with the version it was drawn from recorded on it, so that a later question about why a clause says what it says can be answered from the log.

Write release notes people read

A release note is a short message, not a document. List the changes grouped by section, say in one line what changed and why, and state what teams must do: nothing, adopt at the next issue, or adopt immediately. Put the mandatory changes first. Send it to every office on the same day, and keep a copy where project teams look for the master. If a change affects projects already at tender, say so directly. A release note that goes unread is usually a release note that is too long.

Decide which live projects adopt which changes

Changes reach live projects according to a rule, not a request. A common rule is that mandatory safety and regulatory changes apply to every project that has not yet issued for tender. Other changes apply to projects at Stage 3 or earlier. Projects at Stage 4 or later adopt at the project lead's discretion, with the reason recorded. The office master guide sets out how adoption can follow RIBA stages. Whatever the rule, write it into the change log so a project lead can see at a glance whether a given release applies to them. See also Specification Change Control for how changes are managed within a project once the specification is issued.

Retire stray copies

Every year of neglect leaves a trail of local copies: an office's saved version, a team's edited template, a previous project used as a starting point. Each carries text that the controlled master has since corrected. Retire them in a deliberate step. Find them by searching shared drives for specification templates and for recent specifications whose version is not recorded. Archive them read-only, tell the offices the date and ask project leads to confirm that new specifications start from the controlled master. Then check at the start of the next few projects. If the controlled master is slower to start from than the stray copy, fix that first, or the copies will return.

• ✓One controlled master, one location, one current version.
• ✓A version and last-review date on every section.
• ✓A change log with a reason, an approver and an adoption rule for every change.
• ✓A release note on the day of release, to every office.
• ✓A quarterly watch, an annual full review and a list of immediate triggers.
• ✓Stray copies archived, and every new specification recording the version it started from.

Questions technical directors ask about master maintenance

How often should an office master specification be reviewed?

Run a standards and regulations watch every quarter, a full review of every section once a year, and make immediate changes when a trigger occurs, such as a withdrawn standard, a regulatory amendment or a product withdrawal. Record the date of the last review on each section so the oldest content is visible.

How do you find out that a British Standard has been withdrawn or superseded?

Keep a standards register listing every standard cited in the master, with its edition and status, and check the register against the publisher's status information on a fixed cycle. BSI shows whether a standard is current, withdrawn or superseded. Check the most-cited standards first, because they are in the most clauses.

What recent Approved Document changes should an office master reflect?

In England, the 2026 editions of Approved Document L (volumes 1 and 2) and Approved Document F (volume 1) were published in March 2026 and take effect on 24 March 2027, with later dates for higher-risk building work and transitional provisions. Approved Document B has a 2026 amendment booklet whose amendments come into force on 30 September 2026, subject to transitional provisions. A master should record which regime applies to each project.

Who should decide whether a project lesson changes the master?

The owner of the affected section decides, after checking the evidence. A lesson from one project may be a one-off. The owner confirms the cause, then changes the clause, adds guidance or takes no action, and records which. Changes that affect more than one section go to the technical forum or the master owner.

How do you stop teams using old copies of the master?

Make the controlled master the easiest place to start, then retire the copies. Archive old files read-only, tell the offices the date, and check at project start that the specification was drawn from the current version. Stray copies persist when the controlled version is slower to use.

What should a master specification change log record?

For each change, record the section and clause, what changed, why, who approved it, the date, the new version number and whether live projects must adopt it. A short release note summarises the changes for the project teams. The log lets a team answer what changed since the last project and why.

Where Avoice fits

Maintenance is mostly noticing, comparing and recording. Avoice holds the master as a governed library with an owner, so the routine in this guide has one place to run.

In Avoice the office master is a governed library, and projects draw from it instead of copying the last job. Practice Rules apply the values, standards and words the practice requires as the specification is written, so a rule updated in the library reaches every new specification. Standards sets in the clause library hold the standards and guidance a specification may cite, which gives the standards register a working home. The pre-issue Technical Review compares the specification against the schedules and drawings and flags what has gone stale before issue.

The Compliance module tracks building regulations requirements for each project, which supports the regime-by-project record described in the regulations section. Avoice does not decide what the practice standard is or which regime a project follows. The technical director and the section owners make those decisions. See The Office Master Specification: A Technical Director's Guide for the foundations, and The Pre-Issue Technical Review Checklist for the checks that catch stale content before it reaches tender.