Data and Execution Connection

The BEP is not just a reference document. It is the source of truth the execution engine reads at runtime to enforce rules, validate actions, and drive workflow progress. Every field you define when authoring the BEP has a purpose beyond documentation.

Workflow nodes and RACI

When you assign a responsible role to a workflow node, you are not just labeling who owns that step. The engine uses that assignment to validate every event that attempts to advance the workflow instance past that node.

If a user tries to emit an event (submitting a deliverable, approving a revision, closing a phase), the engine checks whether that user belongs to the responsible role defined on the node. If they do not, the action is rejected. The workflow does not advance.

This means the RACI matrix you build in the authoring phase becomes an enforceable access control layer at execution time, with no additional configuration required.

Teams and members

Roles alone are not enough. The engine resolves roles to actual users through the team and member definitions in the BEP. A role like “BIM Manager” is meaningful at runtime because the BEP maps it to specific members and teams.

When the engine evaluates whether a user can act on a node, it traces: user → member → role → node assignment. All of that resolution happens from BEP data.

Deliverable states

The workflow structure you define determines the valid states a deliverable can occupy and the transitions between them. The engine only allows state changes that follow the paths established in the workflow diagram. There are no shortcuts, no manual overrides outside the defined flow.

This page will grow alongside the execution engine. As more of the BEP’s fields become operationally active, the connection between authoring decisions and runtime behavior will be documented here.