A large infrastructure project produces thousands of documents, more than any team can read. But those thousands collapse into roughly 60–80 recurring document types, each a named, standardized deliverable the industry has already defined. Finite and standardized is exactly what a system can be built to work through, type by type. The pile is smaller than it looks.
The volume
Thousands. The document register of a large road or rail project runs into thousands of individual documents and revisions. Early planning produces the studies: traffic, noise, stormwater, geotechnics, environmental impact. Detailed design produces the technical descriptions, the bills of quantities, the inspection plans. Handover produces the as-built records and the operation and maintenance documentation. Each phase feeds the next, from the first feasibility study to the day the asset is handed to the maintainer, a sequence we walked through in how infrastructure actually gets built.
At that volume, complete review is out of reach. No engineer reads every document on a large project, and no reviewer checks every revision against every governing requirement. The pile keeps growing, too: each review round adds revisions, and each design change ripples into a dozen affected documents. Teams sample, prioritise and trust the process. Counted as instances, the documentation of infrastructure genuinely is unmanageable by hand.
The types
Far fewer than it feels like. A noise assessment for a road in Skåne has the same structure as a noise assessment for a rail line in Norrbotten. The same goes for a stormwater study, a geotechnical report, a technical specification written to AMA, a bill of quantities, an inspection plan, a health and safety plan, a risk assessment. Each is a named, standardised artifact with a known structure, known governing documents and known review criteria. Sort a project's thousands of documents by type and the pile collapses: counting the written deliverables (the studies, descriptions, specifications, schedules and plans, as distinct from the drawings), roughly 60–80 document types cover Nordic infrastructure, and a few hundred cover the industry as a whole.
The people who deliver these projects say the same about their own work: the large majority of Trafikverket projects are standardised and repetitive, following the same approach and the same governing documents, project after project.
Standardised and repetitive is not a complaint. It is what makes a road safe to open and a railway safe to run: the same document types, produced to the same requirements, reviewed against the same criteria, project after project.
The map
The industry did, and it keeps the list maintained. Every deliverable type in European infrastructure is already named and organised in public classification systems. Uniclass 2015, the British system, devotes an entire table to project documents, sorted into groups and sub-groups down to individually named types. Trafikverket's governing document TDOK 2012:35 enumerates the deliverables of Swedish infrastructure: the studies, technical descriptions, reports and maintenance documentation that make up a road plan, a railway plan, a system design and a construction document set. CoClass, the Swedish classification system, structures the built assets those documents describe. The RIBA Plan of Work organises deliverables by project stage, from briefing to handover. And ISO 19650 standardises how the whole information delivery is specified, produced and handed over.
None of this is obscure. These are the systems the industry already uses to name files, structure archives and write contracts. Open the document plan of any ongoing Trafikverket project and the same type names appear, in the same order, as in the last one. The catalogue is not a proposal for how the work could be organised. It describes how the work is organised today.
Why it matters
That is the whole point of finite. If the deliverables of infrastructure were endless in variety, no tool and no team could ever get on top of them. They are not: every deliverable is already enumerated in the industry's own classification systems, produced to the same standards and reviewed against the same criteria, project after project. A defined, standardized set is exactly what an AI civil engineer can be built to work through, one type at a time.
Each entry on that list is a bounded, repeatable piece of work. A noise assessment is a known artifact: understand it once, deeply, and that understanding carries to every project that needs one, which is nearly all of them. The same holds for the stormwater study, the technical specification, the inspection plan. And the large statutory packages, the road plans and railway plans, are not extra work on top of the list. They are assemblies of the same smaller types.
That is the hopeful part. The document mountain no one can read is built from a short list of well-defined parts, and the industry itself wrote the parts list and reviews against it every day. So "help with every kind of document" is not a fantasy; it is a finite target: thousands of instances, a few dozen types, one catalogue an AI civil engineer can work through to the last row. Where that leads, we followed in the roadmap writes itself.
Yesper is the AI civil engineer for construction and infrastructure. AFRY, COWI, NRC Group and other Nordic firms use it to halve the time on a study, rerun calculations in minutes, and catch errors that would otherwise slip through. Get in touch if you'd like to see what it can do for you.
Book demoGet the next piece in your inbox. Unsubscribe anytime.
