A dock looks simple from the deck and becomes a graph the moment you open the file. Piles belong to bents, bents belong to pile groups, caps span bents, decking spans stringers, stringers sit on caps, fenders hang off the outboard face, and mooring hardware anchors to whatever can take the pull. GenAnywhere, the content-shaping persona we use for infrastructure platforms, models this graph explicitly as typed entities so that every paragraph, table, and drawing reference in a dock document resolves against the same structure. This post walks through that entity model, the invariants that keep it honest, and the renderers that turn it into prose, inspection packets, and asset pipelines, all in plain language.
The Core Entities: Berth, PileGroup, Bent, Cap, Deck, FenderSystem, MooringPoint
At the top of the model sits the Berth, the entity that owns the water: design depth, tidal or stage regime, bottom material, exposure class, and the vessel envelope the dock must serve. The Berth does not describe structure; it describes the environment the structure argues with. Beneath it, the PileGroup collects every pile under the dock and records the driving logic: spacing along the berth, spacing across the berth, batter angles at the fender face, embedment, and species or gauge. Bents are cross-frames of piles, the transverse slices a designer thinks in, and each Bent references its piles and carries its own cap. The Cap entity spans a bent and records section, bearing details, and splice locations. The Deck entity owns everything a foot or wheel touches: decking material and direction, stringer layout, edge treatment, wheel guards, elevation, and rated live load. FenderSystem and MooringPoint hang off the outboard edge: the first records sacrificial elements, energy rating, and replacement interval; the second records bollard or cleat type, capacity, and the load direction it is meant to take.
Appurtenances as First-Class Citizens
Real dock files rot in the appurtenances. Gangways, floats, ramps, ladders, crane rails, power pedestals, and pipework get mentioned once in a memo and never again. In the GenAnywhere model each is a typed Appurtenance entity with a host reference to the Deck or Bent it attaches to, a movement class (fixed, hinged, floating, sliding), and its own inspection interval. The movement class is the detail that pays off: a hinged gangway and a fixed ladder age in completely different ways, and any renderer that produces an inspection checklist needs to know which verbs apply. Utilities carried on the structure become Conveyance entities with a route across bents, so a pipeline crossing a petroleum pier is queryable instead of anecdotal.
The Invariants That Keep the Model Honest
Typed entities are only as good as the rules between them, and GenAnywhere enforces a small set of invariants at authoring time. Every Deck must resolve its load path to at least one PileGroup through an unbroken chain of stringer, cap, and bent references; a deck whose load path dead-ends is a documentation defect, not a style issue. Every MooringPoint must declare a capacity and a governing load direction, and every FenderSystem must declare a replacement interval, because a sacrificial element without an interval is a hidden liability. Every Appurtenance with a floating or hinged movement class must reference the tidal or stage range from its parent Berth, which forces the author to confront range before specifying slope. And every entity carries a provenance stamp: survey, design record, inspection, or inference. Inference is allowed; unlabeled inference is not. These invariants are what let a renderer promise completeness: if the graph validates, the generated packet has no silent holes.
Renderers: Prose, Packet, and Pipeline
The same graph renders three ways. The prose renderer walks the load path in narrative order, Berth to PileGroup to Bent to Cap to Deck to FenderSystem, producing the readable document that councils and crews actually finish; it pulls wear patterns from inspection history so the narrative describes the dock that exists rather than the dock that was designed. The packet renderer flattens the graph into an inspection checklist ordered by element number, embedding photograph references and rating scales inline so a field inspector never guesses what a number means. The pipeline renderer emits the asset story: for each entity it produces the identifiers, the revision, and the references that a drawing set or geographic system needs, keeping documents and drawings pointed at the same truth. Because all three renderers read one graph, a corrected pile spacing propagates to prose, checklist, and drawing references in a single edit.
Why the Entity Model Beats the Folder of Memos
The alternative to a typed model is the folder: memos, spreadsheets, photographs, and a drawing set that disagree in quiet ways. The folder cannot answer simple questions like which berths have fender elements past their replacement interval, or which gangways were specified against a tidal range that a later survey revised. The graph answers both in one query, because the facts live in one place with provenance attached. For platform teams, the model also fixes the content supply chain: every article, packet, and public page about a dock resolves its claims against entities instead of against whoever wrote last. Docks are long-lived structures maintained by short-tenured teams; the kindest thing a content architecture can do is make the structure's memory explicit, typed, and queryable. That is the whole GenAnywhere argument in one sentence: model the dock as the graph it already is, and the documentation stops being an opinion.
Top comments (0)