What should RIBA Stage 4 resolve before construction begins? RIBA stage 4 technical design automation turns coordinated design intent into practical, buildable control-system information. It should make key interfaces, responsibilities and assumptions clear before they create uncertainty on site.
Detailed drawings and specifications are important at this point, but detail alone doesn’t guarantee coordination. Automation depends on aligning with architectural, structural and mechanical and electrical information, and agreeing how systems will exchange information and support operational needs.
This article explains the purpose and boundaries of automation engineering at Stage 4, and the coordinated information that helps move a design towards delivery. It sets out practical checks for finding unresolved interfaces, assumptions and late-change risks before the next project stage. With a disciplined approach, Stage 4 can carry control-system intent into a design that is clearer to build, integrate and test, instead of leaving critical decisions to be resolved during construction.
Key Takeaways
- Understand how RIBA Stage 4 develops strategic requirements into coordinated technical information for the project team.
- Use project needs and system interfaces to guide decisions about functions, operating modes, alarms, PLCs, SCADA and field devices.
- Assess whether the design is genuinely coordinated by distinguishing verified interfaces and documented requirements from placeholders and assumptions.
- Apply a practical review sequence to examine requirements, discipline interfaces and design verification with relevant stakeholders.
- See how RIBA stage 4 technical design automation can support continuity from early design through to delivery and commissioning.
What RIBA Stage 4 technical design means for automation systems
The RIBA Plan of Work 2020 names Stage 4 “Technical Design”. For automation systems, this is where the project’s agreed intent is developed into technical information that supports coordination and delivery. The scope and deliverables depend on the building, operational requirements and project responsibilities, so the design should identify what information is needed to resolve its particular control-system interfaces.
RIBA stage 4 technical design automation turns agreed control-system intent into coordinated engineering information that the project team can review, integrate and use to progress the design. This requires engineering judgement. Software can support the production or revision of drawings, but it cannot resolve unclear requirements or decide how systems and disciplines should interact.
How Stage 4 differs from earlier design stages
Earlier stages establish and develop the project’s requirements and design intent. Stage 4 takes those foundations forward by resolving the technical detail and interfaces needed to coordinate automation with the wider project. It should refine earlier decisions, not replace agreed operational needs or introduce unexamined assumptions.
For example, an earlier design may identify a need to monitor plant and communicate its status to a supervisory system. At Stage 4, the team can define what information is required, where the system boundary lies and how the relevant disciplines’ designs connect. Check that these decisions are reflected consistently in the control description and related design information.
What technical design automation covers
Automation design can address control narratives, system architecture and interface definition. A control narrative explains intended system behaviour; architecture describes how control and supervisory functions are arranged; interface information clarifies the connections and exchanges with other systems or disciplines. Together, these help the team understand how the proposed solution is intended to operate, not simply what appears on a drawing.
Decisions about PLCs, SCADA and field devices should follow from the project’s functions, existing systems, operational conditions and interfaces. The design should show how requirements inform the proposed arrangement and make relevant assumptions visible. To review it, trace a key function from its requirement through the intended control behaviour to the system and interface responsible for delivering it.
BIM and computer-aided drafting tools can organise and communicate design information, but they are not automation engineering in themselves. A model may show equipment locations; engineering must also establish what the equipment does, how it communicates and how its operation aligns with project requirements. Treating the two as interchangeable can leave a visually developed design with important control questions unanswered.
Stage 4 also sits within a longer design process. Earlier requirements need to remain traceable as technical choices develop, and those choices need to support later delivery and commissioning. AAC LTD | All About Control’s control-systems design consultancy guide explains how control-systems design can extend across RIBA Stages 1 to 5, connecting early project intent with later implementation.
Which control-system decisions must be resolved during RIBA Stage 4
At Stage 4, automation decisions should follow from documented operational requirements, not technology choices made in isolation. The team should be able to trace each intended function to the system responsible for it, the conditions under which it operates and the information it needs from other systems. The RIBA Plan of Work 2020 provides the wider framework; control-system decisions and deliverables should reflect the project brief and design responsibilities.
In practical terms, RIBA stage 4 technical design automation should make the proposed behaviour and system boundaries clear enough for the relevant project teams to coordinate. Control narratives, functional descriptions and design schedules can record this where appropriate. They should explain the decisions, rather than conceal them behind drawings or generic descriptions.
From operational requirements to control philosophy
Engineers translate intended operating behaviour into documented control logic: what starts, stops or changes state, which conditions affect that behaviour, and what information operators need. Operating modes and alarms should reflect the agreed requirements, with their purpose and relationship to system functions made clear to the team.
In an airport environment, a project might need control systems to monitor or coordinate building services that support operations. Define the functions from that airport’s systems and operational needs rather than assuming the same requirements apply at every site. Distinguish agreed requirements from assumptions, and record open questions alongside the decision or interface they affect.
Defining interfaces across systems and disciplines
Automation interfaces may involve mechanical plant, electrical supplies, ICT networks and operational systems. For each relevant connection, clarify which systems are involved, what information or signals are exchanged, and who is responsible for providing or receiving them. A defined boundary helps each discipline understand what its design must accommodate.
Explicit interfaces reduce design ambiguity by showing where each system’s responsibility ends and the next begins. An interface register or schedule can capture signal purpose, source, destination and outstanding dependencies. This gives the design team a practical way to identify missing information, such as an agreed function without a defined data exchange, before it becomes a construction-stage query.
Technology choices follow from these requirements and interfaces. PLC selection should support the required control functions and project constraints; SCADA should suit supervisory and operator information needs; field devices should align with the functions they serve and the conditions in which they operate. These decisions are related, but not interchangeable: specifying a platform does not define system behaviour or settle integration responsibilities.
A useful Stage 4 review asks whether each key function has a documented purpose, whether its operating behaviour and alarms are described where needed, and whether dependencies between disciplines have an owner and a route to resolution. Make assumptions visible without presenting them as settled design. For project teams developing coordinated control-system requirements, AAC LTD | All About Control’s automation engineering consultancy supports the work from requirements through design.
How to distinguish coordinated Stage 4 automation from design that only looks complete
A substantial drawing set can create an impression of progress without showing that design decisions agree. A control diagram may look detailed, for example, while its assumptions differ from the operating description or information in another discipline’s documents. The useful test is not how much has been produced, but whether the information tells a consistent, reviewable story about the proposed solution.
For RIBA stage 4 technical design automation, coordination means checking the relationships between requirements, design documents and project interfaces, then recording what has been reviewed and what remains open. Models, drawing packages and design-management systems can organise this work, but they don’t replace engineering judgement about whether the information is coherent and suitable for the project’s needs.
Signs that automation design is genuinely coordinated
Look for consistency across requirements, control narratives and system boundaries, with design choices traceable to the needs they address. Interfaces should be identifiable, responsibilities understood and information exchanges documented where relevant. Review comments should lead to recorded decisions or tracked actions, so the team can see how the design developed and what still needs resolution.
- Requirements and design descriptions use consistent terms and describe compatible behaviour.
- Interfaces and responsibilities are identifiable in the relevant project information.
- Comments, decisions and document revisions can be followed through the review record.
Where apparent completeness can conceal risk
Generic sequences or repeated standard details may not reflect a project’s actual operating needs. A document can also leave a key input, interface owner or design assumption unclear, even if its layout appears finished. These gaps don’t automatically make a design unworkable, but they should be visible so the project team can assess their relevance and agree how to address them.
- Placeholder text or unverified information is presented without a clear status.
- Documents describe the same function or boundary differently.
- Review actions remain unresolved without an owner or recorded decision.
Separate verified information from open decisions. A clear status, such as agreed, under review or awaiting input, helps prevent an assumption from being mistaken for an approved requirement. Record the decision’s source and owner, along with any affected documents. If the decision changes, the team can identify what needs review instead of relying on memory or an isolated drawing revision.
Modelling and document-control tools can support comparison, revision tracking and coordination reviews. They cannot determine whether an operating sequence makes sense for a specific facility or whether an apparent interface reflects the responsibilities agreed by the project team. That takes technical review and discussion among the relevant disciplines, informed by the project’s operational context.
No single checklist proves construction readiness for every project. Make the review proportionate to the system and its interfaces, and show both verified design information and remaining decisions. This gives the project team a sounder basis for judging completeness than drawing volume alone, while keeping the assessment focused on project-specific requirements.
A practical review sequence for RIBA Stage 4 automation design
A disciplined review moves from the design basis to coordinated information, then checks whether decisions are recorded and verifiable. For RIBA stage 4 technical design automation, the aim is not to apply a universal checklist. It is to give the project team a repeatable way to expose missing inputs, assess interfaces and manage changes before they affect later work.
Review requirements, assumptions and design inputs
Begin with the agreed requirements and design basis. For each control function, establish which requirement supports it, what inputs it relies on and whether any part of its behaviour remains an assumption. This gives the technical review a clear starting point and separates settled decisions from matters needing project-team agreement.
- Confirm the design basis. Trace each function to an agreed requirement or recorded project decision, and identify the source information used to develop it.
- Log assumptions and dependencies. Record missing inputs, external dependencies and the party or discipline expected to resolve each item. Note how an unresolved input could affect related design information.
- Assess requirement changes. Record the change, its origin and the decision owner, then review which control functions, interfaces and documents may need updating. Link the decision to the resulting revisions in the project information.
Verify interfaces, documents and design changes
Once the design basis is clear, review the information as a connected set. Compare architecture diagrams with functional descriptions and schedules, checking that system boundaries and stated functions agree. Ask relevant stakeholders and discipline leads to review interfaces, so comments can be resolved against shared design intent rather than in isolation.
- Check consistency. Select representative functions and follow them across relevant design documents. Confirm that descriptions, schedules and architecture information refer to compatible arrangements.
- Resolve interface comments. Record each issue, its owner, required input and status. Where disciplines disagree or information is incomplete, document the decision or retain it as an open action rather than implying agreement.
- Apply agreed verification criteria. Define project-specific review or verification criteria and record the evidence and outcome. Criteria should reflect the project’s requirements and responsibilities, not be presented as a universal set for all systems.
Architecture decisions need the same traceability as functional ones. Where IEC 61499 is relevant to the project’s chosen architecture, the IEC 61499 architecture guide provides context for considering how architecture relates to mission-critical systems.
AAC LTD | All About Control provides control-systems design and automation engineering consultancy across RIBA Stages 1 to 5, supporting teams as design intent moves through coordinated design and subsequent project stages. See how AAC LTD | All About Control supports automation engineering design.
How AAC Ltd carries automation design from RIBA Stage 4 towards delivery
Stage 4 decisions remain useful beyond the technical-design package when their purpose and basis stay clear as the project progresses. AAC LTD | All About Control provides control-systems design and automation engineering consultancy across RIBA Stages 1 to 5, supporting continuity from early requirements through detailed design and later project stages. This lifecycle perspective helps teams carry design intent forward instead of treating technical design as an isolated handover.
Maintaining design intent beyond technical design
As delivery progresses, the project team needs to understand what a design decision was intended to achieve, which assumptions informed it and whether later changes affect it. Keeping decisions, revisions and open items visible gives implementation teams a clearer basis for their work and helps inform planning for testing and commissioning. Stage 4 coordination supports that process, but cannot by itself guarantee operational performance or a successful commissioning outcome.
For example, if a control-system interface or operating sequence changes, the effect may extend beyond one drawing. Related functional descriptions, schedules and integration information may also need review. A traceable record helps the team assess the change against the original requirements and identify what needs updating, while keeping the rationale available to those progressing the design.
This continuity matters for mission-critical control systems, where design decisions need to reflect operational requirements and system integration. AAC LTD | All About Control’s work in demanding airport environments informs an approach that considers how control systems fit into a wider operational setting, without assuming that every airport or project has the same interfaces or priorities.
Applying specialist engineering to demanding environments
Aviation projects can involve complex relationships between building services, control systems and operational functions. The arrangements vary, so design coordination needs to reflect the facility’s requirements and the responsibilities agreed by its project team. AAC LTD | All About Control’s control-systems and SCADA integration services support teams in addressing those project-specific relationships as technical design moves towards delivery.
SCADA integration is relevant where a project requires supervisory monitoring or interaction between systems; define its role and interfaces for the particular application. AAC LTD | All About Control delivers to IEC/BS 61499, which should be applied in the context of the project’s architecture and agreed requirements rather than treated as a universal specification for every Stage 4 design.
The practical aim is a clear line from the original operational need to the coordinated design information used in later work. Project-specific reviews remain important as designs develop, but traceability gives stakeholders a stronger basis for understanding decisions, assessing proposed changes and planning subsequent activities. This is the value of RIBA stage 4 technical design automation within a lifecycle-led engineering process: design intent stays connected to the system being delivered.
For technical design support, discuss your automation engineering consultancy requirements with AAC LTD | All About Control.
Carry design confidence into the next stage
The value of RIBA stage 4 technical design automation lies not only in the information issued, but in whether its intent remains clear as the project moves forward. Treat each significant decision as part of a continuing engineering record, so later changes can be considered against the operational need they were meant to serve. That discipline gives project teams a clearer basis for progressing design and delivery.
For complex control environments, specialist perspective can help keep integration requirements in view. AAC Ltd is a Schneider Electric EAE Master Partner and UAO member, bringing relevant engineering experience to projects where control systems must support demanding operational needs.
If you’re planning a Stage 4 design or reviewing its readiness for the next phase, take a project-specific approach to the decisions and interfaces that matter most. Explore AAC Ltd’s control-systems design support.
Frequently Asked Questions
What is RIBA Stage 4 technical design?
RIBA Stage 4 is the technical-design stage in the RIBA Plan of Work 2020. For automation, it develops the project’s agreed requirements into technical information that supports the wider design. The scope depends on the project, procurement arrangements and design-team responsibilities. For instance, the division of information between the consultant and specialist suppliers can affect what is prepared at this stage, so refer to current RIBA guidance for formal terminology.
Does RIBA Stage 4 automation mean using software to create designs automatically?
No. In this context, automation generally means the control systems being designed, such as PLC-based controls and supervisory systems. Digital tools can assist with modelling, documentation and coordination, but they don’t determine whether a proposed sequence suits the building’s operation. Software may help organise equipment information, while engineers establish what a control function should do and how it fits the project requirements.
Can RIBA Stage 4 technical design change after it has been completed?
Yes. A change to the brief, new site information or a revised interface decision may require design documents to be updated. The project’s change-control arrangements should set out who assesses and approves changes. A practical record identifies the change, its reason, the documents affected and the current revision, so stakeholders can work from the same information and understand which earlier decisions have been superseded.
How long does RIBA Stage 4 technical design take?
There’s no standard duration that applies to every project. The programme depends on the design scope, complexity, availability of inputs, review cycles and time needed for decisions across disciplines. Automation work may rely on operational or engineering information provided by others, which can affect sequencing. Plan activities against agreed milestones, dependencies, review responsibilities and the project’s decision-making process rather than assuming a typical timescale.
Can Stage 4 automation design be developed for an existing airport system?
Yes, when the project scope includes modifying or integrating with existing systems. The design basis should account for available asset records, system interfaces and operational constraints. A practical starting point is to compare existing drawings and records with information gathered through project reviews or surveys, then log discrepancies for assessment. Legacy information may be incomplete, so the project team should manage resulting assumptions and design changes through its agreed processes.
Does a BIM model contain all the information needed for automation design?
Not necessarily. A BIM model can help represent equipment and support spatial coordination, but its contents depend on the project’s information requirements. It may not describe control behaviour, alarm intent or the detail of system interfaces. Related documents may therefore be needed to explain those aspects. Clear references and revision control across the model and supporting information help the team identify the current design basis.
