Synthesizing a building program from several competing documents is one of the most valuable uses of AI in architecture, engineering, and construction, because it compresses a task that normally takes days into minutes without losing rigor.
- A third data source, such as a master plan, grounds the synthesis in the non-negotiables of the project.
- Priority logic tells the model how to reconcile conflicts between program, interview, and master plan data.
- A conflict log paired with a clean synthesized table gives you a defensible recommended building program.
This lesson is a preview from our AI Workflows for AEC Professionals Course Online. Enroll in a course for detailed lessons, live instructor support, and project-based training.
This is a lesson preview only. For the full lesson, purchase the course here.
The goal is to move from several competing sources to one reasonable, buildable program. A master plan sets the framework for all new construction on campus, a client interview captures stakeholder priorities and constraints, and a consultant-produced program document contributes technical detail. Each source has blind spots, and each source has strengths. Done well, synthesis turns that tension into a cleaner and more defensible starting point than any single document on its own.
Start with a Fresh Chat
Before touching the documents, open a new chat. Continuing inside an existing chat can cause the model to hallucinate, which is AI-speak for pulling in stray data from the earlier history of the conversation. A clean slate avoids that. Once the new chat is ready, upload the three source documents: the program document, the master plan, and the client interview transcript. Select all three in one upload so the model sees them as a single batch attached to the same prompt.
With the files loaded, the next step is writing the prompt itself. The structure used here is role, task, format, sometimes called RTF. Each element tells the model something specific about how to approach the work.
Define the Role Narrowly
Role is the first section of the prompt. For this task, the right role is lead space planner. The instinct is to write architect, but a narrower role produces a more focused output. Calling the model a senior space planner keeps the work tight, because space planning is exactly what a program synthesis asks for. A broader role invites the model to drift toward form-making and diagramming, which belong in a later phase.
Write a Precise Task
The task section starts with a verb that matches the job. Earlier prompts used words like analyze for messy documents or extract for technical ones. Synthesize is the right verb here, because multiple sources are being reconciled into a single output. A workable task sentence reads, synthesize a final building program from the three attached files. That one sentence communicates scope, source, and expected output.
Lay Out the Priority Logic
Priority logic is the shot that makes program synthesis reliable. Without it, the model weighs every source equally and cannot decide which one wins when they disagree. Number the priorities so the model reads them as an ordered list. A defensible order for a university project looks like this:
- The master plan sets the non-negotiable requirements, because the project cannot violate the campus-wide framework.
- The client interview transcript is high-value primary data, because the Dean has decision authority and insider knowledge such as not exceeding the height of a historic bell tower.
- The consultant program document is high-value technical data, but is flagged with a note to correct any errors, because consultants often include fluff language and occasional inconsistencies.
The word but after the third priority is important. It tells the model that the consultant's numbers are worth mining for technical content, while also giving permission to flag and resolve errors rather than accepting them at face value.
Specify the Output
Format and output are often interchangeable in RTF, and output works well here because the result is a pair of deliverables rather than a single paragraph. Use letters for output items, so the numbering in the task section and the lettering in the output section do not confuse the model. The first output is a conflict log, presented as a table that shows discrepancies between the files along with a proposed final resolution. The second output is a synthesized room table, with columns for room ID, room name, estimated square feet, primary user, and technical requirements. Those columns mirror the combined headers of the program document and the interview document, which is how they naturally fit together.
Once the prompt is ready, submit it. In moments, the model reads through the documents, applies the priority logic, and returns the requested outputs. The conflict log arrives first, showing items like a program that references four stories when the master plan and interview cap the building height lower. The synthesized room table follows, complete with IDs, names, square footages, and technical requirements pulled from across the sources.
The Role Shift for AEC Professionals
This kind of workflow changes the role of the professional in the room. Instead of hand-sorting program data, chasing conflicts, and formatting tables, the human becomes an investigator. The first job is to find the right data sources, because the model can only synthesize what it has access to. The second job is to review the output, accept or revise the final resolutions proposed in the conflict log, and apply judgment on items that cannot be decided by pattern alone.
This shift is the magic of the workflow. A building program that might take days of analysis now takes minutes, and the time saved goes back into higher-value work like diagramming, client communication, and design exploration. The model handles the churn, which was never where the real expertise lived anyway.
Save the Result for Future Reference
Once the synthesis looks right, rename the chat thread to keep it findable. A useful convention is to call it RecommendedBuildingProgram rather than FinalBuildingProgram. In architecture, engineering, and construction, nothing is truly final until the owner has moved in, and even then things change. Labeling the output as recommended makes the status honest and leaves room for the client review that inevitably follows.
Use a fresh chat, upload all relevant sources, and write an RTF prompt with a narrow role, a precise task, clear priority logic, and a specific output format. Ask for both a conflict log and a synthesized room table so the reasoning is visible and defensible. Treat yourself as the investigator and reviewer, and let the model handle the synthesis work. The result is a recommended building program produced in minutes, grounded in your actual project documents, and ready for the client conversation that follows.