Assembling a Planning Pack: From Sketch to D&A Statement.

What a planning pack actually needs to contain

Most planning departments in England and Wales expect the same baseline from a householder or small residential application: a site location plan, existing and proposed drawings at recognised scales, contextual or street-scene views where streetscape impact is a live question, and a Design and Access Statement where the Town and Country Planning (Development Management Procedure) Order requires one. None of that is exotic. What trips up applicants isn't usually the design itself, it's the presentation of it.

Local authority guidance is consistent on this point: a DAS is a short report explaining the design principles behind a proposal, showing how context (character, scale, massing, materials, street pattern) has shaped the scheme, and setting out the access strategy. Officers repeatedly flag the same failure modes: statement text that doesn't match the submitted drawings, thin or missing explanation of context in conservation areas, and generic boilerplate that reads like it was lifted from a different application. A DAS is meant to be written for the scheme in front of the officer, not assembled from a template with the address swapped out.

That's a workflow problem as much as a writing problem. If your drawings live in one folder, your site photos in a phone camera roll, your policy research in browser tabs, and your statement draft in whatever document app you opened last, cross-checking becomes guesswork under deadline pressure. Setting up a Projects workspace in Desk to hold drawings, contextual images, research notes and the statement draft in one place means nothing gets assembled from memory the night before submission.

To keep this concrete, the rest of this piece follows one small case study: a single-storey rear extension to a semi-detached house, going through householder planning in a conservation area where street-scene impact and materials matter. The scheme is modest. The pack still has to hold together.

Turning your own drawings into contextual views

The starting point is always your own drawing set: CAD or hand-drawn proposal elevations, sections, and the site plan. These are the source material, not a prompt written from scratch. Using Image generation to produce a street-scene view or a massing-in-context render works from your own linework, so the roof pitch, window proportions and party wall lines it produces are grounded in what you've actually drawn, not an approximation of "an extension".

This matters for a conservation area case like the one above, where the planning officer will be looking closely at how the extension reads against the host building and its neighbours. A generated view that shows the right eaves height, the right brick coursing and the right relationship to the boundary is useful evidence. A generated view that's vaguely extension-shaped but doesn't match the drawn section is worse than useless, because it invites exactly the "statement doesn't match the drawings" criticism that officers call out.

Boards is the right place to bring this together: site photography, neighbouring building references, precedent images of similar approved extensions on the street, and the generated contextual views, all on one canvas. Seeing the proposal next to its actual context, rather than in isolation, makes it much easier to spot where a generated view has drifted from what you drew.

Before any of it goes near the pack, cross-check proportion and materiality against your drawn elevations. Print the elevation, sit it next to the screen, and look for mismatches in window head heights, roof pitch, brick bond, render texture. This is a five-minute check that saves an officer flagging it as an inconsistency later. Treat every generated view as illustrative, not as a substitute for the scaled elevation it's based on. That's true for any site, but it's non-negotiable for a conservation area submission where the statement needs to demonstrate the design was informed by, and matches, the character of the street.

Researching the policy context before you write a word

A DAS is judged partly on how well it demonstrates awareness of relevant local plan policy, conservation area guidance, and any adopted design codes. Officers expect to see the proposal positioned against these documents, not just described in isolation. For the extension case, that means the local plan's householder design policies, the specific conservation area appraisal for the street, and any supplementary design guidance the authority has adopted.

Using Research (Perplexity-backed) to pull the relevant policy documents for the site address turns a slow manual search across council PDFs into a single query, with links back to the primary source. That link-back matters: always verify the citation against the actual council webpage or PDF before it goes into the statement. Research surfaces the material fast, but the writer is still responsible for accuracy of what's quoted.

Build this into a policy reference list you can cite directly, rather than paraphrasing from memory or guessing at policy numbers. It's also worth checking precedent: similar approved applications in the same authority, particularly other rear extensions on the same street or in the same conservation area. These are useful for the "access" and "amount" sections of the statement, where a documented pattern of similarly scaled approvals strengthens the argument.

Once the research is gathered, feed the findings straight into Corb as project chat context. Corb, ArchAdemia Works' assistant, works from what's actually in the project when you start drafting, so it understands the site constraints, the relevant policy references and the precedent pattern before a single sentence of the statement gets written.

Drafting the Design and Access Statement in Write

Structure the statement around the sections authorities consistently expect: use, amount, layout, scale, landscaping, appearance, and access, with a description of the existing site and its character up front. This structure isn't arbitrary; it's what most council guidance documents ask for directly, and it's what officers scan for when reading quickly.

Write's model picker is useful here because different sections carry different kinds of work. The policy-referencing sections, use, amount, layout, where the statement has to argue why the proposal's scale and footprint are appropriate against local plan policy, benefit from a stronger reasoning model: Claude Opus 4.8 or GPT-5.6 Sol. These sections need to hold a chain of reasoning together, connect the proposal back to specific policy wording, and read as considered rather than assertive.

Shorter, more descriptive sections, existing site description, materials and appearance, a first pass at the access statement, can move faster with Gemini Flash or GPT-5.6 Luna. These are quicker, lighter-weight passes that still need editing but don't need the same depth of reasoning to get a workable first draft down.

Bring the contextual images and research notes in as reference material while drafting, so the statement describes what the pack actually shows rather than a generic account of "a rear extension in a conservation area". If the generated street-scene view shows red brick coursing and a slate roof matching the host building, the appearance section should say exactly that, referencing the specific view by name.

Partway through, use Corb as a second pair of eyes on the draft. Ask it directly: does this paragraph match what's in drawing PR-02? Is the policy reference in the layout section actually supported by an explanation, or is it just a citation with nothing behind it? This is where having the drawings, research and draft all in the same project pays off, Corb can check the draft against material that's actually loaded into the project rather than working from the text alone.

Checking the pack reads as one document, not five

Guidance is explicit that a DAS should read as a coherent argument: context assessment, evaluation, then design solution, in that order, with each stage supporting the next. A pack that reads as five separate documents stapled together, drawings from one session, a statement from another, images from a third, undermines that coherence even when each piece is individually fine.

Cross-reference systematically before compiling anything: every contextual view named in the statement should exist in the pack and match the drawing number it refers to. If the statement says "as shown in the street-scene view, the proposed extension sits below the ridge line of the host property", that view needs to be in the pack, labelled consistently, and it needs to actually show that. This sounds obvious written down. It's the single most common gap between a rushed pack and a clean one.

Review scale and visual consistency across images too. Contextual views, site photographs and drawings should sit together as if they came from the same project, not look like three different jobs got merged at the last minute. A photorealistic street-scene view next to a rough massing sketch and a formal scaled elevation can look inconsistent even when the underlying content is accurate, so keep the visual register of contextual images reasonably consistent across the pack.

Before compiling the final submission PDF, run a final pass with Corb across the whole project chat, drawings list, image captions, research notes, draft statement, and ask it to summarise any gaps: mentions of elements not present in the drawings, policy references without supporting explanation, contextual views cited in the text that don't exist in the pack. This is a workflow pattern worth using well, not an established industry standard; there's no independent research yet on LLMs used specifically for DAS quality assurance. Treat it as a useful check before human review, not a replacement for it.

Keeping the workflow reusable for the next application

Once the extension pack is submitted, the structure behind it is worth keeping. Save the Projects workspace layout, drawings, contextual views, research bundle, draft statement, as a template for the next application. Most small practices run several similar householder or small commercial jobs a year; having a repeatable shell means each new job starts from structure rather than a blank folder.

For practices doing this often enough to justify it, a Canvas workflow can pipe drawing references through Image generation and into a Creative Assistant node for statement drafting, reducing the manual reassembly that eats time on repeat application types. This isn't about removing judgement from the process, it's about not re-inventing the plumbing every time.

Similar single-workspace patterns are showing up across adjacent disciplines. Product designers are building central canvases where CAD screenshots, user research notes and safety standard excerpts feed into compliance narratives. Urban designers working on design codes combine GIS exports, policy maps and generated perspective views on one board to support outline applications. Landscape architects use generated imagery for seasonal planting impressions while the CAD planting plan remains the actual contractual document. The pattern is the same everywhere: keep the material together, keep the drawings as the anchor, treat generated content as illustrative support.

The real payoff of keeping the whole pack in one project shows up when a planning officer comes back with a quick query, a request for an additional sightline, a question about a material specification, a clarification on the access strategy. If the drawings, research and statement are scattered across email threads and separate apps, that query means an afternoon of reassembly. If they're in one project, it's a fast, contained revision. A DAS is meant to be treated as a living record that evolves with the scheme, and that's only practical when the material behind it lives in one place to begin with.

The single most useful habit from all of this: before a pack goes anywhere near submission, ask whether the statement, the drawings and the images tell the same story, in the same order, about the same scheme. If they do, presentation stops being a reason to knock the application back, and the design gets judged on its actual merits.