The roadmap writes itself

Software moves fastest where the work is enumerable

Where the work is enumerable. The professions software has reshaped fastest share one trait: their output could be named and counted before the software arrived. Accounting closes its books through a fixed set of statements and schedules. Legal work, for all its judgment, produces recognisable document families with known structure. Code is the extreme case, work that is itself text, with a hard test for whether it holds. In each field the same thing happened: once one work product was handled well, the next instance of it was already handled, and progress accumulated.

The inverse holds too. Where every assignment is one of a kind, nothing carries from the last job to the next, and software stays at the margins: a search box here, a template there. So the strategic question for an industry is not how hard the work is. Aviation is hard, chip design is hard, and both are thoroughly industrialised. The question is whether the work can be listed.

A finite list of deliverables becomes the roadmap

Civil engineering can be listed. A large infrastructure project produces thousands of documents, but sorted by type the pile collapses to roughly 60–80 recurring written deliverable types for Nordic infrastructure, every one of them already named in the industry's own classification systems. We walked through that collapse, and the public systems that maintain the list, in civil engineering is a finite catalogue.

The consequence is a clean unit of progress: one deliverable type is one capability. A noise assessment has a known structure and known review criteria, set by the same governing documents on every project. Understand it deeply once and the understanding carries to nearly every project in the country, because nearly every project needs one. The same holds for the stormwater study, the technical specification written to AMA, the inspection plan. A type mastered stays mastered; nothing has to be relearned on the next project.

One boundary keeps the list honest. It covers the written deliverables: the studies, descriptions, specifications and plans where the documentation hours sit. Drawings are a different craft. A capable system reads drawings and checks them against requirements, and that is enough; authoring CAD is not on this list, and the list is worth working through without it.

The types compose into whole statutory packages

This is where it compounds, because the types are not flat. The heaviest deliverables in infrastructure are not single documents but assemblies. A road plan, the statutory submission that gives a road project legal force, is built from dozens of smaller deliverables, most of them ordinary entries from the same type list. The railway plan follows the same logic, and so does a tender package.

Read the rows against each other and the mechanic appears: the same component types recur across the assemblies. Master the noise assessment and you hold a piece of the road plan, the railway plan and the environmental impact assessment at once. Each new component capability advances several packages simultaneously. And past some threshold the work changes character: producing an entire statutory package stops being new ground and becomes assembly of parts already mastered. No single-purpose tool gets there, because no single-purpose tool accumulates the parts.

A visible endgame is rare, and this one is countable

Because it is rare. In most knowledge work nobody can see the end from the start; the work mutates faster than anyone can map it. Here the remaining work can be counted. So many types on the list, so many handled, so many left. A second axis keeps score as well: every project moves through the same phases, from early planning through detailed design to as-built records, and every type belongs to a known phase. Coverage can be measured in two directions, by type and by phase, and both lists are finite.

That is an unusual position for a technology to stand in. Most product roadmaps are guesses about what users might want next. This one is a published list of what regulation and practice already require, maintained by the industry itself, in an order the composition logic largely settles: components first, assemblies as they come within reach. The endgame, entire statutory packages drafted and checked at machine speed with the engineer holding the last word, is visible from where the industry stands today. At Yesper, the AI civil engineer for construction and infrastructure, this is literally the roadmap on the wall: one deliverable type at a time, in the industry's own order.