Design, Documentation, and the One Act Nobody Can Delegate

A practice bills for design, and design is a minority of the hours. Separating what actually fills the week is the first step to knowing where tooling helps.

Design. Massing, layout, systems selection, the decisions that determine what the building is. Intellectually dense, comparatively few hours, and the reason clients hire you.

Documentation. Drawings, schedules, and specifications: the instrument that tells a contractor what to build. Enormous, repetitive, detail-critical, and the single largest consumer of time in most practices.

Coordination. Making the architectural, structural, mechanical, electrical and plumbing work occupy the same building without conflict. Partly automated already through clash detection in modelling software, and still full of judgement about which discipline moves.

Contract administration. Requests for information, submittals, site queries, change orders. Reactive, interrupt-driven, and running for the whole length of construction.

Where the compression sits follows immediately. Documentation and contract administration are largely text and structured data, and they compress substantially. Coordination gained from geometry tools long before generative models. Design compresses least, because the constraints are physical and the judgement is what a licence certifies.

Which is the same shape as the other professions in this catalogue, with one difference that makes the boundary sharper here. In AEC the responsibility is not just professional convention. It is a stamp with a name on it, and that is the next step.

The professional seal is the clearest statement in any regulated profession of what cannot be delegated, and it is worth being precise about what it asserts.

When a licensed architect or engineer seals a drawing set, they are certifying that the work was prepared by them or under their responsible charge, and that they are applying their own professional judgement to it. Licensure statutes across jurisdictions are built on that phrase or a close equivalent. The seal is not a certification that the building is perfect. It is an identification of the person answerable for the judgement.

Two consequences follow, and they point in opposite directions.

The first is that no tool can hold this. There is no mechanism in any licensing regime for a system to be in responsible charge, and no version of a disclaimer that transfers it. A generated detail that fails is the sealing professional's detail.

The second is that using tools is entirely ordinary. Practices have always sealed work produced by draughtspeople, junior staff, consultants and software. What the seal has always meant is that a licensed person reviewed it and adopted it. That is a workflow the profession has run for a century.

So the operative question is never whether a tool was involved. It is whether the person sealing exercised genuine judgement over what they sealed, which is exactly the question the profession already asks about junior staff work.

And there is a related prohibition worth knowing: sealing work you did not prepare and did not supervise, sometimes called plan stamping, is a disciplinary matter in most jurisdictions. Rubber-stamping generated output is that same offence in a new costume.

A point that surprises people outside the profession, and that determines how verification should be judged.

The legal standard applied to design professionals is not perfection. It is the degree of care and skill ordinarily exercised by members of the same profession practising under similar circumstances at the same time and place. A design that turns out to be imperfect is not automatically a breach; a design produced without the customary care is, even if nothing goes wrong.

That framing matters for tooling in a way that is easy to miss.

It means the question a court or board would ask is not did the tool make an error. It is did this professional do what a reasonably careful professional would have done with such a tool. And because the standard tracks what the profession customarily does, it moves as practice moves.

Two practical implications.

Adopting a tool and checking its output the way you would check a junior's is defensible, because it is the customary treatment of assisted work. Adopting a tool and not checking, on the basis that the output looked right, is where exposure sits, and looking right is precisely what generated output does.

And the standard being contemporary cuts both ways. As verification practices settle, failing to perform the checks that peers perform becomes the breach. The safe position is not avoiding the tools. It is doing what careful practitioners do with them, and being able to show it.

Which is why documentation of the checking, covered in lesson three, is not bureaucracy. It is the evidence that care happened.

Mapping the work against what a tool may carry.

On the delegable side. Drafting specification sections from your decisions. Summarising a long submittal or product datasheet. Drafting a response to a routine request for information. Extracting requirements from a client brief or a planning condition. Producing the first version of a schedule. Generating options for a massing study before any of them is chosen.

On the non-delegable side, and the reason in each case.

The design decision itself, because that is the judgement the licence certifies.

Anything determining life safety: structural adequacy, egress, fire separation, load paths. A wrong answer here is not a defect, it is a hazard.

Code compliance as a conclusion, because a confident wrong citation of a code provision is invisible on the page and load-bearing in a permit application.

And the seal, which is the formal act of adoption.

The pattern to notice is that the boundary does not follow difficulty. Generating a plausible structural approach is easy for a model; verifying it is the hard, licensed part. The boundary follows consequence and accountability.

Of everything in this profession, code compliance is where generated output is most tempting and most dangerous, and the reason is structural rather than incidental.

Building codes have exactly the properties that produce confident wrong answers. They are numbered and sectioned, so a citation can be well-formed and refer to nothing. They exist in versions, so a provision correct under one edition may be wrong under the one your jurisdiction adopted. They are amended locally, so the national model code and the code actually in force differ in ways no general source captures. And they interact, so a provision read alone can give the opposite answer to the same provision read with its exceptions.

That last one is the killer. Code provisions are riddled with exceptions, and a summary that omits an exception reads as a clean answer.

So a model asked whether a corridor width is compliant will produce a definite answer with a section number, and the answer may be based on the wrong edition, the unamended model code, or the provision without its exception. None of that is visible in the response.

The workable use is the inverse of the tempting one. Use it to find which provisions might apply, then open the adopted code for your jurisdiction and read them. That is genuinely useful, because knowing where to look in a code you use rarely is a real cost.

What must not happen is a generated compliance conclusion entering a drawing set, a permit application or a client letter. The person sealing is asserting compliance, and a plan examiner rejecting a set is the good outcome. The bad one arrives later.

The phrase generative design predates language models and means something more specific, which is worth separating out because the two behave completely differently.

Parametric and optimisation-driven design has existed in the profession for years. You define a goal and constraints, the software searches a solution space and returns options ranked against your objective: structural mass, daylight, floor plate efficiency, circulation distance. The output is geometry that satisfies stated constraints, and it is verifiable because the constraints are explicit and the physics is computed.

Image generation is a different thing entirely. It produces a picture of a building. It is genuinely useful for early conversation, mood, and giving a client something to react to before anything is committed.

What it does not produce is a building. The image has no structure, no dimensional consistency, no buildable assembly, and frequently no coherent relationship between what the facade implies and what the plan would allow.

The practical risk is the gap between those two facts and a client's perception. A photorealistic image reads as a design decision that has been made, and it sets expectations about what the finished building will look like. Walking that back after a client has fallen in love with an image is a real and expensive problem in practice.

So the discipline is about framing rather than about the tool. Generated imagery is explicitly a conversation starter, labelled as such, presented before commitment rather than after. And the moment a scheme is real, the images should come from the model of the actual building.

One is exploring the space. The other is representing a decision. Confusing them is how the tool causes damage.

A limitation worth stating plainly, because it explains why the design step resists compression more than the equivalent step in other professions.

A building is a response to a specific place. The ground conditions, which come from a survey and a geotechnical report. The adjacent structures and what they do to light and access. The prevailing wind, the flood history, the tree with a preservation order. The planning authority's temperament and what it approved two streets over. The route a crane can take. What the local trades can actually build well and at what price.

Almost none of that is in any general corpus, and much of it exists only in documents specific to your project or in the heads of people who work in that place.

Which produces a specific failure mode. A model asked for a design approach will produce a competent, generic answer: the solution that is typical for that building type. Sometimes that is a useful starting point. Often it is precisely wrong for the site, and it is wrong in a way that is invisible unless you know the site.

The practical response is to supply the specifics rather than expect them. The survey, the geotechnical summary, the planning constraints, the client brief, the local authority's design guidance. Given those as documents, the output becomes markedly more useful, and the failure mode shifts from invention to misreading, which you can catch.

And the general principle for the whole cursus: the tool is strong on what is typical and blind to what is particular. Buildings are particular. That gap is where the profession lives.

An order that follows consequence rather than novelty.

First, the reading problem. Summarising long documents you must understand but did not write: product datasheets, submittals, geotechnical reports, planning conditions, consultant reports, the client's brief. High volume, real time saving, and you read the parts that matter afterwards.

Second, contract administration drafting. Responses to routine requests for information, transmittals, meeting minutes from your own notes, the covering letters nobody enjoys. Reviewed before sending, and the review is for technical accuracy rather than tone.

Third, specification drafting from your decisions. You choose the system, the performance criteria and the standards; the tool produces the section in your office's format. Lesson two covers the discipline this needs.

Fourth, requirement extraction and checklists. Turning a brief, a lease or a planning consent into a list of things the design must satisfy, then checking it yourself.

And not without a person owning the conclusion: anything about code compliance, anything about structural adequacy or life safety, and anything sealed.

The ordering principle is the one from the seal. Everything above the line is preparation and drafting, where an error costs an hour. Everything below it is judgement, where an error costs a building.

Most practices start at generated imagery because it demonstrates well. That is the one use with no verification discipline attached and the highest chance of setting a client expectation you cannot deliver.