What is infrastructure for?
A reflection on the question beneath our practical work. Infrastructure is usually justified by what it enables. We think it is better judged by what it makes unnecessary to trust.
Our published work is deliberately practical: audit provisions, procurement clauses, measurement protocols. This series is for the questions underneath it, which are less settled and which we would rather examine in public than resolve privately.
Start with the obvious one. What is infrastructure for?
The enabling answer, and why it is not enough
The standard answer is that infrastructure enables. Roads enable movement, courts enable the resolution of disputes, payment systems enable exchange. On this account infrastructure is instrumental and largely neutral: it is a means, and the moral weight sits with the ends people pursue through it.
This is true and insufficient. It cannot explain why some infrastructure feels like freedom and some like confinement, when both enable a great deal. A payment system that enables exchange while recording every transaction enables and constrains in the same motion. The enabling account has no vocabulary for that, so it tends to treat the constraint as an unfortunate side effect of the enablement rather than as part of what was built.
A second answer: infrastructure removes the need for trust
Here is a proposal we find more useful. Good infrastructure reduces the number of people you have to trust in order to go about your life.
Consider what a reliable water supply does. It is not merely that water arrives. It is that you need not know, assess or trust anyone in the chain that delivers it. You need not evaluate the competence of the treatment engineer or the honesty of the pipe contractor. The infrastructure has absorbed those judgements so that you can stop making them. That absorption is the service. The water is almost incidental.
Infrastructure earns its name when it lets you stop paying attention.
On this account, infrastructure fails not when it stops working but when it starts requiring vigilance. A payment system you must monitor for unauthorised charges has failed as infrastructure even while functioning as a service. A benefits system whose decisions you must check has transferred the work of assessment back to the person least equipped to do it — which is precisely the work it was built to absorb.
Why this matters for what we build now
Most digital systems presented as infrastructure fail this test badly. They require constant attention: reviewing permissions, checking statements, contesting decisions, managing consent, watching for changes to terms. Each demand is individually small. Collectively they represent a large transfer of cognitive labour from the institution to the individual, justified as choice and experienced as burden.
The test we would like to apply is uncomfortable, because our own recommendations sometimes fail it. When we call for transparency, we are frequently calling for more information for a person to evaluate. When we call for consent, we are asking them to make a judgement they have no basis for. Those are improvements on concealment, and they are not the same as infrastructure absorbing the judgement so nobody has to make it.
We do not have a resolution. We suspect the honest position is that transparency and consent are transitional remedies — necessary while systems are untrustworthy, and a sign that they still are. The mature version would be systems that need not be watched, and institutions that answer for them when they fail. That is a considerably more demanding ask than a disclosure obligation, which may be why it is made less often.
These reflections are provisional and will be revised. If you think the argument is wrong, that is the most useful thing you can tell us.
