THE OPERATING SYSTEM
How we work
What we do sets out the role and the capabilities. How we work sets out the operating system: the principles that shape decision flow on every project, the Common Data Environment that holds the project's information under the owner's control, and the four procedures that run inside every mandate.
FIRST
Operating principles
i.
A single line of governance.
Every technical and commercial decision moves up to one point of authority. No competing parallel chains, no decisions taken inside the design team or the contractor without owner-side project review.
iii.
Decisions move against fixed milestones.
At each milestone, the owner sees the cheapest option, the recommended option, and the cost, performance, and risk delta between them, before approving.
v.
Every change tested against three things.
Performance targets, investment logic, and operational requirements. A change that weakens any of them is either rejected or compensated, with the compensating mechanism contractually recorded.
ii.
Information sovereignty.
The project's data, models, and decision history live in an environment the owner controls and keeps after delivery. Service providers work inside it.
iv.
Performance-based, not prescriptive-minimum.
Performance targets defined at feasibility govern the design audit, the construction acceptance, and the handover validation. Where the asset's economics warrant performance above the regulatory floor, the targets are set above.
vi.
Decisions move against fixed milestones.
At each milestone, the owner sees the cheapest option, the recommended option, and the cost, performance, and risk delta between them, before approving.
Common Data Environment
The Common Data Environment is the project's information backbone.
Models, drawings, calculations, technical documents, decision records, change history, all of it lives in one structured environment under the owner's control.
First, the owner's information requirements (OIR, AIR, EIR) are defined at the start, from operational needs, not retrofitted at handover. Every transmittal entering the CDE is checked against them. AI-enhanced checks verify completeness at each milestone, so the handover document set is built up across delivery.
Second, the asset goes into operation with a complete digital and technical asset package, not a box of PDFs handed over in the closing weeks.
Third, the CDE standard carries from project to project. The folder logic, the metadata schema, the AI-check templates remain the same. For an owner running a portfolio, this is the difference between starting from scratch on each asset and inheriting a known operating standard.
SECOND
Procedures
Procedure one
Total Cost of Ownership
A comparative engine for the major design and procurement decisions. For each significant package, competing options are evaluated against their full lifecycle cost: capital cost, energy, maintenance, expected component life, replacement cost, residual value, available incentives, and operational risk.
The cheapest purchase price is one input among many. A more expensive system that lowers lifecycle cost will be approved, and the financial logic is recorded.
Where the cost difference between options crosses a project-specific threshold, the comparison runs: energy price escalation, discount rate, replacement timing, occupancy variance.
The same logic governs change control through construction. Every major change request carries a lifecycle cost delta, not only a CAPEX delta.
Procedure two
CAPEX-to-OPEX continuity
Where Total Cost of Ownership compares options, this procedure builds and protects the project-level operating cost projection. At feasibility, the projected operating cost is fixed against the investment thesis. As packages are decided through the option-level comparison, their outcomes feed into the project's operating cost forecast. The forecast is the baseline.
Through design and construction, the cumulative changes between the approved baseline and the current project state is tracked. Each change with an operating cost impact triggers a recalculation. At any point we see, how far the project has moved from the operating cost the business plan assumed.
The result is that Net Operating Income and Yield on Cost remain a live measurement, and not a feasibility-stage assumption.
Procedure three
Smart Building Scope
What a project owner needs to monitor in operations is not a function of what sensors are available, but what decisions the owner needs to make.
This procedure defines the monitoring scope decision-first. Energy strategy, comfort tuning, maintenance prioritisation, system replacement timing, sustainability reporting - each of these requires specific data at specific intervals.
The monitoring scope is sized: which systems are instrumented, which data points are captured, at what frequency, into which dashboards.
Performance reads, energy reads, comfort reads, fault alerts, all of it sits in an environment the owner can read directly. The facility manager operates the building. The owner reads the asset.
This is independence in operations: the owner is not relying on the service provider's narrative to know how the asset is performing
Procedure four
Building Performance Governance
Performance targets are set at feasibility for comfort, energy efficiency, system resilience, and maintainability. Each target has a numeric value and a verification method.
Design packages are audited against the targets, not against the regulatory minimum. Compliance with current energy regulations is necessary, but not sufficient.
Through construction, the targets are protected against material and technology substitutions. At handover, commissioning verifies that systems perform under real operating conditions (not against the model that justified the building permit).