When you write a specification manually, you're working clause by clause. You open your template, scroll to the relevant section, and type. The thinking and the writing happen together, usually in the same sitting, often late on a Friday.
With an AI-generated specification, the work splits into two distinct phases: setup and review. The setup phase is where you give the system everything it needs to produce a good first draft. The review phase is where you apply your professional judgement to shape, correct, and refine. Neither phase is passive. You're not watching a machine do your job. You're directing it, the same way a lead architect directs a technologist on the team.
This distinction matters because the quality of your output depends almost entirely on the quality of your input. A vague brief produces a vague spec. A detailed brief, backed by real project data, produces something you can actually work with.
The single most important step happens before you generate anything. Avoice works best when it has access to the project documentation your practice already produces: drawing schedules, material selections, previous project specs, product data sheets, and design notes accumulated during RIBA Stages 2 and 3.
Think of it like handing a brief to a new team member. If you give them a one-line description, they'll produce something generic. If you give them the door schedule, the window schedule, the fire strategy report, and last year's spec for a similar building type, they'll produce something that sounds like it came from your practice.
The ingestion process is straightforward. You upload your documentation, and Avoice's AI agents parse it into structured, searchable data. Material choices, performance requirements, manufacturer preferences, compliance references: all of it becomes available for the specification to draw from. This is what separates an AI-generated specification from a generic clause library. The output is grounded in your firm's actual data, not boilerplate.
If you don't have much historical documentation to draw on, start with whatever you have. Even a single previous spec for a comparable project gives the system useful context about your firm's standards and preferences.
Once your data is in the system, you set the parameters for the specific project. This includes the building type, use class, applicable standards, and your preferred classification system.
For UK practices, the main decision here is between Uniclass 2015 and CAWS. If you're working on a BIM-mandated project or anything procured under a framework that requires Uniclass, that choice is made for you. For private sector work, CAWS remains common, particularly among firms whose QS teams are accustomed to it. Avoice supports both Uniclass and CAWS classification, along with NATSPEC and CSI MasterFormat for practices working internationally.
You'll also want to specify the level of detail appropriate to the project stage. A Stage 3 outline spec needs different granularity than a Stage 4 detailed specification ready for tender. Getting this right upfront avoids the problem of generating a 200-page document when you needed a 40-page outline.
The project setup is also where you confirm which building regulations and standards apply. Part L, Part B, Approved Document M, relevant BS EN standards for specific materials: these get referenced automatically in the generated clauses, so identifying them early ensures the output is relevant from the start.
Plan to spend 20 to 30 minutes on the initial project setup. This might feel slow compared to opening a blank template, but the parameters you choose here shape every clause the system generates. Architects who rush this step tend to spend more time correcting output later. Those who get the setup right find the review cycle significantly shorter.
The first time you see a full AI-generated specification, you'll likely have two reactions. The first is surprise at how much of it is correct, particularly around standard clauses, product references, and classification codes. The second is noticing the places where your professional judgement is needed.
Common areas that require editing include site-specific conditions the AI can't know about (access constraints, ground conditions, adjacent structures), bespoke design features not captured in your uploaded documentation, and nuances around product substitution that reflect your firm's relationships with specific manufacturers.
The editing process is no different from reviewing a spec drafted by a colleague. You're reading with professional eyes, checking that performance criteria match design intent, that product references are current, and that nothing has been over-specified or under-specified. The difference is that this review takes hours rather than the days or weeks you'd normally spend writing the first draft from scratch.
One practical tip: resist the urge to rewrite everything in your own voice on the first pass. Focus on accuracy first. Are the Uniclass codes correct? Do the clauses reference the right standards? Is the level of detail appropriate for the stage? Style and tone adjustments come second. You can always refine language, but getting the technical content right is the priority.
Specifications don't exist in isolation. They sit alongside drawings, schedules, and other project documents, and inconsistencies between these documents are one of the biggest sources of rework on site. A window schedule that calls for triple glazing while the spec references double-glazed units. A fire door schedule specifying FD60 rated doors where the spec says FD30. These are the mistakes that cost money and erode client trust.
Avoice's AI agents can flag inconsistencies between your specification and other uploaded project documents before they become problems. If your door schedule lists a product from one manufacturer but the spec references a different one, the system picks it up. If your drawings show a material finish that conflicts with what the spec prescribes, you'll see it flagged during review rather than discovering it on site six months later.
This kind of cross-referencing is something manual spec writers rarely have time to do thoroughly. It's tedious, time-consuming, and easy to get wrong when you're managing multiple documents across a large project. Having it happen automatically doesn't replace your responsibility to check, but it means you're checking against a cleaner baseline.
Your first AI-generated specification won't be perfect. That's normal. The system produces better output as it learns from your edits and as your uploaded documentation grows. The first spec for a new practice is typically 70 to 80 percent usable on the initial pass. By the third or fourth project, that figure climbs significantly because the system has accumulated more data about how your firm works, what products you favour, and how you structure your clauses.
The most common mistake architects make on their first attempt is not uploading enough reference material. The second most common is trying to generate the entire spec at once rather than working section by section. Start with a section you know well, like external walls or roofing, and review it carefully before generating the rest. This lets you calibrate your expectations and catch any setup issues early.
Another frequent pitfall is treating the generated spec as a finished document rather than a first draft. The AI produces technically sound, well-classified output, but your professional review is still what turns it into a specification you'd be confident issuing for tender. The time saving comes from not having to write that first draft yourself, not from skipping the review entirely.
Once you've completed your first project specification using an AI-assisted workflow, the shift tends to happen quickly. Practices that start with a single pilot project usually adopt the approach across their portfolio within a few months. The time savings are too significant to ignore, particularly for small and mid-sized firms where the same people designing the building are also writing the specs.
The comparison with earlier technology shifts in the profession is instructive. Practices that adopted CAD early didn't just draw faster. They freed up time to take on more projects. The move from 2D to BIM followed the same pattern. AI-assisted specification writing is the next version of that: not a replacement for your expertise, but a way to apply it to more work with less administrative friction.
The real value becomes apparent on repeat project types. If your practice specialises in residential, healthcare, or education projects, the system accumulates deep knowledge about your standard approaches, preferred products, and regulatory requirements for that sector. Each new project starts from a stronger baseline than the last.
If you want to see how this works on one of your own projects, Avoice's AI Spec Agent lets you run a trial with your actual documentation. It's the fastest way to understand what your practice-specific output looks like rather than evaluating against a generic demo.
