DEV Community: GeoGenius

Modeling Signal Towers as Typed Entities: GenAnywhere's Content Architecture for Sites, Structures, and Spectrum Paths

GeoGenius — Fri, 23 Oct 2026 08:15:35 +0000

A signal tower site looks like a single object from the highway and becomes a graph the moment you open its file. The foundation anchors a structure; the structure carries frames; frames carry antennas and dishes; antennas own azimuths and coverage polygons; dishes own paths to distant endpoints; cables bind radios in shelters to everything above; and a regulatory envelope wraps the whole assembly in lighting, marking, and consultation obligations. GenAnywhere, the content-shaping persona we use for infrastructure platforms, models this graph explicitly as typed entities so that every paragraph, checklist, and drawing reference in a tower document resolves against one structure. This post walks the model, its invariants, and its renderers in plain language.

The Core Entities: Site, Structure, AntennaSystem, MicrowavePath, FeedRun, Compound, RegulatoryEnvelope

At the root sits the Site, the entity that owns the ground: coordinates, elevation, exposure category, ice and wind zones, flood status, and seasonal access rules. The Site describes the argument the structure must win, not the structure itself. Beneath it, the Structure entity records type (lattice, monopole, guyed, or stealth), height, section geometry, foundation type, coating system, and design loads; a guyed Structure additionally owns GuySet entities with anchor locations and tensions. AntennaSystem entities hang off the Structure at named centerlines: each carries sector azimuth, radial coverage, mount type, and the radios it serves. MicrowavePath is the entity most tower files forget: a typed link between two dishes with endpoints, frequency band, and path clearance notes, so a retired path leaves a record instead of a rumor. FeedRun entities trace cable from radio to antenna with grounding and surge details. The Compound entity owns fence, shelters, power service, backup, and aviation lighting controller. Finally, the RegulatoryEnvelope wraps lighting and marking specification, environmental determinations, and permit identities with expiry dates.

Stealth and Colocation as First-Class Types

Stealth is not a footnote; it is a structural type with consequences. In the GenAnywhere model a stealth Structure carries a concealment class (parapet-hidden, flagpole, light-standard, steeple, monopine) and a disclosure flag, because concealed assets fail differently: maintenance access, visual inspection intervals, and public communication all change with the costume. Colocation is modeled the same way: each tenant is a Tenant entity owning its AntennaSystems and FeedRuns against a shared Structure, with load contributions recorded per tenant so the structure's total load is always the sum of named parts rather than a remembered number.

The Invariants That Keep the Model Honest

Typed entities earn trust through the rules between them, and GenAnywhere enforces a small set at authoring time. Every AntennaSystem must resolve its mount to a Structure centerline and its coverage to a polygon anchored in the Site's coordinate frame; an antenna floating without a centerline is a documentation defect. Every MicrowavePath must reference dishes at both endpoints and declare clearance status, because an undocumented path endpoint is how interference investigations begin. Every Structure must reconcile its design load against the summed tenant contributions, and any drift beyond tolerance raises an exception a structural engineer must clear. Every guyed Structure must reference its GuySet anchors inside the Site boundary, and every RegulatoryEnvelope lighting specification must match the Structure height class. And every entity carries provenance: survey, design record, inspection, or inference. Inference is permitted; unlabeled inference is not. These invariants let a renderer promise completeness: a validated graph has no silent holes.

Renderers: Prose, Checklist, and Registry

One graph renders three ways. The prose renderer walks Site to Structure to AntennaSystem to MicrowavePath, producing the readable site narrative for planners, carriers, and public comment; it pulls observed wear from inspection history so the narrative describes the tower that exists. The checklist renderer flattens the graph into a climb or drone inspection order by element number, embedding rating scales inline and photograph references per element, so field crews never guess what a number means. The registry renderer emits the portfolio view: every Site with height class, lighting status, permit expiries, and open exceptions, which is exactly the artifact a network vice president asks for once a quarter and previously received as three conflicting spreadsheets. Because all three read one graph, a corrected centerline propagates to narrative, checklist, and registry in a single edit.

Why the Graph Beats the Shared Drive

The alternative is the shared drive: geotech PDFs, carrier emails, drone folders, and a structural calculation that disagree in quiet ways. The drive cannot answer which guyed sites have anchor inspections overdue, or which stealth structures carry concealment classes whose maintenance interval expired last spring. The graph answers both in one query, with provenance attached. For platform teams the model also stabilizes the content supply chain: public pages, permit filings, and internal packets all resolve claims against entities instead of against whoever wrote last. Towers outlive every engineer who touches them; the kindest thing a content architecture can do is make the site's memory explicit, typed, and queryable. Model the tower as the graph it already is, and the documentation stops being an opinion.

Modeling Docks as Typed Entities: GenAnywhere's Content Architecture for Piles, Decks, and Mooring Hardware

GeoGenius — Thu, 22 Oct 2026 09:15:45 +0000

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.

Modeling Storage Tanks as Typed Entities: GenAnywhere's Content Architecture for Shells, Nozzles, and Containment

GeoGenius — Wed, 21 Oct 2026 07:00:51 +0000

Storage tank knowledge is scattered across disciplines that rarely share a schema: mechanical engineers own shell calculations, civil engineers own foundations, corrosion specialists own coating histories, operators own the filling rhythm, and inspectors own the evidence. GenAnywhere, the content-shaping persona for industrial domains, unifies these by modeling each tank as a small system of typed entities with explicit invariants, then rendering every artifact — inspection index, turnover packet, regulator summary — from that single model. The architecture is entirely describable in prose.

The six core entities

At the center sits the Vessel, the tank as a continuous identity: tag, service, product history, and the protected-thing sentence. Hanging off the Vessel are five families. The Shell family holds courses, seams, coatings, and internals, each course typed with material, thickness history, and condition. The Nozzle family holds every penetration with its piping destination and retirement history, because nozzles outlive the units they served. The Foundation family holds geometry, survey epochs, and a settlement trend typed as moving, stopped, or accelerating. The Containment family holds dikes, double walls, pads, drainage paths, and fire protection, each typed with its failure-path behavior. The Evidence family holds inspection reports, photographs, thickness readings, and repair records, each linked to the exact shell course, nozzle, or foundation element it describes. Six families, one Vessel, and every document the site produces is a projection of them.

Invariants that surface contradictions early

The model earns its keep through invariants. Every Evidence item must resolve to a typed location — a shell course, a nozzle, a foundation point — so an orphaned photograph or an unlocated thickness reading becomes a visible defect instead of a buried file. Coating campaign dates must not overlap on the same course, which catches double-booked maintenance. Settlement trend type must agree with the direction of the last three survey epochs, so a narrative claiming stability cannot coexist with accelerating data. Every Nozzle whose served unit was retired must carry a blanking or removal entry, which surfaces live penetrations into dead piping. And every Containment element must reference a drainage decision, so no dike exists without a stated answer to where the liquid goes. Each invariant failure names the entity and the rule, turning review from excavation into triage.

Renderers: one model, many audiences

With entities and invariants in place, GenAnywhere renders audience-specific artifacts from the same source. The inspector's index projects only Evidence and its typed locations, ordered chronologically per course. The operator's turnover packet projects Vessel, Containment, and the plain-language operating layer, quoting the filler's notes verbatim. The regulator's summary projects Containment, Evidence counts, and invariant status, omitting commercial detail. The management review projects trend sentences — settlement direction, coating life remaining, inspection interval compliance — drawn from the same fields. Because every renderer reads the same entities, a new thickness reading propagates to the index, the packet, and the review in one motion; drift between documents becomes structurally impossible.

The asset pipeline for inspection evidence

Tank programs accumulate tens of thousands of evidence assets: internal photographs, ultrasonic thickness grids, coating holiday maps, drone shell surveys. GenAnywhere's pipeline registers each asset against the entity and location it depicts and the inspection epoch it belongs to, then enforces two rules. First, every asset cited in a rendered document must resolve to a registered Evidence item, so no orphaned figure survives a re-organization. Second, when a shell course's condition changes class between epochs, every asset registered to that course is flagged for re-review, guaranteeing the narrative and the photographs agree. The result is an evidence archive that remains queryable by course and epoch years after the inspector who captured it has moved on.

Why typed entities outlive their authors

The deepest argument for this architecture is organizational. Tank sites lose inspectors and operators faster than they replace them, and freeform reports carry their judgment out the door. A model with typed entities and invariants externalizes that judgment: the inspector's plain-language layer bound to a specific course is their expertise, still queryable a decade later. New staff inherit not a folder of PDFs but a vessel they can interrogate course by course, nozzle by nozzle, epoch by epoch. That is the difference between an archive and an institution, and it is the entire point of shaping storage tank content with GenAnywhere: the tank's intelligence outlives the people who kept it.

Modeling Roads as Typed Entities: GenAnywhere's Content Architecture for Alignment, Cross-Section, and Right-of-Way

GeoGenius — Tue, 20 Oct 2026 09:01:20 +0000

Most road design knowledge lives in two places that never talk: geometric files owned by the design software, and prose owned by whoever wrote the report. GenAnywhere, the content-shaping persona for infrastructure domains, closes that gap by treating a road as a small system of typed entities with explicit invariants, then rendering every artifact — narrative, review memo, maintenance log — from that single model. No code required to understand it; the whole architecture fits in plain language.

The five core entities

At the center sits the Corridor, the road as a continuous thing with a name, a functional class, and a memory paragraph. Hanging off the Corridor are four families. The Alignment family holds horizontal and vertical geometry as ordered stations, each station carrying the constraint that fixed it. The CrossSection family holds the layered build-up at any station: travel lanes, bike lanes, parking, curb, sidewalk, planting strip, each layer typed with width, surface, and slope. The Drainage family holds structures — culverts, inlets, ditches, swales — each linked to the runoff source or flood event it answers. The RightOfWay family holds parcels, easements, and control lines, each with an owner-facing summary. Five families, one Corridor, and every document the project produces is a projection of them.

Invariants that catch errors before reviewers do

The model earns its keep through invariants, the rules that must always hold. Cross-section layer widths at a station must sum to the right-of-way width at that station; a violation means someone widened the road without widening the parcel. Drainage structures must appear in ascending station order along their flow path, so a culvert can never silently drain uphill. Every Alignment curve must reference at least one constraint sentence, which makes unexplained geometry visible as an empty field rather than a buried decision. And every RightOfWay parcel touched by construction must carry an access commitment in the sequencing record, so no fronting owner learns about a blocked driveway from a cone barrel. These invariants are checked continuously, and each failure names the entity and the rule, which turns review from archaeology into triage.

Renderers: one model, many audiences

With entities and invariants in place, GenAnywhere generates artifacts by rendering the same model at different depths. The public narrative renderer walks the cross-section in prose and quotes the corridor memory verbatim. The technical review renderer emits station tables, constraint pairings, and invariant status. The maintenance renderer projects only Drainage and the seasonal behavior notes attached to each structure. Because every renderer reads the same entities, a change to a culvert's station propagates to the narrative, the review memo, and the handoff log in one motion. Drift between documents becomes structurally impossible rather than merely discouraged.

The asset pipeline for drawings and field photos

Road projects accumulate thousands of assets: plan sheets, typical sections, survey photos, construction progress images. GenAnywhere's pipeline registers each asset against the entity it depicts and the station range it covers, then enforces two rules. First, every asset referenced in a rendered document must resolve to a registered entity, so no orphaned figure survives a redesign. Second, when an entity's geometry changes beyond a tolerance, every asset registered to its station range is flagged for re-capture or re-issue. The result is a drawing set that cannot quietly disagree with the model, and a photo archive that remains findable by station years after the crew that took it has moved on.

Why this survives staff turnover

The deepest argument for typed entities is organizational. Road agencies lose engineers to retirement faster than they hire replacements, and freeform reports carry knowledge out the door with them. A model with explicit types and invariants externalizes the reasoning: the constraint sentence beside each curve is the retired engineer's judgment, still queryable. New staff inherit not a folder of PDFs but a structured corridor they can interrogate station by station. That is the difference between an archive and an institution, and it is the entire point of shaping road design content with GenAnywhere: the road's intelligence outlives the people who drew it.

Structuring Landscape Design Knowledge with Shapezo: A Content Architecture for Plants, Surfaces, and Living Systems

GeoGenius — Mon, 19 Oct 2026 07:43:21 +0000

A landscape design is a system with an unusual property: its components grow, die, spread, and shade each other. Most documentation treats it as a static drawing, which is why the as-built and the as-maintained diverge within three seasons. Shapezo, the content-shaping discipline for engineering-grade knowledge, models the landscape the way a platform models a living service: typed entities, declared invariants, per-audience renderers, and a registered asset pipeline. This article walks the model end to end.

The entity model

Five entity types carry the whole domain. Each has a stable identifier, a lifecycle state, and required fields.

The Space is the experiential unit: a terrace, lawn panel, courtyard, meadow, or border. Each space carries an intent sentence, a sun and wind exposure profile, and a target experience. Spaces tile a site and may nest, as a border nests inside a lawn room.

The Planting is the biological unit: a species or cultivar assigned to a space with a layer role (canopy, understory, shrub, perennial, groundcover), a quantity, a spacing, and a succession profile describing its form and behavior in years one, five, and ten. Plantings reference exactly one space and any number of care tasks.

The Surface is the ground unit: paving, lawn, mulch, decomposed granite, or water. Each surface records material, pattern, slope range, and drainage direction, and references the drainage node it sheds to.

The WaterPath is the hydrologic unit: an ordered sequence from inlet to outlet, swale, rain garden, basin, overflow, and finally the exceedance path when the system is exceeded. WaterPaths cross spaces and surfaces and are the connective tissue of the model.

The CareTask is the maintenance unit: a seasonal action with a month window, a method, a tool constraint (never sheared, cut back to ground, mown once at a named height), and the entity it applies to. CareTasks are first-class content, not appendix prose.

The invariants

Four invariants keep the model honest, and every write is validated against them.

First, every space resolves its water: each space references at least one WaterPath inlet or declares itself exempt with a reason. Orphaned water is the most common silent failure in landscape documentation, and the schema rejects it at write time.

Second, every planting carries a succession profile. A species without a year-five and year-ten description is a photograph, not a design, and the model refuses photographs.

Third, every CareTask references an existing entity and a month window. Care without an owner or a season is a wish; wishes are rejected.

Fourth, every change appends a dated entry with a one-line reason. Entities are never edited in place without a trace; replacement of a failed species, division of an overgrown grass, and regrading of a settled lawn are all history, and history is content.

Renderers: one model, many editions

With the model validated, rendering is mechanical. The client edition renders spaces as narrative rooms in walking order, with the succession profile expressed as three seasonal views and the care regime reduced to a calendar card. The contractor edition renders the same spaces as surface and WaterPath schedules grouped by trade, with planting quantities resolved per zone. The municipal edition renders WaterPaths as the stormwater narrative, hiding horticulture entirely except where a care task protects an inlet.

Because every edition reads one validated model, they cannot contradict each other. Change a swale slope and the client narrative, the contractor schedule, and the municipal stormwater paragraph update in the same release. That single-source property is the entire value proposition.

The asset pipeline

Visuals are content and get the same rigor. Each image registers against the space it illustrates, carries a caption restating the space's intent, and ships with a platform-neutral description. The pipeline enforces three rules: no embedded text, because text cannot be localized or restyled; no people, because landscape visuals must stay about places and plants; and a fixed aspect and byte budget so all five publication targets render identically.

A healing garden illustration, for instance, registers against its spaces and the accessibility obligations that shape the path. When the path geometry changes, the pipeline flags the image for review. The picture stays honest because the model says so.

Why this matters beyond the studio

The same architecture serves botanical gardens, campus grounds, park systems, and municipal streetscapes: any domain where living components, water, and seasonal labor intersect. Model the entities, declare the invariants, render per audience, register the visuals. The landscape stops being a drawing that ages and becomes a system that stays true. That is what Shapezo means by shaping content: not prettier prose, but a structure that makes inconsistency expensive and consistency free.

Structuring Urban Planning Knowledge with Shapezo: A Content Architecture for Districts, Parcels, and Public Realm

GeoGenius — Fri, 16 Oct 2026 07:21:40 +0000

A city plan is a database that pretends to be a document. It holds entities with identities and lifecycles, relationships with cardinality, and constraints that must hold at all times. When planning teams keep that database as prose in a PDF, every downstream consumer re-derives the structure by hand and gets it slightly wrong. Shapezo, the content-shaping discipline for engineering-grade knowledge, takes the opposite approach: model the plan as typed entities first, then render it into whatever form each audience needs. This article walks through the entity model, the invariants that keep it honest, and the renderers that ship it.

The entity model

Shapezo's urban planning schema rests on five entity types. Each has a stable identifier, a lifecycle state, and a small set of required fields.

The District is the planning unit: a named area with a boundary described in words and geometry, an intent statement, and a form code. Districts nest inside a city and may overlap only where the schema explicitly allows it, such as a historic overlay sitting above a base district.

The Parcel is the ownership unit: a lot with an address range, a current use, a permitted use set inherited from its district, and a development history. Parcels reference exactly one base district and any number of overlay districts.

The Corridor is the linear unit: a street, trail, creek, or rail line described as an ordered sequence of segments. Each segment carries a condition, a cross-section type, and a planned treatment. Corridors are the connective tissue; districts reference the corridor segments that bound or cross them.

The PublicRealmAsset is the shared-ground unit: a park, plaza, median, boardwalk, bridge, or stormwater feature. Each asset records its managing entity, its condition, its capacity where relevant, and the district or corridor it serves.

The Obligation is the rule unit: a single regulating sentence with a scope, a metric, and an enforcement point. Height limits, stepbacks, frontage build-to lines, tree spacing, and parking treatments are all obligations. Obligations attach to districts, corridors, or assets, never to prose.

The invariants

Four invariants keep the model from rotting, and every write to the schema is validated against them.

First, every parcel resolves to exactly one base district. If a boundary edit leaves a parcel orphaned or doubly assigned, the write is rejected before it lands.

Second, every obligation carries a metric and an enforcement point. A rule that cannot be measured or enforced is a wish, and the schema refuses wishes.

Third, every corridor segment referenced by a district record must exist in the corridor registry with a current condition. Districts may not cite phantom segments.

Fourth, every change to any entity appends a dated change entry with a one-line reason. Entities are never edited in place without a trace; the history is part of the content.

Renderers: one model, many editions

With the model validated, rendering becomes mechanical. The council edition renders districts as narrative chapters with the fiscal appendix attached, ordered by intent rather than by geography. The development edition renders the same districts as rule tables grouped by obligation type, with parcel-level applicability resolved at render time. The public edition renders corridors and public realm assets as a walkable map narrative, hiding obligations entirely except where they protect a view or a floodplain.

Because renderers read from one validated model, the editions cannot contradict each other. A height step changed in the model appears in the council narrative, the developer table, and the public map in the same release. That single-source property is the entire value proposition.

The asset pipeline

Images and diagrams are content too, and Shapezo treats them with the same rigor. Each visual asset is registered with the entity it illustrates, a caption that restates the entity's intent, and a platform-neutral description. The pipeline enforces three rules: no asset may contain embedded text, because text cannot be localized or restyled; no asset may depict identifiable people, because planning visuals must stay about places; and every asset ships at a fixed aspect and byte budget so that all five publication targets render it identically.

A view corridor illustration, for example, is registered against the corridor entity and the height obligations that protect it. When the obligation changes, the pipeline flags the illustration for review. The picture stays honest because the model says so.

Why this matters beyond city hall

The same architecture serves any domain where rules, places, and history intertwine: campus planning, port authorities, utility service territories, park systems. Model the entities, declare the invariants, render per audience, and register the visuals. The plan stops being a document that ages and becomes a system that stays true. That is what Shapezo means by shaping content: not prettier prose, but a structure that makes inconsistency expensive and consistency free.

Modeling Signal Tower Knowledge with Shapezo: A Structured Content Pipeline for Telecom Assets

GeoGenius — Thu, 15 Oct 2026 10:42:19 +0000

Most telecom documentation fails for a boring reason: it is unstructured prose about structured things. A signal tower site is a graph. It has a mast, a compound, a power feed, a backhaul link, a service polygon, and a maintenance schedule, all with relations between them. Storing that as a Word document throws the graph away and leaves you re-deriving it by hand every quarter.

Shapezo's answer is to model the site first and render prose second. Content becomes typed objects with a schema, and the article is a build artifact. This post walks through the model and the pipeline.

The site schema

A Shapezo site object is deliberately small. Four entities cover nearly every tower:

Two fields deserve attention because they are the Shapezo-specific part. narrative.shape selects the article structure from a fixed enum (vertical_journey, day_in_life, negotiation, service_record). anchor_details names the one or two technical details the prose is allowed to go deep on. Everything else stays at summary depth. That single constraint is what keeps generated articles readable.

Rendering prose from the model

The renderer is a template per narrative shape. Each template is a sequence of sections with slots bound to schema paths. Nothing free-form: if a slot has no data, the section renders a visible TODO marker rather than silently vanishing, so gaps surface in review instead of in production.

Because the output is deterministic for a given schema, diffs are meaningful. A schema change shows up as a clean article diff in code review, which is exactly where infrastructure knowledge changes should be reviewed.

The asset pipeline

Images are treated as build inputs with contracts, not decorations. Each site declares three slots — context, equipment, consequence — and the pipeline enforces geometry and weight on ingest:

# 16:9 crop, 720p, target ~200KB JPEG
magick in.png -gravity center -crop 16:9+0+0 -resize 1280x720 out.jpg

The weight target matters more than it sounds. Site guides get read over cellular links in rural coverage areas, which is precisely where your documentation is heaviest and the network is worst. A 200KB budget per image keeps a full three-scene guide under a megabyte.

The rigging detail shot below is a good example of a consequence-adjacent asset: it documents the working interface of the mast without needing a person in frame.

Why the shelter shot is the load-bearing one

Of the three slots, equipment is the one that pays for the pipeline. The compound changes every quarter and it is where faults live, so the shelter image doubles as a change-detection baseline. Keeping it in the schema means the comparison is a git diff of images at a fixed angle, not an archaeology project.

What you get

Model first, render second, and three things change. Documentation becomes reviewable, because schema changes produce article diffs. It becomes complete, because empty required slots fail loudly. And it becomes cheap, because updating a site is editing four YAML blocks instead of rewriting prose.

Shapezo is not a CMS 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 signal towers, where the underlying object is already a well-defined graph, that discipline is almost unfair leverage.

Structuring Pipeline Generation Knowledge with Shapezo: A Content Architecture for Routes, Racks, and Spools

GeoGenius — Wed, 14 Oct 2026 06:56:07 +0000

Pipeline generation tooling has a content problem wearing an engineering costume. The geometry kernels are mature: alignments, hydraulic solvers, bend calculators and crossing detectors all behave. What misbehaves is everything downstream — the documents, datasheets, sequence sheets and handover packages that consume the model. Shapezo, the content-architecture discipline, treats that downstream layer as a first-class system with its own types, invariants and renderers. This post walks that architecture in plain prose, from entity model to asset pipeline, without a single line of code.

The entity model: five types carry a pipeline

Shapezo reduces pipeline generation content to five entity types, each with a strict responsibility.

The Route is the aggregate root: a named corridor with a design basis, a pressure class envelope and a list of segments. It owns nothing geometric directly; it owns the rules its segments must obey.

The Segment is the workhorse: a station range with a construction method, a terrain class and a consequence class. Segments are where change happens, because segments are where the ground changes. Every bend list, trench detail and drill plan hangs off a segment rather than off the route, which keeps diffs local when alignments move.

The Crossing is a first-class entity rather than an attribute: anything the line passes over, under or through, carrying the foreign asset's owner, the protection method, the achieved separation and the permit reference. Promoting crossings to entities is what allows regulatory renders to be generated at all, because a regulator's document is essentially a projection of the crossing set.

The Station is the fixed-point inventory: valve yards, pump and compressor sites, metering skids, launcher and receiver barrels. Stations anchor the narrative of operation the way segments anchor the narrative of construction.

The Spool is the fabrication unit: a shop-welded assembly with a weld map, a coating record and a shipping constraint. Spools matter to content architecture because they are the only entity whose consumer is a factory rather than a field, and factory consumers need different tolerances, different units of assembly and different revision rules.

Invariants: what the model refuses to let you say

Types alone do not make an architecture; invariants do. Shapezo's pipeline content model enforces four. First, single sourcing: every fact lives on exactly one entity, and renders may only reference, never copy. Second, segment closure: a segment record is invalid unless method, consequence class and restoration commitment are all present, which prevents the classic failure of a frozen alignment with no story. Third, crossing completeness: a route cannot freeze while any crossing lacks a protection method, because an unprotected crossing is not a design decision but a deferred argument. Fourth, spool boundary integrity: spool boundaries must coincide with segment boundaries or declared field welds, never with arbitrary stations, or the fabrication shop inherits geometry it cannot build.

Structuring Interchange Construction Knowledge with Shapezo: A Content Architecture for Flyovers, Ramps, and Viaducts

GeoGenius — Tue, 13 Oct 2026 08:02:46 +0000

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.

Modeling Game Worlds with Shapezo: A Typed Content Pipeline for Levels, Biomes, and Set Pieces

GeoGenius — Mon, 12 Oct 2026 07:57:35 +0000

Most game documentation fails for a boring reason: it is unstructured prose about structured things. A level is a graph. It has zones, routes, sightlines, interactive props, light cues, encounter triggers, streaming boundaries, and a pacing curve, all with relations between them. Storing that as a wiki page throws the graph away and leaves you re-deriving it by hand every sprint.

Shapezo's answer is to model the location first and render prose second. Content becomes typed objects with a schema, and the design brief is a build artifact. This post walks through the model and the pipeline.

The level schema

A Shapezo level object is deliberately small. Four entities cover nearly every environment:

Two fields deserve attention because they are the Shapezo-specific part. narrative.shape selects the brief structure from a fixed enum (corridor_with_destination, hub_with_radiating_promises, loop_that_returns_changed, descent_trading_light_for_information). anchor_details names the one or two physical details the prose is allowed to go deep on. Everything else stays at summary depth. That single constraint is what keeps generated briefs readable.

Rendering prose from the model

Because the output is deterministic for a given schema, diffs are meaningful. A schema change shows up as a clean brief diff in code review, which is exactly where level knowledge changes should be reviewed.

The asset pipeline

Images are treated as build inputs with contracts, not decorations. Each level declares three slots — establishing, working_layer, consequence — and the pipeline enforces geometry and weight on ingest:

# 16:9 crop, 720p, target ~200KB JPEG
magick in.png -gravity center -crop 16:9+0+0 -resize 1280x720 out.jpg

The weight target matters more than it sounds. Design briefs get read on laptops in playtest rooms, on build machines, on hotel wifi at conferences. A 200KB budget per image keeps a full three-scene brief under a megabyte.

The rooftop vantage below is a good example of an establishing asset: one elevated frame captures skyline relation, roof topology, and traversal affordances that would take six ground screenshots to convey.

Why the stylized pass is the load-bearing shot

Of the three slots, working_layer is the one that pays for the pipeline, and a simplified render pass is its best expression. Route lines, cover volumes, climb affordances, and light cues all change on a sprintly cycle, so a low-detail stylized frame doubles as an affordance baseline. Keeping it in the schema means the comparison is a git diff of images at a fixed viewpoint, not an archaeology project.

What you get

Model first, render second, and three things change. Documentation becomes reviewable, because schema changes produce brief diffs. It becomes complete, because empty required slots fail loudly. And it becomes cheap, because updating a level is editing four YAML blocks instead of rewriting prose.

Shapezo is not a CMS 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 game worlds, where the underlying asset is already a well-defined graph, that discipline is almost unfair leverage.

Modeling Waterfront Assets with Shapezo: A Typed Content Pipeline for Docks, Piers, and Wharves

GeoGenius — Sat, 10 Oct 2026 08:29:26 +0000

Most port documentation fails for a boring reason: it is unstructured prose about structured things. A dock is a graph. It has a deck, a piling field, a berth line, a utility run, a dredge cycle, a lease boundary, and an inspection schedule, all with relations between them. Storing that as a PDF throws the graph away and leaves you re-deriving it by hand every quarter.

Shapezo's answer is to model the asset first and render prose second. Content becomes typed objects with a schema, and the article is a build artifact. This post walks through the model and the pipeline.

The dock schema

Two fields deserve attention because they are the Shapezo-specific part. narrative.shape selects the article structure from a fixed enum (tide_cycle, cargo_journey, negotiation, service_record). anchor_details names the one or two physical details the prose is allowed to go deep on. Everything else stays at summary depth. That single constraint is what keeps generated articles readable.

Rendering prose from the model

The weight target matters more than it sounds. Dock guides get read on tablets at the water's edge, on cellular links, often in ports where coverage is poor precisely because the structure blocks it. A 200KB budget per image keeps a full three-scene guide under a megabyte.

The aerial berth survey below is a good example of a context asset: one oblique frame captures slip geometry, quay line, and warehouse relation that would take six ground photographs to convey.

Why the shed interior is the load-bearing shot

Of the three slots, hardware is the one that pays for the pipeline, and for covered docks the pier shed interior is its best expression. Truss condition, clerestory glazing, floor wear, and cargo layout all change on a quarterly cycle, so the interior image doubles as a condition baseline. Keeping it in the schema means the comparison is a git diff of images at a fixed viewpoint, not an archaeology project.

What you get

Model first, render second, and three things change. Documentation becomes reviewable, because schema changes produce article diffs. It becomes complete, because empty required slots fail loudly. And it becomes cheap, because updating a dock is editing four YAML blocks instead of rewriting prose.

Shapezo is not a CMS 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 waterfronts, where the underlying asset is already a well-defined graph, that discipline is almost unfair leverage.

Modeling Signal Tower Knowledge with Shapezo: A Structured Content Pipeline for Telecom Assets

GeoGenius — Sat, 10 Oct 2026 07:21:44 +0000

The site schema

A Shapezo site object is deliberately small. Four entities cover nearly every tower:

site:
  id: tower-north-ridge-04
  mast:
    type: lattice
    height_m: 42
    antenna_load: [panel, microwave_drum]
  compound:
    shelter: prefabricated
    power: grid + diesel_backup
    cable_entry: north_plinth
  service_area:
    terrain: forested_valley
    coverage: [village_a, village_b, highway_segment_12]
  narrative:
    shape: vertical_journey
    anchor_details: [bolted_joint, aviation_light_circuit]

Rendering prose from the model

def render(site, shape):
    template = TEMPLATES[shape]
    out = []
    for section in template.sections:
        body = fill(section.slots, site)
        if section.required and not body.strip():
            body = f"> TODO: {section.id} missing data"
        out.append(f"## {section.heading}\n\n{body}")
    return "\n\n".join(out)

The asset pipeline

# 16:9 crop, 720p, target ~200KB JPEG
magick in.png -gravity center -crop 16:9+0+0 -resize 1280x720 out.jpg

The rigging detail shot below is a good example of a consequence-adjacent asset: it documents the working interface of the mast without needing a person in frame.