How AeroVox is built to be trusted

AeroVox synthesizes voice from weather data, not the other way around. All weather inputs are sourced exclusively from publicly available, authoritative government feeds. AeroVox never accesses airport-internal networks, proprietary sensors, or private data systems.

AeroVox uses a deterministic phraseology engine — a fixed rule set that maps parsed METAR fields to spoken phrases using FAA and ICAO standard vocabulary. There is no language model involved in script composition. The AI is used only at the voice synthesis step — it speaks the script, it does not write it.

• Rule-based composition: each clause in the broadcast (wind, visibility, ceiling, altimeter, etc.) is produced by a deterministic template that accepts typed inputs and produces a fixed output. The same METAR always produces the same script.
• Field-level traceability: every spoken word can be traced back to a specific field in the source METAR. No word appears in the broadcast that does not derive from the observation or from a fixed facility convention.
• Reproducible: given the same METAR and facility configuration, the script — and therefore the audio — is identical on every run. This property is verifiable by the customer.
• No generative invention: the system cannot hallucinate weather data. If a METAR field is absent or unparseable, the corresponding clause is omitted, not estimated.
• Locale-aware: Spanish, French, and Portuguese scripts are produced by locale-specific phraseology tables, not machine translation. Unit conventions (QNH vs. altimeter, metric vs. statute) follow the locale standard.

AeroVox is an augmentation layer, not a safety-critical sole source. The existing AWOS, ASOS, or ATIS infrastructure at a pilot airport remains live and unchanged throughout any AeroVox deployment. No failure mode in AeroVox can interrupt the existing authoritative broadcast path.

AeroVox targets 99.9% monthly uptime for the cloud-managed service tier. This corresponds to a maximum of approximately 44 minutes of downtime per month. On-premise and air-gapped deployments are not subject to a cloud SLA — availability is determined by the customer's own infrastructure and subject to their SLA requirements.

• Infrastructure: Cloud tier runs on Render (managed PaaS) with auto-scaling and multi-region failover capability. Render publishes its own status at status.render.com.
• Broadcast re-bake: default cadence 30 minutes, aligned to the ATIS cycle. Re-bake is triggered on weather signature change or on the timer, whichever comes first.
• Audio delivery: generated audio files are cached at the CDN edge layer and served independently of the synthesis pipeline. A CDN outage does not stop the synthesis service.
• Monitoring: internal health checks on every synthesis cycle. Anomalous behavior triggers an alert to the engineering team. Pilot airports receive a direct escalation path.

AeroVox's security posture is rooted in a minimal-access design: the system does not collect personally identifiable information, does not access airport internal systems, and does not sit on any airport network. The attack surface is narrow by design.

• No PII collection: AeroVox processes weather data, not people data. No passenger, crew, or staff information is collected, stored, or transmitted at any point.
• No airport system access: AeroVox pulls weather exclusively from publicly available NOAA/FAA/ICAO feeds. It does not connect to airport AWOS hardware, ATIS controllers, radio systems, or internal networks.
• METAR is public domain: the data AeroVox ingests is the same data available to any member of the public at aviationweather.gov. No data protection concerns apply to the input stream.
• Audio output is non-sensitive: generated broadcasts contain only the information already in the public METAR. There is no sensitive information in the output.
• API authentication: the sample broadcast endpoint and any production broadcast API use token authentication. Tokens are scoped per airport and rotated on demand.
• Transport encryption: all communications between AeroVox services use TLS 1.2+. Audio delivery is served over HTTPS.
• Audit log integrity: broadcast logs are append-only. Log entries include the source METAR hash, the script hash, the voice synthesis job ID, and the timestamp. Tampering is detectable by hash comparison.

Because the phraseology engine is deterministic, every broadcast is fully auditable after the fact. A regulator, an airport director, or a legal investigator can reconstruct any historical broadcast from its source METAR and the engine version hash — and confirm that the broadcast faithfully represented the authoritative observation at that moment.

• Per-broadcast log entry: timestamp, source METAR text, parsed field set, generated script (all four languages where applicable), voice synthesis job ID, audio file hash, engine version.
• Engine versioning: each release of the phraseology engine is tagged with a version identifier. The version used for each broadcast is logged. A regulatory review can identify exactly what rules were applied.
• Script-to-METAR mapping: the log includes a field map — a machine-readable record of which script clause was produced by which METAR field. This makes word-level traceability available without manual review.
• Replay capability: any historical broadcast can be regenerated by re-running the logged METAR through the logged engine version. The output is deterministically identical to the original.
• Log retention: default retention is 90 days for cloud-managed tier. Extended retention (1–7 years) is available and recommended for production deployments subject to FAA recordkeeping requirements.
• Log access: production airports receive read access to their own broadcast log via a secure endpoint. Logs are never shared between airports.