A window on the weather side of my house let in water during the first proper rain after we finished it. Moderate wind, nowhere near storm force. The water found the real-wood floor underneath, and the stain is still there.
The detail behind that window had gone through months of drawings and counter-drawings between my architect and the carpenter. Each side had its own reading of how the flashing, the sill and the timber should meet. We revised the drawing more than once. I remember thinking, at the time, that we were behaving like pioneers solving a problem of global significance, when in fact we were arguing over a window detail on a weather-exposed façade, a problem builders have faced for as long as there have been windows and weather.
When my architect and the carpenter inspected the damage, they shook their heads in disbelief. I understood the disbelief. What I could not get past was the boiling feeling underneath it: we had drawn this detail with real care, and it still failed on the first test.
I had suspected, before we built it, that someone somewhere had already solved this exact problem. I never asked whether a usable version of that solution existed anywhere I could find it. That is the part I keep returning to.
The gap is not that nothing exists
It would be wrong to say architecture has no repository of solved details at all. Detail catalogues, construction atlases and manufacturer system details all exist, the last tied to a given manufacturer’s own products and materials. None of that helped me, and the reason is worth separating into its parts rather than treating it as one vague absence.
The first part is discoverability. A window detail solved by an architect in the north of England, for a comparable climate and a comparable façade, was of no use to me in the south of Germany, because I had no way to find that it existed, let alone that it applied to my case. Catalogues organise by product line or by code compliance. Neither category captures the specific combination of exposure, material and joint that a given architect is facing.
The second part is liability. If I had found a detail from another project and used it, and it had failed anyway, who would carry that? The architect who drew it originally, for a building they never saw and conditions they never assessed? The architect who adopted it, for applying someone else’s solution without redoing the engineering? Nobody has settled that question, so the safer, and in practice the only, path is to draw everything again from the specifics of the job in front of you.
The third part is incentive. Even where an architect has a detail that works reliably, there is no structure that rewards sharing it. The time spent solving it was already billed once, to one client, on one project. Publishing it helps competitors and exposes the architect to the liability question above, for no offsetting benefit. So the solved detail stays in one office’s archive, and the next architect facing the same problem starts again.
What other fields do instead
Mechanical engineering settled an equivalent problem roughly a century ago, through standards and catalogued components. A ball bearing of a given size and load rating behaves the same way regardless of who specifies it or who manufactures it, because the standard fixes the specification and the catalogue makes the part findable. An engineer selects the bearing from a catalogue instead of redesigning it.
Software went through the same shift more recently, through open-source libraries and public APIs. Nobody writing a login screen builds the authentication logic from first principles. They build on a library that has already handled the edge cases, because the code is published, versioned and reusable, and because the norm in that field is to build on what exists.
Architecture has neither the standard nor the norm. A window detail is not a complex problem in the way a novel structural system might be. Weatherproofing a window follows physics that do not change from one building to the next. Sound insulation between two flats follows acoustic principles settled decades ago. These are exactly the kinds of details where reuse should be routine, and each project treats them as if they were being solved for the first time.
Three houses, the same start
I have built three houses. Each time, the process for resolving details like this one ran the same way: architect and tradesperson working it out between themselves, from scratch, with no reference to what had already worked elsewhere. Whether the result held up was, in a meaningful sense, left to chance.
The manufacturer-tied platforms that exist in architecture do not close this gap. They let a system supplier publish details for their own products, which is useful within that one supplier’s catalogue and useless the moment a project mixes materials or falls outside what that supplier sells. What is missing sits above any single manufacturer: a way for architects across firms and across countries to find each other’s solved details, know who is answerable when a detail fails and have a reason to publish the solution rather than keep it filed away.
Reuse would still mean adapting a detail to the specific building, the specific exposure and the specific materials in front of an architect. What would change is the starting point. Instead of a blank page and a debate that runs for months, the architect would start from a detail already tested against conditions like theirs, and spend the saved time on the parts of the building that are genuinely unique, instead of redrawing a solved problem under the pressure of a construction schedule.
The question I have not been able to put down since that first rain is why that exchange does not exist yet, given how old and how common this particular problem is. Until an architect somewhere can find the detail another architect already solved, the next window on a weather-exposed wall gets drawn from zero, and whether it holds through the first rain stays a matter of chance.