A specification and a schedule answer different questions. The specification says what a product is: its performance, its standard, its quality, its reference. The schedule says where it goes and how many of it there are. Door D12, ground floor, east elevation, 926 by 2040, FD30, satin stainless ironmongery. One document is descriptive. The other is positional. They were never meant to be the same thing, and in most practices they have never lived in the same place.
Your specification usually sits in a Word file or a dedicated tool. Your schedule sits in a spreadsheet, or increasingly inside the model as a Revit schedule pulled straight from the door and window families. Different authors, different software, different review cycles. The architect drafts the spec. The technologist builds the schedule. They talk to each other, of course, but they are not reading from a single source of truth, and that is the root of everything that follows.
The part most quality systems miss is timing. The two documents update on different clocks. A client asks for better acoustic performance on the street elevation. The technologist updates the window schedule that afternoon, bumping the glazing to a 38 dB unit. The specification, sitting in a separate file owned by someone else, gets updated next week, or after the next deadline, or not at all.
Every variation, every value engineering exercise, every late design change tugs the two apart a little more. By RIBA Stage 4 you can hold a specification that describes the scheme from three revisions ago and a schedule that describes today. Both look finished. Both have been signed off. Neither one agrees with the other, and the only person who will reconcile them is the contractor, on site, at the worst possible time.
Contractors price from the schedule and they build from the schedule. So when the schedule and the specification disagree, the schedule usually wins, because it carries the quantities and the setting out. The richer performance requirements in your specification, the acoustic rating, the security standard to PAS 24, the U-value, quietly fall away because nobody on site is reading the spec line by line against every opening.
Then the contradiction surfaces as a request for information. Which door is right, the FD30 on the schedule or the FD60 in the spec? Work pauses on that element. A variation gets raised. If the schedule was wrong, you might already have the wrong ironmongery fitted or glazing ordered to the wrong make up. None of this is dramatic on its own. It is simply slow and expensive, and it repeats across dozens of openings on an ordinary job.
The cost is rarely a single big number. It is the accumulation of small ones. An afternoon lost to an RFI here, a part order corrected there, a contracts meeting that runs long because two documents tell different stories. Multiply that across a project, and across a year of projects, and the drift between schedules and specifications becomes one of the quietest drains on a practice's margin.
Fire is where this stops being a cost question and becomes a safety one. After the Building Safety Act, the evidence behind every fire door has to hold together. If your specification calls a door FD60S and your schedule calls it FD30, that contradiction is now a documented discrepancy sitting inside a regulated golden thread. You do not want to be explaining it to a building control body, and you certainly do not want it found after handover.
Fire ratings are exactly the sort of attribute that lives in both documents at once. The specification sets the performance, the standard, and the need for intumescent strips, smoke seals, and the right vision panel glazing. The schedule records it opening by opening. Two places to get it right, which means two places to get it wrong, under a regime that now expects them to match precisely.
The traditional fix is a careful person with both documents open, reading across. On a house, that works. On a school with two hundred doors and ninety window types, it falls apart. No one can hold that many cross references in their head, and the check always lands at the moment the team has least time, the evening before issue.
This is where AI starts to earn its keep. Tools like Avoice read a firm's specifications and schedules together and flag where they disagree before anything goes out the door. Instead of a person manually comparing an FD30 in one file against an FD60 in another, the inconsistency is surfaced for you, with both sources shown side by side. The check no longer depends on whether somebody happened to have an hour spare.
There is a confidence cost as well as a time cost. When you know the cross checking is patchy, you carry a low hum of doubt into every issue. Is the spec right? Did the schedule catch the last change? That doubt is hard to put a figure on, but anyone who has signed off a package near midnight knows the feeling.
The practices that handle this well stop treating the specification and the schedule as two separate deliverables and start treating them as two views of the same data. The performance lives in one place. The schedule reads from it. The specification reads from it. Change the fire rating once and both move together, because both are looking at the same underlying record rather than two copies that have to be kept in step by hand.
Getting there used to mean an expensive bespoke system that only large practices could justify. That is changing. Avoice ingests a firm's existing documentation, the sheets, the schedules, the material libraries, the past projects, and turns them into structured, searchable data instead of a heap of disconnected files. Once the information is structured, checking a schedule against a specification becomes a query rather than a weekend.
When the two documents share a source, the work changes shape. You spend less time hunting for contradictions and more time on the decisions that genuinely need an architect. The specification stops being the document everyone dreads updating and becomes something that keeps pace with the design as it moves.
There is a standards angle here too. Avoice structures its output around recognised classifications, Uniclass and CAWS in the UK, so the schedule and the specification end up speaking the same language by construction. A door classified the same way in both places is a door that is far harder to get wrong. That is the real reward, not faster typing, but documents that cannot quietly drift apart while your back is turned.
The mismatch between your schedules and your specification was never really a discipline problem. It was a data problem wearing a discipline costume. Fix the data and the gap closes on its own. The question for most practices now is how long they want to keep checking by hand for something a machine can catch in seconds. If you want to see how that works on a live project, Avoice runs demos built around your own documents.
