Delivery model
The equipment sets the ceiling on how fast a single repair can be completed. Everything else — allocation, clustering, sequencing, working windows, evidence — determines how close a programme gets to that ceiling.
The problem
None of these are failures of effort. They are structural consequences of how work is allocated and sequenced.
The design objective
Stonegate Infrastructure is built to maximise these specifically, because they are what a client is actually buying.
Together they describe best value in practical terms. Highways budgets are public money and must demonstrate measurable value, so the objective is to increase the useful maintenance output achieved from the expenditure available — not simply to hold the lowest rate on a schedule.
We do not publish target figures against these measures. Any numbers offered now would be projections rather than performance. Baselines and targets are established with the client at the start of a programme, and reported against thereafter.
Commercial model
This division matters, and we want to be precise about it. It is not a request for the client to hand over control of their network.
Intervention levels, inspection regimes and defect categories are set by the highway authority under its own risk-based maintenance policy, consistent with the UK Roads Liaison Group code of practice for well-managed highway infrastructure. Nothing in this model changes that.
The client remains responsible for
Stonegate Infrastructure is responsible for
Where the commercial model permits, Stonegate Infrastructure takes ownership of delivering the agreed programme within the scope, standards and service levels the client sets — rather than supplying labour and plant to be directed job by job. Programme level allocation allows delivery to be optimised far more effectively than isolated daily job assignment.
Where it does not, we work within whatever allocation model the contract specifies. The optimisation described here is an opportunity to be discussed, not a precondition of engagement.
Worked example
An illustration of how a released pool of approved defects becomes a sequence of deliverable working days.
The figure below is used to illustrate the method. It is not a description of a contract held or work completed.
500 approved defects released as a single programme
Continual improvement
Programme data is only worth capturing if it changes how the following programme is planned.
The records produced during delivery describe where the working period actually went. Reviewed across a programme rather than a single day, they identify:
The output of that review is practical: a revised approach to clustering, sequencing, crew allocation or working windows for the next release of work. It is operational learning rather than analysis for its own sake.
On innovation. We apply technology where it improves the physical delivery outcome — how work is allocated and routed, how plant is utilised, how evidence is captured and how quality is assured. Software that does not change what happens on the carriageway is administration, not innovation, and we do not present it as such.
Working windows
On some parts of the network, the productive constraint is traffic rather than daylight.
A defect on a busy arterial route may be straightforward to repair but difficult to access safely during the day. The same defect in an evening or off-peak window can be completed with less disruption and higher productivity, provided the working arrangements, lighting and traffic management are appropriate.
Working windows are therefore treated as a variable in programme design rather than a fixed assumption — always within permitted hours, noise constraints and the conditions attached to the relevant permits and approvals.
Next step
The larger and more geographically defined the pool, the more there is to optimise. We are happy to talk through how a specific programme would be sequenced.