Dev.to AI 🤖 Ai 👁 0 📖 3 min read

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

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 m

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

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:

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]

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.

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)

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.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.