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.
| Source | Feed | Update cycle | Coverage |
|---|---|---|---|
| NOAA / NWS | aviationweather.gov METAR endpoint (public, unauthenticated) |
Every 20–60 min per station (station-dependent) | All FAA-registered U.S. airports with surface observations |
| FAA SWIM Not connected in this demonstration |
System Wide Information Management METAR/TAF topic | Event-driven | Supplement for participating NAS facilities |
| ICAO international | Country-specific METAR feeds (publicly accessible) | Per ICAO station schedule (typically 30 min) | International demo airports (MDPC, LFPG, etc.) |
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.
| Scenario | AeroVox behavior | Existing AWOS |
|---|---|---|
| METAR feed temporarily unavailable | Retains the most recently generated broadcast and retries on the next polling cycle. Operational staleness handling must be validated for each approved deployment. | Unaffected; continues operating on its own sensor and data path |
| AeroVox cloud service outage | Broadcast endpoint becomes unavailable. If a cached broadcast is available at the edge node, it continues to serve until connectivity restores. If not, the endpoint returns a clear error. | Unaffected; no dependency on AeroVox cloud infrastructure |
| Voice synthesis failure on a single broadcast cycle | Previous successfully generated broadcast is retained and the next cycle re-attempts synthesis. Alert routing is a production deployment requirement. | Unaffected |
| METAR parses to an unexpected or edge-case value | Deterministic engine applies conservative fallback: omit the affected clause, retain all parseable fields. The broadcast does not guess. An internal flag is logged for review. | Unaffected |
| Internet connectivity loss at airport | If edge-mode is deployed: last generated broadcast continues on local cache. If cloud-only: broadcast endpoint unreachable from the audio chain, which falls back to AWOS. Reconnection is automatic on restore. | Unaffected |
AeroVox is architected for a 99.9% monthly uptime target for the cloud-managed service tier. This is a design target, not an operational SLA: no customer SLA is in force today. 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.
| Deployment tier | Uptime target | Maintenance windows | SLA basis |
|---|---|---|---|
| Cloud (managed) | 99.9% monthly | Communicated ≥ 24 hours in advance; scheduled off-peak | Included in service agreement |
| On-premise | Customer-determined | Customer-controlled; engine updates via signed artifact delivery | Negotiated per contract |
| Air-gapped / sovereign | Customer-determined | Offline update bundles; no live cloud dependency | Negotiated per accreditation path |
- Infrastructure: The current demonstration runs as a managed cloud service. Production availability, redundancy, and failover commitments require a documented deployment design and service agreement.
- Broadcast re-bake: when an airport is explicitly configured for live operation, the current poll interval defaults to 30 minutes. Immediate weather-event ingestion requires an authoritative event feed.
- Audio delivery: generated audio is served by the configured deployment. CDN behavior and outage handling must be validated before an operational commitment.
- Monitoring: local health reporting is available. Alert routing and airport escalation procedures are required production controls.
AeroVox's security posture is rooted in a minimal-access design: the system does not require airport internal-system access or an airport-network connection. The public sample workflow collects contact details supplied by prospects and is handled separately from weather processing.
- Contact-data boundary: weather processing does not use passenger, crew, or staff data. The optional public sample form records prospect contact details and IP metadata; production data handling must follow the applicable privacy notice and retention policy.
- 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 public sample endpoint uses abuse controls, not customer token authentication. Production broadcast APIs require scoped authentication and rotation before operational use.
- Transport encryption: public production deployments must be served over HTTPS with deployment-specific TLS configuration verified before operational use.
- Audit log integrity: append-only broadcast logs, hashes, job identifiers, and tamper detection are required production controls; they are not claimed for the current demonstration.
Because the phraseology engine is deterministic, a production deployment can be designed for full after-the-fact auditability. Historical reconstruction requires retained source observations, engine versioning, and an approved audit store; those controls are deployment requirements, not features asserted for this demonstration.
- Required production log entry: timestamp, source METAR text, parsed field set, generated script, synthesis job ID, audio hash, and engine version.
- Required engine versioning: approved deployments must retain a version identifier for the rules used in each broadcast.
- Required script-to-METAR mapping: a production audit store should retain the field mapping needed for word-level traceability.
- Replay capability: retained observations and versioned rules can support deterministic replay when the deployment includes those controls.
- Retention and access: retention periods and airport access must be agreed in the deployment's governance and authority-approved operating model.
Questions
Request a technical briefing
Procurement officers, FSDO contacts, and technical evaluators can request a direct engineering briefing. We will walk through the engine, the data path, and the failure modes in as much detail as needed.