Design Automation Platform

Description

Severn Trent requires a commercial, off-the-shelf SaaS platform that is capable of automating preliminary design for water and wastewater treatment infrastructure. The current approach to early-stage design requires manual calculations and analysis of varied datasets, followed by document production for design reviews and governance, resulting in inefficient ways of working and substantial design rework. We require a design solution to bring automation to this end-to-end process, helping our design teams quickly produce and evaluate design options, accelerating the overall design process. The platform must combine all of the following capabilities within one solution (not delivered as separate, disconnected modules): 1. Domain Depth & Embedded Engineering Knowledge: These requirements ensure the solution is a true engineering platform - not a custom tool or services proxy. Engineering standards, heuristics, and design rules must be explicitly encoded within the platform itself, rather than inferred from documents, learned from examples, or left to user judgement. 2. Native support for water and wastewater treatment assets: The platform must natively support water and wastewater treatment infrastructure. This includes process-driven layouts, unit process sequencing, equipment sizing, and regulatory or code-driven constraints, without requiring custom modelling or scripting. 3. Standards-driven and deterministic behaviour: Design behaviour must be governed by explicit engineering standards and schemas, producing consistent, explainable results that do not vary run-to-run based on prompts, user phrasing, or probabilistic inference. 4. Governance, Auditability & Long-term Use These requirements differentiate a durable system of record from point tools or one-off solutions: Auditable design history The platform must maintain a persistent, reviewable history of design inputs, assumptions, changes, and outputs suitable for regulatory review, capital planning, and financial or technical audits. Separation of design logic from deliverables Engineering logic must be independent of output formats, allowing the same design logic to be reused across projects, asset types, and downstream tools without re-authoring or re-engineering. Proven owner-operator adoption The solution must be designed for use by asset owners or utilities - not solely by consultants or contractors - to support internal planning, option evaluation, and decision-making. 3. Time-to-Value & Immediate Usability Services-led or custom-built solutions have been determined to be unsuitable, preferring pre-existing : Operational on day one without custom development The platform must be immediately usable upon subscription by owner or utility staff, without vendor-led customisation, bespoke development, or extended onboarding projects. Hours-to-design, not weeks-to-prototype The system must generate complete preliminary designs withing hours or days, not weeks, for new projects without incremental setup effort. Repeatable use without vendor dependency End users must be able to execute new projects and iterations independently, without reliance on the vendor to execute and / or to enhance usability. 4. Design Outputs and Data Requirements These requirements focus on what the system produces, not how it may be marketed: Design-grade, structured engineering data The platform must generate machine-readable, structured engineering data representing process units, equipment sizing logic, and interdependencies - alongside standard outputs such as PDF and BIM - suitable for downstream modelling, costing, and authoring systems. Traceable assumptions and documented logic Each design must include explicit, inspectable assumptions and rules (e.g. design criteria, applied standards, constraints), supported by in-platform technical documentation sufficient for internal validation and regulatory review. Multi-option, directly comparable designs The system must produce multiple complete preliminary design options while using a consistent structure that enables direct comparison of cost, footprint, performance, and risk. The platform must be a proven, commercially available product - not in early development or awaiting first deployment - and should have demonstrated successful results with other water companies within the UK and particularly with other WASCs. Severn Trent already have a piece of critical software proven and in place, so will only consider products that offer the same functionality today; there will be no opportunity for ramp-up development. It must also integrate seamlessly with core utility systems where required (e.g., Common Data Environment).