Who Maintains Shared Infrastructure?

Infrastructure is a service through time

Infrastructure easily draws our attention to the moment of construction. A new road, bridge, channel, warehouse, vehicle or communications network has a visible price and a visible result. Less visible are the decades of inspection, cleaning, lubrication, patching, calibration, replacement, winter service, upgrading and eventual renewal. The OECD therefore treats infrastructure management across the whole asset life cycle: planning, construction, operation, maintenance, renewal and end of life.

That changes how a new project should be judged. If a community can raise construction money but lacks the people, skills or stable revenue for maintenance, it has not acquired a cost-free asset; it has acquired a future obligation. The European life-cycle costing approach explicitly includes operation, spare parts, maintenance and end-of-life costs rather than looking only at the purchase price.

The first rule should therefore be simple: do not create a shared asset without knowing how it will be maintained. For some assets that means a few hours of volunteer work each year. For others it means certified specialists, 24-hour on-call capacity, spare parts, a service contract and a multi-year renewal fund.

Owner, operator and maintainer are not necessarily the same

One of the most common mistakes in shared infrastructure is to compress every role into the word “owner”. An owner may set the long-term purpose of an asset without operating or repairing it every day. A municipality may own a road while a public company or concessionaire performs routine maintenance. A cooperative may own a warehouse while specialist firms service technical equipment. A community may operate a local communications network while another operator supplies the wider connection.

Clear accountability improves when at least six roles are separated: who defines the need and service standard; who owns or holds the asset; who operates it day to day; who performs maintenance and repairs; who provides the money; and who verifies condition and performance. Critical infrastructure adds a seventh role: who leads the response during an emergency.

These roles may be combined in one organisation or distributed among several. No arrangement is automatically freer or more efficient. The problem appears when roles are vague: users assume the owner is responsible, the owner points to the contractor, the contractor points to the contract, and the budget contains no reserve for major repair. Distributed delivery requires clearer accountability, not less accountability.

Maintenance cannot be the leftover of the budget

New infrastructure is politically and psychologically easier to see than well-maintained existing infrastructure. An opening ceremony is an event; preventive inspection is not. Maintenance is therefore easy to postpone until a small problem becomes large enough to require expensive rehabilitation. The World Bank and OECD warn that deferred maintenance shortens asset life, raises failure risk and can shift costs from relatively cheap routine intervention to much more expensive renewal.

R73 already showed that financing a common function rarely reduces to one instrument. R79 adds the time dimension: part of revenue must cover current operations, part routine maintenance, part periodic renewal and, where appropriate, a reserve for failures. If everything is pooled into one undifferentiated pot, it is easy to fund today’s service by leaving tomorrow’s user an exhausted asset and no renewal fund.

Larger systems therefore benefit from a simple asset register: what exists, what condition it is in, which service level it must provide, when it was last inspected, which interventions are planned and what future liabilities are approaching. This need not become heavy bureaucracy; it needs to be a memory better than the memory of one caretaker.

A road shows the difference between daily work and major renewal

Roads are a useful example because the word “maintenance” hides very different tasks. Routine work includes condition checks, drainage, signs, vegetation, minor repairs, winter service and clearing the consequences of accidents or storms. Renewing pavement, a bridge or a retaining wall is a different category: it requires more capital, design work, specialised execution and usually longer planning.

Slovenian practice illustrates the nested logic. State roads are managed through state-level systems and concession areas, while municipal roads fall under local responsibility; routine road maintenance is an organised public function with defined standards. This does not mean that every task must be performed by a civil servant. It means that someone must clearly be responsible for keeping the route safe and passable even when a contractor is late or an emergency occurs.

The same applies to local transport. A vehicle does not become a transport service merely because a community buys it. It requires drivers, registration, cleaning, tyres, servicing, a timetable, a replacement vehicle or an agreement for breakdowns. Infrastructure is therefore better described in terms of providing a service level than merely possessing an object.

Waste and logistics are chains, not single locations

With waste, responsibility is often visible only at the bin outside a house, while the actual service is a chain: collection, transport, transfer, sorting, preparation for reuse, recycling, treatment and final disposal. Slovenia treats municipal waste collection as a mandatory municipal public service, and operators also report collected quantities and what happens to them afterwards. That matters because the service is not finished when waste disappears from sight.

The same logic applies to logistics more broadly. A community may locally maintain a collection point, warehouse, cold store, delivery vehicle or small distribution hub, but the value of those assets depends on onward links. Without a carrier, backup vehicle, road access, fuel, information system or partner able to receive the shipment, a local hub quickly becomes a dead end.

Logistics should therefore be assessed as the entire service path and the points where responsibility changes hands. Who accepts the goods or waste? When does the next operator become responsible? What happens if one link fails? R88 will later ask at which scales larger networks are justified; R79 only requires that the operational chain contain no unnamed gaps.

Communications need a local hand and a wider connection

Digital infrastructure shows that local maintenance and wider connection are not opposites. The ITU describes community-network models in which a local community deploys or operates the last mile and takes responsibility for part of its maintenance, while a larger operator provides backhaul. Such arrangements can be useful where a commercial operator would not otherwise build affordable access.

Communications become especially critical when something else goes wrong: flood, fire, earthquake, power failure or another disaster. The ITU therefore treats redundancy, rapid outage detection, repair and alternative connections as core parts of resilience. A local group that can replace a power supply or restore an access point has more capability than a completely passive customer, but it still needs wider backbone capacity, backup power, equipment and people with deeper specialist skills.

This suggests an important rule: keep maintenance local where proximity improves speed, knowledge and accountability; keep specialist support reachable where complexity exceeds local capacity.

Contracting out delivery does not contract out responsibility

A community, municipality, cooperative or other body may maintain infrastructure itself, entrust it to a public company, contractor or concessionaire, or combine several providers. Outsourcing is neither the same as privatising accountability nor proof of efficiency. The key question is what the agreement requires and who can verify delivery.

A sound infrastructure contract should therefore specify more than price and task. It should define service levels, response times, inspection frequency, documentation duties, spare-parts standards, emergency procedures, reporting, responsibility for failure and handover requirements if the provider leaves. European life-cycle costing rules also highlight why the lowest purchase price is not necessarily the lowest total cost when later operation, maintenance and replacement are included.

A particularly dangerous dependency arises when a provider leaves with the documentation, passwords, plans, configurations or exclusive access to spare parts. The community may formally own the infrastructure while being practically unable to replace its caretaker without major cost. Contracts should therefore protect the ability to change providers and preserve institutional memory.

Many failures become organisational before they become technical

Infrastructure can fail because of material fatigue, weather or accidents, but many breakdowns begin earlier in organisation. Nobody has a complete asset list. Inspections are not recorded. A small defect is postponed for months. Only one supplier has a critical spare part. A contract says nothing about response time. A renewal reserve is spent elsewhere. An experienced maintainer leaves and the knowledge leaves too.

The opposite error is excessive duplication. If every small community attempts to hold every specialist machine, expert and reserve by itself, it may pay for idle capacity most of the time. A nested model can therefore be more resilient: local people know the assets and perform routine tasks, several communities share a specialist or equipment, and a wider level provides rare capacities for major failures.

R79 deliberately does not prescribe the correct scale for every sector. That question returns in R88. Its test is operational: does every task have a clearly responsible level, sufficient skill, sufficient finance and a realistic fallback plan? If not, the system is fragile whether it is public, private, cooperative or community-run.

A practical audit of shared infrastructure

For one road, vehicle, collection centre, warehouse, local network or other shared asset, a community can perform the following audit:

1. What is the actual service? Not “we own a van” but, for example, “we provide transport to the clinic for older residents five days a week.”
2. Who holds the asset and its documentation? Where are plans, contracts, warranties, passwords, manuals and maintenance records?
3. Who is operationally responsible? Who checks day to day that the service is working?
4. Who maintains it and who can repair a major failure? Separate routine work from specialised intervention.
5. What service level do we expect? Availability, safety, response time, cleanliness, passability, capacity or another measurable result.
6. How do we finance the life cycle? Operations, routine maintenance, major renewal and contingency reserves are not the same budget item.
7. What does asset condition tell us? When was the last inspection and which renewal is approaching?
8. What happens when it fails? Who is on call, what alternative exists and how quickly can it be activated?
9. Can we replace the provider? Do we control the data, equipment, configurations and open standards needed for handover?
10. Which task is better shared at a wider level? A specialist, heavy equipment, laboratory, backup centre, backbone connection or larger treatment facility?

If nobody can answer several of these questions, the first problem is not technological. The community has an asset but not yet a system of stewardship.

Shared means someone must be named

A free and decentralised community does not become resilient simply by moving an asset closer to people. Proximity can improve transparency and response, but it can also expose missing skills, finance or role clarity. The same is true of centralised systems: a large organisation can pool expertise and reserves, but it can create distant accountability, slowness or one large point of failure.

R79 therefore returns to a simpler principle. Every shared infrastructure system needs a steward of the function, a maintenance plan, a financing mechanism, a record of condition and a fallback path when failure occurs. Ownership matters, but ownership alone keeps nothing passable, clean, safe or connected.

A commons without named care becomes an abandoned commons. Shared infrastructure with clearly distributed responsibilities can remain shared without requiring one permanent master. The measure of mature self-organisation is not how many things we own together, but how many shared things we can keep functioning over the long term.