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.
Top comments (0)