Authoring Guide
There is no enforced order when authoring a BEP in dotBEP. You can start wherever makes sense for your project and build from there. That said, there is a recommended sequence, not because the AI requires it, but because it helps you as the author think coherently and avoid revisiting decisions later.
This guide follows that recommended sequence, section by section.
BIM objectives
Start here. BIM objectives define why BIM is being used on this project: what specific outcomes the team is aiming for. Everything that follows (BIM uses, workflows, deliverables) should connect back to these objectives. Defining them first gives the rest of the BEP a clear direction.
If you already know your objectives
Tell the AI directly what the project is trying to achieve with BIM:
For this project, our BIM objectives are:
- Reduce coordination clashes between disciplines before construction
- Provide the client with an accurate as-built model at handover
- Support quantity take-offs during the design phase
Please add these as objectives to the BEP.If you need help identifying them
Give the AI context about the project and let it suggest a starting point:
This is a [type of project, e.g. hospital renovation] with [key characteristics, e.g. multiple disciplines, tight construction schedule, public client]. Based on this, what BIM objectives would you recommend for the BEP? Suggest a few options and I will tell you which ones apply.Review what the AI proposes, adjust the wording to match your project’s language and priorities, and confirm. The AI will then add them to the BEP.
Phases and milestones
Once you have your objectives, define the project’s timeline. Phases give the BEP its temporal structure (design, construction, handover), and milestones are the specific dates within each phase when deliverables are due. Establishing this early gives every subsequent decision a time reference to anchor to.
If you have a defined project schedule
Provide the phases and key dates directly:
Please add the following phases and milestones to the BEP:
Phases:
- Design
- Construction
- Handover
Milestones:
- Concept design complete: [date]
- Design freeze: [date]
- Construction start: [date]
- Structure complete: [date]
- Practical completion: [date]
- As-built handover: [date]If your schedule is still being defined
Give the AI a project duration and type, and let it suggest a reasonable structure:
The project is a [type, e.g. new office building] with an estimated duration of [e.g. 24 months] starting in [month and year]. Suggest a phase and milestone structure for the BEP based on this, and I will adjust the dates and names as needed.Teams, roles and participants
You do not need to have the full picture before you start. Teams, roles, and members can be added at any point during the project. Start with what you know and fill in the rest as the information becomes available.
Adding teams
Teams represent the organizations involved in the project: your firm, the client, subcontractors, consultants, and so on. Each team has a role that describes its function in the project.
If you already know which teams are involved:
Please add the following teams to the BEP: [team name] as [role, e.g. BIM Manager], [team name] as [role, e.g. Client], [team name] as [role, e.g. BIM Coordinator]. We are [your firm name].If you are not sure which teams to include yet:
Based on a [type of project], which teams would you typically expect to be part of a BEP? Suggest a list and I will confirm which ones apply to this project.Defining roles
Roles describe the positions that members can hold within a team. dotBEP includes a set of standard roles, but you can also define custom ones specific to your project.
If you want to add a custom role:
Please add a role called [role name] with the following description: [description].If you want to review what roles are already defined before adding more:
List the roles currently defined in the BEP.Adding members
Members are the people assigned to teams and roles. You can add them one by one or in a batch, and you can always come back to add more as new participants join the project.
If you are ready to add specific people:
Please add the following members to the BEP: [full name], [email], [role] at [team name]. [full name], [email], [role] at [team name].If you want to add someone but are mid-conversation and prefer to keep going:
Please add [full name] from [team name] as [role]. Their email is [email].BIM uses
BIM uses describe the specific applications of BIM on the project: coordination, quantity take-offs, clash detection, handover, and so on. Each use connects to one or more of the objectives you defined earlier, making the link between intent and practice explicit.
If you already know which BIM uses apply
List them directly and the AI will add them to the BEP:
Please add the following BIM uses to the BEP: [use name], [use name], [use name]. Link them to the relevant objectives.If you want to be more specific about how each use connects to your objectives:
Please add the following BIM uses and link them to the objectives indicated: [use name] linked to [objective description], [use name] linked to [objective description].If you need help identifying which uses apply
Give the AI context about the project and let it suggest a starting point:
Based on the objectives and project type we have defined, which BIM uses would you recommend including in the BEP? Suggest a list with a brief justification for each.Review the suggestions, confirm the ones that apply, and ask the AI to discard the rest. You can always add more uses later as the project scope becomes clearer.
Workflows
Workflows are the heart of the BEP. Without them, a BEP is a statement of intent but not actionable software: it says what the team wants to achieve but not how they will actually do it. This is the clear distinction between BEP as a document and BEP as a software, which is what dotBEP proposes. A BEP with well-defined workflows gives every participant a clear picture of who does what, in what order, and who is responsible for each step.
Beyond the BEP itself, workflows are what make dotBEP useful during project execution. Once the BEP is in place, the team can create instances of each workflow directly in the platform to track real work in progress, log decisions, and maintain a traceable record of how the project was actually carried out. The quality of that record depends entirely on how well the workflows are defined in the BEP.
How a workflow is structured
A workflow is a diagram made up of nodes connected by edges. Understanding the building blocks helps you describe your processes clearly to the AI, which in turn produces more accurate and complete workflows.
Nodes are the steps in the diagram. There are five types:
- Start and end mark where the workflow begins and where it concludes. Every workflow has exactly one of each.
- Process represents a step carried out by a person. It has a RACI assignment (who is Responsible, Accountable, Consulted, and Informed) and describes what work needs to happen at that point. This is the most common type of node.
- Decision is a branching point: the workflow evaluates a condition and takes one of two or more paths depending on the result. Decision nodes have no RACI and require no human action — they are evaluated automatically by the engine based on the context available at that moment.
- Automation represents a step carried out by a system rather than a person: an external integration, a validation check, or any logic that runs without human intervention. An automation node always connects to a decision node immediately after, which routes the workflow based on the automation’s output.
Edges are the connections between nodes. Each edge can carry an event that triggers the transition (for example, “model submitted” or “review approved”), a condition that must be met for the transition to be taken, and effects that fire automatically when the transition occurs (such as a notification to the next responsible party).
You do not need to think in these terms when describing a workflow to the AI. You can describe the process in plain language and the AI will map it to the correct structure. But knowing what is possible helps you ask for exactly what you need.
If you already have a workflow defined
If you have a workflow mapped out on paper, in a spreadsheet, or in a diagram tool, describe it to the AI and it will build it in the BEP:
Please create a workflow called [workflow name] for the following process: [describe the steps in order, who is responsible for each, and any decision points or approvals involved].The more detail you provide about each step and its RACI assignments, the more complete the workflow will be. You can always refine it afterwards.
If you want the AI to draft a workflow for you
If you know what process you want to document but have not mapped it out yet, describe the goal and let the AI propose a structure:
I need a workflow for [process, e.g. clash detection and coordination]. Please propose a sequence of steps with RACI assignments based on the teams and roles we have already defined in the BEP.Review what the AI proposes step by step. Adjust the sequence, rename steps, reassign responsibilities, and ask it to revise until the workflow reflects how your team actually works.
If you want to add a decision point or approval step
Real workflows are rarely linear. If a step requires a review or an approval before proceeding, you can ask the AI to add a decision point:
After the step [step name] in the [workflow name] workflow, add a decision point where [role] reviews the output. If approved, the process continues to [next step]. If rejected, it goes back to [earlier step].Reviewing a workflow before finalizing
Once a workflow is drafted, it is worth asking the AI to walk you through it before you move on. This helps catch gaps, missing RACI assignments, or steps that do not reflect how the team actually operates:
Walk me through the [workflow name] workflow step by step, including the RACI assignments for each step. Flag any steps where a role has not been assigned.Linking workflows to BIM uses
Each workflow should be linked to at least one BIM use. This connection is what ties the governance structure of the BEP to its stated objectives and makes the document internally consistent:
Link the [workflow name] workflow to the [BIM use name] BIM use.If a workflow supports more than one BIM use, you can link it to several at once:
Link the [workflow name] workflow to the following BIM uses: [use name], [use name].Once your workflows are defined, they become the foundation for project execution. To understand how dotBEP runs workflow instances, tracks transitions, and supports events, effects, and automations, see BEP Execution.
Standards and guides
Standards define the rules the team must follow when producing and managing information: naming conventions, file formats, modeling requirements, coordinate systems, and so on. Guides are complementary documents that explain how to apply those rules in practice, such as step-by-step procedures for a specific software or activity.
Defining standards and guides in the BEP gives the whole team a single, authoritative reference for how work should be done, reducing ambiguity and rework.
Adding a standard
If you have a standard already written or can describe its content:
Please add a standard to the BEP called [standard name]. It covers the following: [description of what the standard defines].If the standard is a document that already exists and you want to attach it:
Please add a standard called [standard name] and attach the following file as its content: [attach or paste the document].Adding a guide
In dotBEP, guides are not written documents. A guide is a curated collection of annexes: external references such as documents, links, or videos that explain how to carry out a specific activity. Guides are typically linked to workflow actions, so that when a team member is executing a step in a workflow, they have direct access to the references that explain how to do it.
To add a guide and its annexes:
Please add a guide called [guide name] with the following annexes: [annex name] ([url or description]), [annex name] ([url or description]).To link a guide to a specific workflow action:
Link the [guide name] guide to the [step name] step in the [workflow name] workflow.Reviewing what is already defined
Before adding more standards or guides, it is useful to see what is already in the BEP:
List the standards and guides currently defined in the BEP.Information requirements
Information requirements define what level of detail is expected from each model element at each milestone. In dotBEP this is expressed through the LOIN (Level of Information Need): for each element type, you specify the level of geometry (LOD) and the level of information (LOI) required at each key date.
This section tends to be the most technical part of the BEP and is also the one where errors have the most downstream impact, since it directly governs what the team must produce and when.
If you have an information requirements table
If your project already has an information requirements table (from the client, a standard, or a previous project), share it with the AI and ask it to populate the BEP:
I'm attaching our information requirements table. Please read it and add the LOIN entries to the BEP, matching each element to its LOD and LOI per milestone.If you need to define requirements from scratch
If no table exists yet, the AI can help you build one based on the project’s BIM uses and milestones:
Based on the BIM uses and milestones defined in the BEP, what information requirements would you recommend for [element type, e.g. structural elements]? Propose a LOIN table and I will review it.Work through the element types one group at a time. It is easier to validate in chunks than to review a large table all at once.
Reviewing what is defined
To check the current state of your information requirements before moving on:
List the LOIN entries currently defined in the BEP, grouped by element type.Location breakdown structure
The location breakdown structure (LBS) defines how the project is divided spatially: buildings, floors, zones, areas, or any other breakdown that makes sense for how the work will be managed and delivered. Deliverables in dotBEP can be assigned to LBS nodes, which allows the team to track what needs to be produced for each part of the project.
Defining the LBS
If you already know how the project is spatially organized:
Please add the following location breakdown structure to the BEP: [top-level node, e.g. Building A] containing [child nodes, e.g. Ground Floor, First Floor, Second Floor]. [top-level node, e.g. Building B] containing [child nodes].If the structure is simple, a flat list works just as well:
Please add the following locations to the BEP: [location name], [location name], [location name].If you are not sure how to divide the project, describe it and let the AI suggest a structure:
The project consists of [describe the physical scope, e.g. a hospital with three wings and a basement plant room]. Suggest a location breakdown structure for the BEP.Deliverables
Deliverables are the tangible outputs the team must produce: models, drawings, reports, schedules, and any other information package with a defined responsible party and a due date. In dotBEP, deliverables are organized in two complementary views: the TIDP (Task Information Delivery Plan), which shows deliverables by team, and the MIDP (Master Information Delivery Plan), which shows all deliverables across the project ordered by phase and date.
Defining deliverables is the final step of the BEP authoring sequence. By this point you have the phases, milestones, teams, workflows, and LBS in place, and all of that structure is what makes the deliverables meaningful.
Adding deliverables
You can add deliverables one by one or in batches. For each deliverable, the key information is: what it is, who is responsible, which milestone it is due at, and optionally which LBS node it belongs to.
Please add the following deliverables to the BEP: [description], responsible [team name], due at [milestone name], location [LBS node]. [description], responsible [team name], due at [milestone name].If the deliverables come from an existing document
If your project has a deliverables schedule or a master document register already, share it with the AI and ask it to populate the BEP:
I'm attaching our deliverables schedule. Please read it and add all the deliverables to the BEP, matching each one to the correct team, milestone, and location where possible.Reviewing the MIDP
Once deliverables are defined, you can ask the AI to summarize the full schedule to review it for gaps or inconsistencies:
Show me a summary of all deliverables in the BEP ordered by milestone, including the responsible team for each.Reviewing the TIDP for a specific team
To see what a particular team is responsible for:
List all deliverables assigned to [team name], grouped by milestone.