A prescriptive specification tells the contractor exactly what to provide and how to install it. It names products, references the relevant British Standards, sets out workmanship, and leaves little room for interpretation. If you write "150mm Rockwool RWA45 between joists, fully filled, no gaps", that is prescriptive. You have made the decision, and the contractor's job is to carry it out.
Performance specifications work the other way around. You state the outcome the element has to achieve, a U-value, a fire rating, an acoustic reduction, a wind load, and you let the contractor or a specialist subcontractor decide how to meet it. You are not saying which product. You are saying what the product has to do. The same wall might be specified as "achieve a U-value of 0.18 W/m²K and 60 minutes' fire resistance", and how that gets built becomes someone else's design problem.
There is a middle ground that trips people up. A proprietary specification names one product with no alternative allowed. A descriptive specification describes the characteristics without naming a brand. Both are forms of prescription, and most real specifications mix all of these on the same page without anyone deciding that on purpose. That is usually where the trouble starts.
When appearance matters, prescription wins. If you have specified a particular brick because it matches the conservation area, or a window section because the planning officer asked for slim sightlines, you cannot leave that to the contractor's discretion. The whole point is that the decision is yours and it is fixed. Prescriptive specifications give you that certainty.
They also coordinate more cleanly with the rest of your information. A named product has a known size, a known weight, a known fixing detail, so your drawings, your schedules and your specification can all describe the same thing. On heritage work, on high-end residential, on anything where the architect's hand is the value being sold, prescription is usually the honest choice. You are being paid to make those calls, so make them.
The cost of that certainty is risk. Once you name a product and it fails, or it gets discontinued, or it turns out to clash with something on site, the decision was yours and so is the liability. Prescription concentrates control and responsibility in the same place. That is fine, as long as you know you are holding both.
Performance specifications shine when the element is genuinely an engineered system that a specialist understands better than you do. Curtain walling, structural steel, lifts, large rooflights, complex cladding build-ups. These are designed by people who do nothing else, and trying to prescribe every detail yourself is slow and often wrong. State the performance, hand over the design, and let the people with the test data and the warranties take it on.
There is a commercial argument too. A performance specification lets several suppliers price the same outcome with their own products, which tends to sharpen the number. It leaves room for a contractor to propose something cheaper or quicker that still hits your targets. And it shifts design risk onto the party best placed to manage it, which is exactly what you want on a complex package.
The catch is that a performance specification is only as good as its criteria. "High quality finish" is not a performance requirement. It is a wish. If you cannot measure it, the contractor cannot price it and you cannot enforce it. Vague performance specifications are worse than prescriptive ones, because they create the illusion of a requirement while giving you nothing to point at when the work falls short.
The most common failure is not choosing the wrong approach. It is mixing them without realising. You name a product, then add "or equal and approved", which turns a prescriptive clause into a half-formed performance one without setting any criteria for what "equal" means. On site, the contractor proposes a cheaper alternative, you have no measurable basis to refuse it, and the argument eats a fortnight of everyone's time.
Product substitution has become a sharper problem since the Building Safety Act. The golden thread of information assumes you can show what was specified, what was installed, and why any change was acceptable. A loose "or equal" clause sitting next to a fire-rated build-up is now a genuine liability, not just an irritation. If you are going to allow substitution, you have to say on what terms, with what evidence, signed off by whom. That is a decision, and it belongs in the specification, not in an email chain three months later.
The procurement route often makes the decision for you. On a traditional contract, you carry the design, so prescription is the natural default and performance clauses are reserved for the specialist packages. On design and build, the employer's requirements are essentially a large performance specification, and the contractor's proposals fill in the how. Get that boundary wrong and you either lose control of things you cared about or take back risk you meant to transfer.
Contractor design portions are where this plays out in miniature. You define the performance and the interfaces, the contractor's specialist designs the element, and the two have to meet cleanly at the edges. The RIBA Plan of Work is useful here. Through Stage 3 you can hold things open and lean on performance. By Stage 4 the specification has to firm up, and every clause you have left as a vague aspiration becomes a question someone has to answer under time pressure. The earlier you decide which elements you are prescribing and which you are leaving to performance, the less of that scramble you get.
Whichever approach you take, the specification has to agree with the drawings and the schedules. A prescriptive clause naming a 44mm fire door has to match the fire-door schedule and the door types on the plans. A performance clause for glazing has to line up with the U-values your energy calculations assumed. Mixing the two approaches multiplies the cross-checking, because now some elements are defined by product and some by outcome, and the two have to be reconciled by hand across documents that update on different cycles.
This is where tools like Avoice change the calculation. Avoice reads a firm's specifications and schedules together and flags where they disagree, so a glazing performance target that no longer matches the window schedule surfaces before it reaches site rather than after. It uses AI agents that work through the document set the way a diligent technologist would, checking that what the specification promises is what the rest of the information actually describes.
Because Avoice grounds its output in your own past projects, schedules and material libraries rather than a generic clause library, the specifications it produces tend to carry your firm's actual decisions, classified under Uniclass and CAWS, instead of a wall of boilerplate clauses you then have to delete. That matters for the performance-versus-prescriptive question, because the cleaner your starting point, the easier it is to see which elements you have genuinely prescribed and which you have left open.
Stop treating it as one decision for the whole job. Go element by element. For anything where appearance, planning or heritage is driving the choice, prescribe it and own it. For anything that is an engineered system designed by a specialist, set a measurable performance and hand it over. For everything in between, ask one question: do I care more about controlling exactly what gets built, or about transferring the risk of how it performs? Whichever you cannot afford to get wrong is the one that decides the clause.
Then check the boundaries. The expensive failures live at the joins, where a prescribed element meets a performance package, or where an "or equal" clause sits unguarded next to something safety-critical. Make those edges explicit. Say what can be substituted, on what evidence, and what cannot move at all. A specification that has clearly decided its own approach, element by element, is far easier to coordinate, price and defend than one that drifted into a mix by accident.
If you want to see how this works on a real project, Avoice runs demos tailored to your practice, using your own documents so you can watch it pull a specification and its schedules into line. The approach you choose still has to be yours. The point is to choose it on purpose, and to know, clause by clause, exactly what you have decided to control and what you have decided to let go.
