Telecom Compliance Data Reference

Telecom Compliance Data Reference is the single vocabulary that every tower automation subsystem on telecomtower.org is required to speak. It exists because three independent operational domains — document parsing, inspection scheduling, and compliance architecture — each touch the same underlying facts about a tower, and if each domain were allowed to name those facts differently, every integration point between them would become a translation problem instead of a lookup. This page is that lookup. It defines one canonical field name and type for every fact a tower record can carry, one authoritative mapping from those fields to the regulatory sources that require them, and one schema for the audit log that every write to any of those fields must seal into. Nothing downstream re-derives these definitions; everything downstream cites them.

The reason this has to be centralized rather than left to each domain is straightforward: Automated Structural Report Parsing & Document Ingestion extracts a tower_height_ft value from a scanned CAD sheet, Intelligent Inspection Scheduling & Technician Routing reads that same tower_height_ft to calculate an inspection frequency, and Telecom Tower Compliance Architecture & Data Mapping evaluates that same value against a municipal height cap. If any one of those three systems used a different field name, a different unit, or a different rounding rule, the numbers would silently diverge and no single audit would catch it — each subsystem would report internally consistent, mutually contradictory truths. The subsystems below close that gap: the Canonical Field Dictionary fixes the vocabulary, the Regulatory Source Crosswalk fixes the citations, and the Audit Log Schema Reference fixes the seal every one of those fields is written under.

Operational Architecture Overview #

Every field, from every domain, passes through the same three gates before it is trusted anywhere on this site. A vendor-specific label is resolved to its canonical name, the canonical field is attached to the regulatory citation that governs it, and the result is sealed into a manifest whose hash is the only thing any downstream consumer is allowed to trust without re-verification. The three operational domains do not each implement this resolution independently — they call into it.

Figure: heterogeneous vendor fields from all three operational domains resolve through one canonical field registry, attach one regulatory citation, and seal into one audit manifest that every domain reads back from.

The principle is identical to the one this site already applies inside Telecom Tower Compliance Architecture & Data Mapping: trust is earned once, at a single boundary, and never re-litigated. Here that boundary is the reference plane itself. A subsystem that reads a sealed field from the manifest does not need to know which vendor label originally produced it, nor which regulation it maps to — both are already resolved and attached, and the hash proves neither has drifted since sealing.

Canonical Field Vocabulary #

Every fact this site tracks about a tower site, a lease, or a zoning determination reduces to one of a fixed set of field names, and that set is deliberately small. site_id (str, e.g. TWR-8842) identifies the physical structure and is the join key every other field hangs off of. tower_height_ft (float) is always feet, always positive, regardless of whether the source measured meters or read a blueprint annotation. lease_expiry (ISO-8601 date string) is always UTC-normalized so date comparisons are locale-independent. zoning_code (str, pattern MUN-XX-XXX, e.g. MUN-4A-RES) identifies the municipal land-use classification in force at the site. fcc_asr_number (str, e.g. 1290123) is the federal antenna structure registration identifier. Rounding this out: structure_type, owner_id, landlord_id, rent_amount_usd (float), escalation_pct (float), design_capacity_kg (float), and current_load_kg (float).

This list is not a suggestion that subsystems are free to extend informally. It is the complete contract. The full catalog — including every known vendor alias for each field, the coercion rule that resolves an alias to its canonical type, and the default-vs-required distinction for each entry — lives in the Canonical Field Dictionary. That page is where a new data source gets registered: before a fourth domain, or a fourth vendor format, is allowed to write into any pipeline on this site, its field labels are mapped into this dictionary first. The practical mechanics of that mapping — taking a raw vendor export and producing canonical output — are worked end to end in Mapping vendor fields to the canonical tower schema.

The discipline that keeps this vocabulary trustworthy is refusal, not inference. If a payload calls a field HeightMeters and the dictionary has no registered alias for it, the registry does not guess; it raises a resolution error and the record is refused rather than silently admitted with an unmapped or wrongly-typed field. A guessed mapping that turns out wrong is far more expensive to find later than a refused record is to fix now, because a wrong guess propagates into every downstream compliance decision that reads it.

Regulatory Source Crosswalk #

A canonical field name is only half of what a compliance officer needs — the other half is knowing exactly which regulation requires that field to exist, and at what threshold. tower_height_ft is not an arbitrary measurement; it exists in this system because FCC Antenna Structure Registration under 47 CFR Part 17 conditions a structure’s registration on accurate height reporting, and because municipal zoning ordinances set height caps that zoning_code resolves against. fcc_asr_number exists because that same Part 17 registration is the federal identifier a structure must carry before it can legally transmit. Fields that gate who may read or write a record — the access-control layer behind owner_id and landlord_id — trace to NIST SP 800-53’s access control and audit families, AC and AU, which is why the Security Boundary Configuration subsystem in the compliance architecture domain cites those same control identifiers rather than inventing its own access taxonomy. Fields touching climb operations and technician safety windows trace to OSHA 29 CFR Part 1926, which is why the weather and crew-capacity logic inside Intelligent Inspection Scheduling & Technician Routing cites the same part number a compliance auditor would look for.

The Regulatory Source Crosswalk is where every one of these field-to-statute mappings is recorded as a single authoritative table, so that “why does this field exist” always has one answer instead of three slightly different ones scattered across subsystem pages. Two companion guides make the crosswalk directly executable rather than just documentation: Validating FCC ASR numbers in Python implements the format and checksum validation an fcc_asr_number must pass before it is accepted, and Mapping NIST SP 800-53 controls to tower data access implements the control-to-field binding that the RBAC layer in the compliance architecture domain consumes directly.

Centralizing the crosswalk also means a regulatory change is a one-place update. When a municipality revises a height cap or the FCC updates a filing requirement, the crosswalk entry changes once, and every subsystem that cites it — the zoning evaluator, the scheduling engine, the ingestion validator — picks up the revision on its next read rather than requiring three separate patches that can drift out of sync with each other.

Validation Layer #

Every field that reaches the reference plane passes a validation gate before it is eligible to be cited against a regulatory source or sealed into a manifest. The required-field set mirrors the one enforced inside Telecom Tower Compliance Architecture & Data Mapping — site_id, tower_height_ft, lease_expiry, and zoning_code must be present, typed, and range-checked, because these four fields are what every downstream regulatory citation and audit entry hangs off of. But the reference plane adds one validation rule the operational domains do not: every field name presented to it must already exist in the canonical dictionary, or the payload is refused outright rather than passed through with an unmapped attribute quietly attached.

This is a deliberately stricter posture than “validate what you know and pass through what you don’t,” because an unmapped field sitting inside an otherwise-valid record is exactly the kind of latent inconsistency that survives every downstream check silently until an auditor asks what it means. Records that fail this gate route to the same kind of remediation queue used across the site — the original payload, the specific resolution failure, and the source domain are preserved so the field can be registered in the dictionary or the source system corrected, without losing the audit trail of the rejected attempt.

Core Subsystem 1 — Canonical Field Dictionary #

The Canonical Field Dictionary is the field catalog itself: every canonical field name, its type, its unit, its required-vs-optional status, and the complete list of vendor aliases known to resolve to it. This is the artifact a new integration consults first. A structural engineering firm delivering CAD exports under a new naming convention does not get a bespoke parser bolted onto ingestion — its field labels get registered as aliases in the dictionary, and every existing pipeline that already speaks the canonical vocabulary picks up the new source automatically. The dictionary also carries the coercion rule for each field: tower_height_ft accepts meters, feet, or unlabeled numeric strings under a documented unit-inference rule, but always emits a positive float in feet, so no downstream consumer ever has to ask what unit a value is in.

Because this dictionary is the first gate every field passes through, it is also the natural place to enforce naming discipline against drift. Two vendors independently choosing to call the same underlying fact Structure Height and Elevation (AGL) is not a coincidence the rest of the architecture should have to notice twice — it is resolved once, here, and every subsystem downstream inherits the resolution. The worked example of taking a raw multi-vendor export through this exact resolution path is in Mapping vendor fields to the canonical tower schema.

Core Subsystem 2 — Regulatory Source Crosswalk #

The Regulatory Source Crosswalk is the second core subsystem: the table that answers, for every canonical field and every access control, exactly which regulation requires it and at what citation. Where the dictionary answers “what is this field,” the crosswalk answers “why must it exist and what does non-compliance look like.” The two subsystems are deliberately kept separate because they change on different schedules — the field vocabulary is stable and rarely grows, while regulatory citations get amended, superseded, or reinterpreted on a jurisdiction’s own timeline, and conflating the two would mean a routine ordinance update touching the same artifact that defines core data types.

The crosswalk is what makes a zoning verdict or an access decision defensible under scrutiny rather than merely asserted. When the Zoning Rule Engine Design subsystem evaluates a proposed height against a municipal cap, the citation it attaches to that verdict — the specific ordinance section, the FCC Part 17 registration threshold, the precedence rule that resolved the conflict — is pulled from this crosswalk rather than hardcoded into the zoning engine itself, so a compliance officer questioning the verdict can trace it to one canonical source rather than to logic embedded in application code.

Audit Log Schema Reference #

Every write this reference plane performs — a field resolution, a citation attachment, a manifest seal — produces an entry in the same audit log shape, and that shape is fixed by the Audit Log Schema Reference. The schema is deliberately minimal: a canonical record serialized with sorted keys, a UTC timestamp, and a hashlib.sha256 digest computed over that exact serialization. This is the identical pattern already established in the compliance architecture domain’s immutable ledger, and the reference plane does not vary it, because a second, slightly different audit shape would defeat the entire point of having one authoritative log format a regulator or an internal reviewer can learn once and apply everywhere.

What makes this schema load-bearing rather than decorative is that every one of the three operational domains seals its own writes under it. A parsed structural report, a scheduled inspection dispatch, and a zoning verdict all produce audit entries with the same field ordering, the same hash algorithm, and the same digest verification procedure, which is what lets a single verification pass over the log detect tampering anywhere in the system rather than requiring three domain-specific checkers. The mechanics of that verification — recomputing the digest over a stored record and comparing it against the sealed value — are demonstrated in Verifying SHA-256 audit hashes across compliance records.

Security, Access Control & Audit Trails #

The reference plane holds no lease economics or structural vulnerability data itself, but it holds something arguably more sensitive to tamper with: the definitions everything else trusts. If an attacker could quietly redefine what tower_height_ft means, or silently detach a required regulatory citation from a field, every downstream compliance decision built on that definition becomes wrong without any single subsystem doing anything incorrect on its own. Access to the dictionary and crosswalk is therefore held to the same role-scoped standard as the Security Boundary Configuration subsystem enforces elsewhere: read access is broad, because every domain needs to resolve fields constantly, but write access — registering a new alias, amending a citation, revising the manifest schema — is restricted to a small reviewed set of roles, and every such change is itself sealed into the audit log under the same schema it defines.

This is a deliberately self-referential guarantee: the schema that governs every other subsystem’s audit trail also governs changes to itself, so there is no privileged, unaudited path to altering the vocabulary the rest of the site depends on. A compliance officer auditing a zoning verdict from six months ago can also audit whether the field definition that verdict relied on has changed since, and if it has, exactly when and under whose write.

Resilience & Fallback Patterns #

The reference plane is read far more often than it is written, which shapes its resilience story differently from the operational domains. A stale cached copy of the dictionary or crosswalk is far more dangerous than a temporarily unavailable one, because a stale copy fails silently — a subsystem resolves a field against an outdated alias table and produces a wrong-but-plausible result — while an unavailable reference plane fails loudly and can be handled by the same fallback discipline the Fallback Routing Protocols subsystem already applies to field connectivity. Every consumer of this reference plane therefore pins the manifest hash it last verified alongside any cached copy it holds, and refuses to trust a cached lookup whose hash no longer matches the currently published manifest, converting a silent staleness failure into a loud, immediately actionable one.

When the reference plane itself is unreachable — a rare event, since it changes slowly and is aggressively cached — the correct behavior for every downstream domain is to fail closed on new writes rather than fall back to an assumed definition. A tower inspection dispatch that cannot resolve tower_height_ft against a verified dictionary entry is a dispatch that waits, not one that guesses. This is the same principle that governs every other resilience pattern on this site: connectivity degradation is allowed to change latency, never correctness.

Production Implementation #

The module below is the runnable form of the resolution pipeline traced in the overview diagram: it resolves vendor field aliases to canonical names, coerces types and units, attaches a regulatory citation per field, validates that every required field is present, and seals the resulting field manifest with a hashlib.sha256 digest. The class/data-flow diagram below shows how a raw multi-vendor payload moves through CanonicalFieldRegistry before the code.

Figure: the CanonicalFieldRegistry pipeline — a raw payload resolves through resolve_fields, binds a RegulatorySource per field in attach_citations, passes validate_required, and seals into an immutable manifest via seal_manifest; unmapped aliases or missing required fields raise FieldResolutionError.

import logging
import json
import hashlib
from dataclasses import dataclass, field
from datetime import datetime, timezone
from typing import Dict, Any, Optional

# Configure structured logging per production standards
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s | %(levelname)s | %(name)s | %(message)s",
    datefmt="%Y-%m-%dT%H:%M:%S%z"
)
logger = logging.getLogger("canonical_field_registry")


class FieldResolutionError(Exception):
    """Raised when a field cannot be resolved to a canonical name or fails validation."""
    pass


@dataclass
class RegulatorySource:
    statute: str
    section: str


@dataclass
class ResolvedField:
    name: str
    value: Any
    source: Optional[RegulatorySource] = None


class CanonicalFieldRegistry:
    """
    Resolves heterogeneous vendor field labels to the canonical tower schema,
    attaches regulatory citations, validates required fields, and seals the
    result into a tamper-evident field manifest.
    """
    ALIASES = {
        "site_id": {"site_id", "SiteID", "TowerID"},
        "tower_height_ft": {"tower_height_ft", "HGT (m)", "Tower Height", "structure_elev_ft"},
        "lease_expiry": {"lease_expiry", "LeaseExpiry", "Lease End Date"},
        "zoning_code": {"zoning_code", "ZoningCode", "Zone"},
        "fcc_asr_number": {"fcc_asr_number", "ASR", "ASR Number"},
    }

    CITATIONS = {
        "tower_height_ft": RegulatorySource("FCC ASR", "47 CFR Part 17"),
        "fcc_asr_number": RegulatorySource("FCC ASR", "47 CFR Part 17"),
        "zoning_code": RegulatorySource("Municipal Ordinance", "local land-use code"),
        "site_id": RegulatorySource("NIST SP 800-53", "AC-3 access enforcement"),
    }

    REQUIRED_FIELDS = {"site_id", "tower_height_ft", "lease_expiry", "zoning_code"}

    def __init__(self) -> None:
        self._reverse_alias = {
            alias: canonical
            for canonical, aliases in self.ALIASES.items()
            for alias in aliases
        }
        logger.info("CanonicalFieldRegistry initialized with %d canonical fields.", len(self.ALIASES))

    def _coerce(self, canonical_name: str, raw_key: str, value: Any) -> Any:
        """Coerce a raw value to the canonical field's type and unit."""
        if canonical_name == "tower_height_ft":
            numeric = float(value)
            if "m)" in raw_key or "meter" in raw_key.lower():
                numeric = numeric * 3.28084
            if numeric <= 0:
                raise FieldResolutionError(f"tower_height_ft must be positive, got {numeric}")
            return round(numeric, 2)
        if canonical_name == "lease_expiry":
            return str(value)
        if canonical_name == "zoning_code":
            return str(value).upper()
        if canonical_name == "fcc_asr_number":
            return str(value)
        return value

    def resolve_fields(self, raw_payload: Dict[str, Any]) -> Dict[str, ResolvedField]:
        """Resolve every key in a raw payload to a canonical field name and value."""
        resolved: Dict[str, ResolvedField] = {}
        for raw_key, value in raw_payload.items():
            canonical_name = self._reverse_alias.get(raw_key)
            if canonical_name is None:
                logger.debug("Ignoring unmapped field: %s", raw_key)
                continue
            try:
                coerced = self._coerce(canonical_name, raw_key, value)
            except (TypeError, ValueError) as exc:
                raise FieldResolutionError(
                    f"Failed to coerce field '{raw_key}' -> '{canonical_name}': {exc}"
                ) from exc
            resolved[canonical_name] = ResolvedField(name=canonical_name, value=coerced)
        logger.info("Resolved %d canonical fields from raw payload.", len(resolved))
        return resolved

    def attach_citations(self, resolved: Dict[str, ResolvedField]) -> Dict[str, ResolvedField]:
        """Attach a regulatory citation to each resolved field where one is registered."""
        for canonical_name, resolved_field in resolved.items():
            resolved_field.source = self.CITATIONS.get(canonical_name)
        return resolved

    def validate_required(self, resolved: Dict[str, ResolvedField]) -> None:
        """Ensure every mandatory canonical field is present after resolution."""
        missing = self.REQUIRED_FIELDS - resolved.keys()
        if missing:
            raise FieldResolutionError(f"Missing required canonical fields: {', '.join(sorted(missing))}")

    def seal_manifest(self, resolved: Dict[str, ResolvedField]) -> Dict[str, Any]:
        """Seal the resolved, cited field set into a tamper-evident SHA-256 manifest."""
        sealed_at = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%SZ")
        fields_payload = {
            name: {
                "value": rf.value,
                "citation": f"{rf.source.statute} {rf.source.section}" if rf.source else None,
            }
            for name, rf in sorted(resolved.items())
        }
        canonical = json.dumps({"fields": fields_payload, "sealed_at": sealed_at}, sort_keys=True)
        digest = hashlib.sha256(canonical.encode("utf-8")).hexdigest()
        manifest = {"fields": fields_payload, "sealed_at": sealed_at, "manifest_hash": digest}
        logger.info("Field manifest sealed (hash %s).", digest[:12])
        return manifest

    def build_manifest(self, raw_payload: Dict[str, Any]) -> Dict[str, Any]:
        """Full pipeline: resolve, cite, validate, and seal a raw vendor payload."""
        resolved = self.resolve_fields(raw_payload)
        resolved = self.attach_citations(resolved)
        self.validate_required(resolved)
        return self.seal_manifest(resolved)


# Example usage demonstrating alias resolution, citation attachment, and sealing
if __name__ == "__main__":
    registry = CanonicalFieldRegistry()

    vendor_payload = {
        "TowerID": "TWR-8842",
        "HGT (m)": 56.5,
        "LeaseExpiry": "2028-11-30",
        "Zone": "MUN-4A-RES",
        "ASR": "1290123",
    }

    try:
        manifest = registry.build_manifest(vendor_payload)
        print(json.dumps(manifest, indent=2))
    except FieldResolutionError as exc:
        logger.error("Manifest build failed: %s", exc)

Running the module against the sample vendor payload resolves HGT (m) to tower_height_ft and converts it from meters to feet, resolves TowerID, LeaseExpiry, Zone, and ASR to their canonical names, attaches the FCC ASR and NIST AC-3 citations, confirms all four required fields are present, and prints a sealed manifest with a stable manifest_hash. A payload missing zoning_code or lease_expiry after resolution raises FieldResolutionError at validate_required and never reaches seal_manifest — the same refuse-rather-than-guess posture the validation layer enforces everywhere else on this site.

Operational Alignment & Next Steps #

Centralizing the field vocabulary, the regulatory citations, and the audit-log schema turns what would otherwise be three independently drifting definitions into one definition each of the operational domains cites. What this eliminates is specific: no more a scheduling engine and a compliance evaluator disagreeing on what tower_height_ft means because one inherited a stale unit assumption, no more a zoning verdict whose regulatory citation was hand-typed into application code and drifted from the actual ordinance text, no more an audit log format that differs subtly enough between subsystems that a single verification pass cannot check all of them.

The metrics worth watching mirror the ones tracked in the compliance architecture domain, applied at the reference-plane level. Watch the field-resolution failure rate — a rising count of FieldResolutionError events means a new vendor source is arriving faster than its aliases are being registered in the Canonical Field Dictionary. Track citation coverage as a percentage of canonical fields, so no field governing a regulatory threshold is ever missing its source in the Regulatory Source Crosswalk. And keep the manifest-hash verification pass rate at one hundred percent across every domain that reads from this reference plane, exactly as the Audit Log Schema Reference requires — any drop there means either tampering or a definition that changed without going through the reviewed write path.

FAQ #

Related #

• Canonical Field Dictionary — the field catalog: canonical names, types, units, and every registered vendor alias.
• Regulatory Source Crosswalk — the authoritative field/control-to-statute mapping across FCC, NIST, and OSHA sources.
• Audit Log Schema Reference — the fixed SHA-256 seal format every domain’s audit trail conforms to.
• Telecom Tower Compliance Architecture & Data Mapping — the compliance domain that cites this reference plane for its lease, zoning, and access rules.
• Up one level: telecomtower.org home — the full telecom tower maintenance and lease-compliance automation reference.