Airclerk helps engineering consultancies put AI to work on the document load around delivery: the design report assembled from the project file with its gaps listed, the compliance evidence traced to each requirement, the review prepared before the reviewer sits down. Calculations, design decisions, producer statements and sign-off stay with the engineer.
Illustrative example
A structural design report for a commercial fit-out, assembled from the firm’s own template and the project file as it stands. The workflow fills what the file supports, names what it does not, and leaves every engineering call to the engineer. Illustrative project; no real client.
Four checks under one section. One is complete and cited, one has moved under the report’s feet, one rests on a document everybody assumed had arrived, and one is honest about where the file goes quiet. The engineer opens the report knowing which pages to trust and which questions to answer first.
Two lines hold the output together. The workflow prepares and checks: it assembles the sections, traces each claim to a source and revision, and lists what is missing or superseded. The engineer decides: adequacy, compliance, design changes, the producer statement and the signature stay with the chartered engineer, and the report says so on its face.
The same discipline runs through nine other workflows, from the fee proposal to closeout →
Engineering consultancies use AI models such as Claude, Microsoft Copilot or ChatGPT to support document-heavy project work such as fee proposal drafting, project brief analysis, requirements registers, RFI and correspondence triage, design report assembly, Building Code evidence matrices, Health and Safety by Design registers, peer-review preparation, producer-statement readiness and project closeout. The assistant can be connected to the firm's project folders, document-management system, email, CRM, project-management platform, approved templates and internal knowledge. Project isolation, source citations and engineer approval are built into the workflow. The AI supports the work around engineering judgement. It does not replace engineering calculations, design decisions, certification or professional sign-off.
These are starting patterns, not a packaged engineering suite. Each workflow is adapted to the firm's disciplines, systems, templates, professional boundaries and standards access. Each is a candidate first workflow.
Turns the client brief, correspondence, prior project examples and the firm's commercial templates into a first-draft proposal. Scope, deliverables, assumptions, exclusions, dependencies and information required from the client are separated clearly for principal or director review.
Extracts requirements from the client brief, consent documents, architectural information, specifications, meeting notes and project correspondence. Creates a traceable register of requirements, owners, source documents, decisions, open questions and changes.
Classifies incoming project correspondence by discipline, project, urgency and required action. Drafts responses for routine items, identifies missing information, updates the open-issues register and escalates anything requiring engineering judgement. Nothing is sent without the project team's approval.
Builds a report shell from the firm's approved template and assembles the available project information into the correct sections. Sources, assumptions, exclusions, referenced drawings, outstanding calculations and unresolved inputs are made visible rather than filled with plausible language. The engineer reviews the technical narrative and remains responsible for the final report.
Maps the project's proposed compliance pathway against the evidence available in the file. Relevant drawings, calculations, reports, specifications, product information and review records are linked to each requirement. Gaps, conflicting revisions and unsupported claims are flagged for the engineer's decision. This is an evidence-organisation workflow, not an autonomous determination that the design complies.
Assembles identified design risks, decisions, controls and residual risks from workshops, meeting notes, design reports, drawings and project correspondence. Tracks ownership and records what information needs to pass to the client, contractor, operator or later project stage.
Prepares the project for internal or external peer review. Checks the file against the firm's approved review checklist, assembles the design basis and key assumptions, identifies missing or superseded material, and produces a review index with direct links to supporting evidence. The peer reviewer makes the technical findings.
Checks whether the expected supporting information appears to be present before a producer statement is prepared or signed. The workflow can assemble the relevant design documents, review records, construction observations, changes and outstanding exceptions against the firm's approved readiness checklist. It does not issue, approve or sign a producer statement.
Turns structured site notes, photographs, correspondence and identified departures into a draft observation report. Items are linked to their evidence, assigned an owner and tracked through response, reinspection and closure. Anything potentially affecting the design or final sign-off is escalated.
Builds regular client and internal project reports from correspondence, actions, programme information, commercial records and deliverable status. At closeout, it assembles the final document index, unresolved-item register, decision history, handover material and lessons learned.
Optional AI Process Assurance can sit behind the workflows we implement: the instructions, sources, exceptions, review changes and sign-off retained as an AI Workpaper, so the firm can show what the AI did, what it did not do, how the result was checked and who approved it. It is a platform subscription, implemented alongside the workflow, and the workflow runs without it.
A free introductory conversation is enough to say whether the workflow you have in mind is a first workflow, and to quote a fixed fee for it. The detailed design happens inside the engagement, with your engineers, against your own templates and project systems.
Where AI could make the biggest difference, how that work runs today, the systems it touches and who owns it. We also work out together whether Airclerk is the right partner for it. If we are, the conversation gives us enough to quote.
One document: the outcome we are aiming for, what we deliver, what your team contributes, the fixed fee and timeline, and what acceptance looks like. Nothing starts until it is agreed on both sides.
The engagement opens with the detailed design, agreed with you before anything is built. Then we configure and connect the workflow to your documents and systems, build in the agreed review controls and audit trail, test it on real work, and prepare the people who will run it.
Handover, and the support that follows go-live, are written into the scope so you know what is covered before you sign. Ongoing operations and further workflows are a separate agreement, made when you want them rather than switched on by default.
Read how an engagement runs in detail →
Airclerk can implement Claude, Microsoft Copilot or ChatGPT depending on the firm's existing environment. Workflows run on the firm's approved enterprise instance and under its own vendor agreement.
The first workflow is chosen by volume, source availability, repeatability, review effort and professional risk. For many firms that means fee proposals, project brief analysis, RFI triage, design-report assembly, review preparation or project reporting. Calculations, safety-critical selections, final compliance decisions, certifications and professional sign-off remain outside the first workflow.
Each workflow defines who reviews what: project engineer, discipline lead, technical director, project director or another authorised reviewer. The workflow stops at the appropriate boundary. It does not send project correspondence, approve a design change, close a technical issue or produce a signed professional document by itself. The AI Workpaper records which sources were used, what exceptions were raised, what changed during review and whether any required gate was missed.
The workflow is evaluated against held-out examples from the firm's own completed work. Does it use the correct project revision? Does it distinguish evidence from assumption? Does it identify missing information instead of inventing it? Does it maintain project isolation? Does it route technical decisions to the right engineer? Does it stay within the approved standards licence? Cross-project leakage, prompt injection, unsupported technical claims and false-completeness checks form part of the production gate.
The engagement produces: the configured workflow on the firm's approved AI platform and systems; a Workflow Charter defining its stages, permitted sources and approval gates; a clear boundary statement describing what the workflow must never decide or do; evaluation results from held-out project testing; a standards and reference-content access model; a runbook for engineers, project managers and support teams; training appropriate to each role; a retained AI Workpaper for each material run; the check-ins after go-live that confirm the workflow is being used safely, shaped to the firm and written into the scope. Ongoing operations beyond that are a separate agreement.
The first production workflow should not ask the AI to perform load calculations, size structural elements, select safety-critical systems, certify compliance or make a final design decision. Engineering software, calculation tools and competent engineers remain responsible for that work. The AI fits around those systems: organising the project evidence, finding inconsistencies, preparing reports, surfacing missing inputs and making the review process easier to perform and evidence.
The most useful engineering knowledge is rarely contained in a generic prompt. It sits in the firm's proposal templates, design-report structures, review checklists, drawing standards, project correspondence, approved examples, lessons learned and the judgement of its experienced engineers. Airclerk works with the firm's engineers to turn those methods into repeatable AI skills, rather than imposing a generic engineering playbook.
Many engineering standards are licensed and copyright-protected, and a subscription does not automatically permit their content to be embedded in an AI application. Standards content is connected only where the firm's licence permits the proposed use; otherwise the workflow works from internal checklists and source references, and stops for an engineer to verify the relevant standard. The detail is in the FAQ below.
The objective is not to make the AI the engineer. It is to make the project file more complete before an engineer reviews it: the right documents assembled, the right requirements traced, open issues visible, sources identified, assumptions recorded and approval gates followed. That is where speed and professional control can reinforce one another.
Engineering consultancies can use AI to support document-heavy work around engineering delivery: fee proposals, scope drafting, project brief analysis, requirements registers, RFI and correspondence triage, design report assembly, compliance evidence matrices, Health and Safety by Design registers, peer-review preparation, producer-statement readiness, site observation reports and project closeout. Airclerk implements these as governed workflows connected to the firm's approved project systems, documents, templates and knowledge. Engineers retain the calculations, technical decisions, review and sign-off.
Not in the workflows Airclerk recommends as a starting point. Engineering calculations should remain in the firm's approved calculation and modelling tools, operated and reviewed by competent engineers. The AI can organise the inputs and outputs, prepare surrounding documentation, identify inconsistencies and assemble review evidence, but it does not become the designer of record. Final design decisions, certifications, producer statements and other professional sign-offs remain with the firm's authorised engineers.
Only where the firm has the rights required for the proposed use. Engineering standards are commonly licensed and copyright-protected. A purchased PDF, network licence or online subscription does not automatically permit standards content to be copied into an AI tool or digital application. Airclerk maps the proposed workflow against the firm's licences before implementation. Where direct use is not permitted, the workflow can rely on the firm's approved internal checklist, link the engineer to the applicable source and require human verification rather than reproducing or recalling the standard.
Two controls come first. Project isolation: material from one client or project is walled off from another project's work. Permission-aware access: the workflow sees only the project material the person running it is already authorised to access in the firm's existing systems. Before project information is connected, Airclerk reviews the AI vendor's enterprise terms, retention, training use, subprocessors and data-location arrangements. The implementation runs on the firm's approved enterprise instance, under its own agreement with the AI provider.
In plain terms: the workflow keeps a record of its sources, the checks it ran and who approved the result. Airclerk calls this AI Process Assurance. A Workflow Charter defines the expected process, approved sources, professional boundaries and review gates. A Semantic Audit records what actually happened during the run. The retained AI Workpaper shows the sources used, exceptions raised, review changes and final approval. It does not claim to capture everything an engineer does. It creates a reviewable record for the specific AI-assisted workflows the firm chooses to govern.
The approach applies to multidisciplinary and specialist consultancies, including firms working across structural, civil, geotechnical, mechanical, electrical, fire, hydraulics, water, environmental, acoustics, seismic and building-services engineering. The first workflow is selected around the firm's actual work rather than its discipline label. A specialist consultancy and a multidisciplinary firm may share the same high-value starting point, such as report assembly, review preparation or project correspondence triage.
We are not aware of one, and we would be cautious of one. Engineering methods, disciplines, systems, project types and professional boundaries vary too much for a generic package to be installed safely. Airclerk brings the implementation method, governance controls, workflow architecture and reusable patterns. The firm brings its engineers, systems, templates, approved references and technical review standards. The first engagement starts with a first conversation and runs as a co-design process, not a generic engineering brain delivered from outside the practice.
AI features inside Microsoft 365 and engineering platforms are useful, and Airclerk does not try to replace them. The workflow layer crosses systems and follows the firm's process. It can begin with the client brief, retrieve the correct project documents, apply the firm's approved checklist, prepare a report, route it to the responsible engineer and retain the evidence of review. The firm controls the configured process, professional boundaries and approval gates. We implement Claude, Microsoft Copilot and ChatGPT; the platform is chosen around your systems and the work.
Bring the deliverable that takes the longest to assemble: the design report, the peer-review pack, the producer-statement file. An introductory conversation is enough to say whether it is a first workflow and what it would cost to build.