Most heavy-civil documentation fails for a boring reason: it is unstructured prose about structured things. An interchange is a graph. It has structures, spans, bents, bearings, girder lines, deck pours, phasing stages, traffic movements, inspection holds, and a construction calendar, all with relations between them. Storing that as a folder of PDFs throws the graph away and leaves you re-deriving it by hand every reporting period.
Shapezo's answer is to model the asset first and render prose second. Knowledge becomes typed objects with an explicit schema, and the project narrative is a build artifact of that model. This post walks through the architecture in plain language, because the discipline matters more than any particular toolchain.
The interchange object model
A Shapezo interchange model is deliberately small. Four entity families cover nearly every grade-separated project. The structure family describes each bridge in the interchange: type, span arrangement, pier and foundation system, deck system, and total length. The alignment family describes how the structures connect: ramp lines, mainline stations, vertical profiles, and the movements each line carries. The phasing family describes time: construction stages, open and closed movements per stage, detour routes, and the calendar windows that constrain them. The narrative family is the Shapezo-specific part, and it carries two fields that decide everything downstream.
The first is the narrative shape, selected from a fixed enum of four: the journey, which follows one driver across the finished levels; the build, which follows one pier from footing to bearing seat; the trade, which runs neighborhood impact and project benefit in parallel columns; and the service record, which states what the structure delivers to whom. The second field names the one or two anchor details the prose is allowed to go deep on, such as the rebar mat, the form traveler, the bearing pad, or the girder splice. Everything else stays at summary depth. That single constraint is what keeps generated narratives readable instead of exhaustive.
Rendering prose from the model
The renderer is a template per narrative shape. Each template is an ordered sequence of sections, and each section has slots bound to paths in the model. Nothing is free-form. If a required slot has no data, the section renders a visible placeholder marker rather than silently vanishing, so gaps surface in review instead of in publication. A phasing template whose traffic-handling section comes back empty is a review comment, not a surprise at the public meeting.
Because the output is deterministic for a given model, diffs are meaningful. A change to the phasing model shows up as a clean narrative diff in review, which is exactly where construction knowledge changes should be examined. Two reporting periods of the same structure differ only where the structure actually differs, which turns progress reporting into comparison instead of recollection.
The asset pipeline as a contract
Images are treated as build inputs with contracts, not decorations. Each structure declares three slots: establishing, structural detail, and consequence. The pipeline enforces geometry and weight on ingest: aspect ratio locked to sixteen by nine, resolution locked to 1280 by 720, file weight capped at 200 kilobytes, and no baked-in text or people, ever. The weight cap matters more than it sounds, because field records get opened on tablets at the edge of a work zone, on cellular links, in corridors where coverage is poor precisely because the structure blocks it. A 200 kilobyte budget keeps a full three-scene record under a megabyte.
The incremental launch below is a good example of an establishing asset: one frame captures the launching nose, the bearing pedestals, the rail yard being crossed, and the abutment jacking frame, conveying in a single view what six ground photographs would struggle to relate to each other.
Why the falsework view is the load-bearing shot
Of the three slots, structural detail is the one that pays for the pipeline, and for urban elevated work the falsework view is its best expression. Shoring tower configuration, deck form geometry, and bracing layout all change week to week, so a consistent falsework image doubles as a configuration baseline. Keeping it in the model means period-over-period comparison is a diff of images at a fixed viewpoint, not an archaeology project in a shared drive.
What you get
Model first, render second, and three things change. Documentation becomes reviewable, because model changes produce narrative diffs. It becomes complete, because empty required slots fail loudly instead of quietly. And it becomes cheap, because updating a structure next period means editing a handful of typed fields instead of rewriting prose from scratch.
Shapezo is not a document management system and not a static site generator. It is the discipline of deciding the shape of your content before you write it, plus just enough tooling to enforce that decision. For interchange construction, where the underlying asset is already a well-defined graph of structures, alignments, and phases, that discipline is almost unfair leverage.
Top comments (0)