Architects can use AI to build the document checklist and to turn their own design notes into a supporting statement draft. The architect must write the design rationale, verify every policy citation against the source document, and sign off every statement made in the practice's name. Applicant and neighbour data stays out of consumer AI tools.
The line runs between organising and asserting. Checklists, structure and plain-English rewrites organise material that already exists. A design rationale, a policy conclusion or a figure asserts something about a real building, and an assertion needs a named person who can defend it. The sections below mark that line job by job, with the checks to run and the wording to use.
Three zones for an application pack
Sort every task in an application into one of three zones before anyone opens a chat window. The zone decides who writes, who checks and what the assistant may be shown.
| Zone | What happens | Examples in an application |
|---|---|---|
| 1. AI drafts, architect edits | The assistant organises material the architect already holds | The document checklist; the skeleton of a supporting statement built from the architect's own bullet notes; a table of every figure in a finished draft, for checking |
| 2. AI works only on pasted source text | The architect copies the real text in; the assistant summarises or sorts it; the architect reads both | A plain-English summary of a policy paragraph you pasted; sorting consultation responses by topic; pulling the key items out of the authority's list of required documents |
| 3. Architect only | No AI input into the decision or the wording of the claim | The design rationale; judgements on neighbours, heritage, trees and flood risk; which policies apply; every compliance statement; every figure; drawings; signatures and declarations |
A quick test settles borderline cases. If a sentence says something new about the site or the design, it belongs in zone 3, however fluent a draft of it looks. If it reorganises or restates something the architect already wrote or the authority already published, it can sit in zones 1 or 2. The rest of this tutorial applies that test to the two documents where AI is worth using, the checklist and the statement, and then to the checks and data rules around them.
Start with the document checklist
The checklist is the safest job in the whole pack, because the source is public, the output is a table, and a gap shows up as an empty cell. Most authorities publish a list of what a valid application must contain, and the lists vary by application type. Copy that list into the chat along with your own drawing and document register, then ask the assistant to compare them.
Below are (1) the authority's published list of documents for a valid
application of this type and (2) my current drawing and document register.
Make a table: Item | Line from the authority's list (quote it) | In my
register? | Status | Gap or question.
Treat anything marked "if applicable" or "where relevant" as CONDITIONAL and
write me a question for it. Do not add items from your own knowledge.
[paste the authority's list]
[paste my register]Here is an illustrative result for a small rear extension. The quoted lines come from an imagined list.
| Item | Line from the list | In register? | Gap or question |
|---|---|---|---|
| Application form | "Completed application form" | Draft | Declarations to be signed by the person named on the form |
| Location plan | "Location plan with the site boundary marked" | Yes | Check scale and boundary line |
| Floor plans | "Existing and proposed floor plans" | Existing yes; proposed in draft | Proposed plan revision C pending |
| Elevations | "Existing and proposed elevations" | Existing yes; proposed in draft | Rear elevation to be updated for the rooflight |
| Supporting statement | "Where relevant, a statement describing the design approach" | Not started | CONDITIONAL: is it relevant to this proposal? |
| Tree survey | "Where there are trees on or near the site" | No | CONDITIONAL: notes mention a large tree on the rear boundary. Does it trigger a survey? |
| Heritage statement | "Where the site is in a designated area" | No | CONDITIONAL: designation status not known |
Read the table the way a validation officer would. Three habits of the model are worth watching. It merges separate documents into one row, so two drawings become "plans". It treats "where relevant" as "not needed" if you do not force a question. And when you forget the "do not add items" instruction, it fills the table with items from other authorities' lists, which look right and are not on yours.
The check has two parts. First, compare the table with the authority's own page, not the pasted copy, because lists change and some are updated more often than a document saved last month. Check the fee and the file format rules there too. Second, remember what a tick means. "In register" says a document exists, not that it is correct, complete or at the right revision. The checklist finds missing items. It cannot judge the content of the items it finds.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowA supporting statement the architect can stand behind
A supporting statement explains why the proposal is right for the site. The reasoning is the architect's product, so the order of work matters: the architect writes the rationale first, in rough bullets, and only then does the assistant shape it into prose. If the assistant writes first, the architect ends up editing someone else's argument and approving claims they never made.
Turn my bullet notes into a supporting statement under these headings:
The site; The proposal; Design approach; Materials; Neighbours.
Use only the facts in my notes and keep my numbers exactly as written.
Add no policy references, no percentages and no judgement words such as
"sensitive", "harmonious" or "appropriate". Never write that anything
complies, accords or conforms. Where a claim would need my assessment, write
[CONFIRM: what is needed] instead.
- rear extension 3.6 m deep x 5.2 m wide, single storey, flat roof with rooflight
- set 1.2 m off the left boundary; right-hand neighbour already has a 3 m extension
- brick to match the house; aluminium-framed glazing
- kitchen and dining become one room opening to the garden
- large tree on the rear boundary: extension kept clear of the root zone, per the tree adviser's noteWithout those rules, a typical first draft of the same notes reads like this: "The proposal is a sensitively designed single-storey extension that harmoniously respects the character of the area and has no harmful impact on neighbouring amenity, in full accordance with local policy. The design reduces overshadowing by approximately 15 per cent." Every clause in it is an assertion nobody supplied. "Sensitively" and "harmoniously" are judgements, "no harmful impact" is a conclusion, "in full accordance with local policy" is a compliance claim, and the 15 per cent is a number the model made up.
With the rules, the draft comes back closer to this, shown here with the architect's edits already applied:
The proposal is a single-storey rear extension, 3.6 m deep and 5.2 m wide, with a flat roof and rooflight. It is set 1.2 m from the left-hand boundary. The adjoining property on the right already has a 3 m extension. Materials are brick to match the existing house and aluminium-framed glazing. The kitchen and dining room become a single room opening to the garden. A large tree stands on the rear boundary, and the extension is kept clear of its root zone, as set out in the tree adviser's note. [CONFIRM: effect on neighbouring daylight, to be assessed from the drawings.]
Now the architect's part. Each number goes back to a drawing. The sentence about the tree is true only if the tree adviser's note says so, so the architect opens the note. The [CONFIRM] marker becomes either an assessment the architect writes after studying the drawings, or a deletion. The compliance words, if any, go in last, by hand, after the citations have been checked in the next section. Stay alert to the opposite failure as well: a statement scrubbed of every judgement can read like a data sheet, and authorities and neighbours are persuaded by reasoning. That reasoning, in the architect's words, is the part no assistant can supply.
When you have a finished draft, use the assistant for a second job that is safe: "List every number, dimension, date, percentage and proper name in the text below, one per row, with the sentence it appears in. Do not check them." Add a column for the source drawing and tick each row yourself. It is a faster way to find a figure that moved between revisions. The longer treatment of this kind of statement, with a sample structure, sits in drafting a design and access statement with AI and what the architect checks.
Policy citations: open the source for every one
This is the check that matters most, and the one most likely to be skipped because the draft looks finished. Language models write text that resembles policy references: a plausible code, a plausible paragraph number, a confident sentence about what the policy requires. Some of those references exist and some do not, and from the page you cannot tell which. A wrong citation in a submitted statement is a professional embarrassment at best, so the rule is absolute: a citation the architect has not opened does not go in.
- Ask for topics, not numbers. "List the policy topics a reviewer would expect this statement to address" is a fine question. "Which policies apply?" is not.
- Find the current document yourself, on the authority's own site, and record its title, version and date. Documents get replaced, and a model trained on older text may cite numbering that no longer exists.
- Copy the exact wording of the paragraph into a citation log.
- Decide whether the wording supports the claim. This step is a judgement and stays with the architect.
- Only then write the citation, by hand or by letting the assistant format it from the log.
The log can be a simple table. An illustrative extract, with invented policy references, shows what it catches:
| Claim in the statement | Cited in the draft | What the source says | Result |
|---|---|---|---|
| Extension is subordinate to the original house | Policy HD-3 | The wording sits in the design guide, section 4.2, not under HD-3 | Keep the claim; correct the reference |
| Proposal protects neighbours' daylight | Policy EN-7 | No policy with that number in the current document | Remove the reference; find the real one, or delete the claim |
| Materials match the existing house | Design guide, para 6.1 | Wording matches the claim | Keep |
| Parking is unchanged | None | No citation needed | Keep as a plain fact |
The second row is the dangerous one, and it is the kind a reviewer would catch in seconds. The claim itself may be fine; the reference was invented to decorate it. Without the log, the architect reads "Policy EN-7" in a sentence that sounds right and moves on. With the log, there is a row that cannot be completed. Keep the log in the project file: it is also the record that shows your insurer, if ever asked, that every citation was checked against a source.
The assistant has a useful, limited role in this step. Once you have copied the real paragraph into the chat, it can summarise those words in plain English, or tell you which sentences of your draft the paragraph appears to bear on. That is zone 2 work, because the source is on the table. You still read the paragraph yourself, since a summary can drop the exception that matters.
Applicant and neighbour data in AI tools
An application pack is full of personal information: the applicant's name, address, phone and email; ownership details; neighbours' names and addresses on consultation lists; and objection letters that sometimes mention health, family or security. Data-protection laws treat names and addresses as personal data (the GDPR does, if you have clients in the EU), so check what your practice may do with them, and ask your data-protection adviser if you are unsure. Three habits keep the risk small.
- Minimise before pasting. The assistant does not need a name to sort comments by topic. Replace people with roles, and addresses with house numbers or "neighbour A".
- Choose the account carefully. The business tiers (Claude Team and Enterprise, ChatGPT Business and Enterprise, Gemini in Workspace, Microsoft 365 Copilot) all state that customer content is not used for model training by default. Personal ChatGPT and Claude accounts can use chats for training unless the model-training option in privacy settings is off, so if anyone in the practice drafts on one, confirm that setting first and keep applicant and neighbour details out of it entirely.
- Keep the originals in the project file. Delete working chats when the task is done, and never treat a chat as the record.
A before-and-after shows what minimising means for an objection. Original: "The neighbour at number 14 writes that the extension will block light to her kitchen and adds that her husband is unwell and needs a bright room." Version for the assistant: "Neighbour A objects: loss of light to a kitchen; mentions a health circumstance (details withheld)." The assistant can group that comment with others on daylight, and the sensitive detail never leaves your file. When the summary comes back, the architect still reads the original letters. A summary can soften a complaint or drop the single point the authority will weigh, and the person who signs the response needs to have read what was actually said.
Check two further sources of leakage. Your appointment or the client's own terms may forbid sharing project information with third parties, in which case the answer is no until you have written permission. And site photographs can show neighbours, number plates or security equipment, so crop or leave them out before uploading. The wider policy questions, including who owns copyright in drawings, are covered in the copyright and client-data risks AI brings to a practice and in an AI policy checklist for drawings and client data.
AI-made images in a submission
Image generators are good at mood pictures and poor at being accurate. An application image is evidence: neighbours and reviewers use it to understand what will be built and how it sits against its surroundings. A generated picture that adds a taller tree, a softer sky or a smaller neighbouring building persuades by misleading, and it can come back as a complaint.
- Use views built from the model for anything that shows the proposal in its setting, so that the geometry matches the drawings.
- Keep generated mood images for client presentations, where nobody relies on them as a record, and label them as illustrative if they ever travel further.
- Never let an AI image alter the context: street scenes, neighbouring properties, trees and boundaries are facts about the site, not styling choices.
- Check the authority's guidance on visualisations before you include any, because what it accepts, and what it may require to be verified, varies.
If an image was touched by AI at any stage, say so in the file note, so that whoever signs the pack knows what they are signing.
Who signs what, and why AI authorship changes nothing
Every document in a pack has someone who answers for it. AI involvement does not move that responsibility an inch, and a statement that reads like an automated assessment ("analysis shows no harm to neighbours") quietly claims a credential no tool has. Write every claim as the architect's own assessment, in the architect's own voice, or leave it out.
| Document | Who answers for it | Where AI may have helped |
|---|---|---|
| Application form and declarations | The person who signs the form, the applicant or the agent named on it | Nowhere in the declarations. The checklist may track them |
| Ownership and notice declarations | The applicant, on facts the applicant supplies | Nowhere |
| Drawings | The architect, under revision control | Not in the design judgements |
| Supporting statement | The architect who signs it | Zone 1 draft and zone 2 sorting, with every claim traced |
| Specialist reports (tree, heritage, flood, structural) | The specialist who signs | Nowhere. Never draft a specialist's opinion for them |
Whoever signs a declaration is saying it is true. "The AI wrote that part" is unlikely to carry any weight with an authority, a client or an insurer, and it is not an explanation you would want to give. That is why the review routine below exists, and why it is worth reading what AI drafts in construction design and what needs a stamp and what to tell your insurer before the first application goes out.
A review routine before anything is submitted
Run the same seven steps on every pack, in this order, and write down who did each one.
- A second person reads the pack cold, without being told which parts AI touched.
- Every figure in the statement is traced to a drawing, using the table of numbers the assistant extracted, and ticked.
- Every policy citation has a source and a log row, with the wording copied and the document version recorded.
- Search for the compliance words: "complies", "in accordance with", "accords", "conforms". Each is the architect's explicit claim, so each one is kept or deleted on purpose.
- Check the personal data rule: no applicant or neighbour details beyond what the application needs, and nothing from a working chat that should have stayed in the file.
- Compare the final PDF with the last reviewed text. An assistant asked to "tidy" a paragraph often changes words elsewhere, and a late edit can undo an earlier check.
- Record the use in the project file: which parts used AI, which tool and plan, and who reviewed them. Your insurer or client may one day ask.
The same habits sit behind the internal notes that come before an application, described in briefs, planning notes and consultant chasers, which keeps those notes to facts and topics so nothing in them can be mistaken for a conclusion.
A small rear extension, timed with and without AI
Here is an illustrative timing for the pack described above, a single-storey rear extension for one applicant. The minutes are estimates to be replaced by your own, and the "with AI" column includes every check.
| Job | By hand (min) | With AI plus checks (min) | What the AI column contains |
|---|---|---|---|
| Document checklist | 45 | 20 | Prompt, comparison, check against the authority's page |
| Rationale and statement draft | 180 | 75 | 40 minutes writing the bullets, 35 minutes editing the draft |
| Figure trace against drawings | 40 | 25 | Table of figures from the assistant, ticked by the architect |
| Policy citation log | 90 | 80 | Finding and reading the sources; the assistant helps only with summaries |
| Total | 355 | 200 |
The saving is 155 minutes, about 2 hours 35 minutes on one small application, or roughly 52 hours a year at twenty such applications. Look at where it comes from. Drafting and tracing shrink. Verification barely moves, and it should not: the citation row falls by only ten minutes because the work is finding and reading the real documents. A plan to adopt AI that promises to shrink the citation check is a plan to skip it. Time your own pack the first time through, keep the log, and decide from your numbers whether the routine earns its place.
Questions architects ask about AI and applications
Do I have to tell the planning authority I used AI?
There is no universal rule, and expectations differ between authorities and professional bodies. Check the authority's current guidance, your professional body's position and your insurer's wording. Whatever you disclose, the architect who signs stays responsible for every statement, so keep a note in the project file of what AI touched.
Can AI summarise objections or consultation responses?
It can group comments you paste in by topic and flag repeats, provided you strip names and addresses first and use a business plan. The architect still reads every original comment, because a summary can soften or drop the one point that decides the case.
Can AI supply the figures in a statement?
No figure should come from AI. Areas, heights, distances and percentages come from the model or the drawings, and the statement quotes them. Tell the assistant to leave a placeholder wherever it wants a number, then fill each one from the drawing and tick it off.
Which AI tool should I use for application documents?
Any current assistant can restructure notes and build checklists, so choose on data terms. Prefer a business plan that does not train on your data by default, and keep the application's personal data out of personal accounts. The tool matters less than the review routine around it.
Further reads
- How to Use Claude AI in Architecture: Specs and Planning Reports — Claude for specifications and planning reports.
- AI Drawing Review: Check Architectural Sets Before You Issue Them — Check a drawing set before it is issued.
- AI Policy for Architects: A Ready-to-Use Checklist and Clauses — Write the practice AI policy once, then follow it.
- HOA Architectural Review Requests: AI Checks Against Guidelines — Checking review requests against written guidelines.
- What AI Is Good for Architects? Six Jobs for a Small Practice — Six jobs for a small practice, with limits.
- Claude vs ChatGPT vs Gemini for Architects: Which to Pay For — A practice owner's guide to paying for Claude, ChatGPT or Gemini: seat costs, drawing-file limits, data settings and a test you can run in an afternoon.
- Electrical Permit Application: Track Permits and Inspection Dates With AI — A contractor's permit tracker: one job record for applications, a dated sheet for inspections, and AI for scope summaries, chase lists and correction notices.
- How to Use AI in Architecture Design: Concept Options for Small Practices — A concept workflow for small architecture practices: a numbered brief register, planning limits with page references and a brief check after every AI step.
- Solar Permit Application: Can AI Draft It? What Installers Must Verify — How installers can use AI for permit narratives, cover letters and completeness checklists, and what the designer must verify.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: OpenAI enterprise privacy page; vendor privacy statements for business plans (Claude Team and Enterprise, Microsoft 365 Copilot, Gemini in Workspace).