SDVOSB — Service-Disabled Veteran-Owned Small Business Ret. USAF F-15C pilot · 22-year veteran A KBM Solved IT company
KBM Air
Request a walkthrough

Weather communications & briefing distribution

AeroVox

The observation is accurate. The briefing built from it should be too — word for word, every time.

MVP Demonstrated

AeroVox is not an ATIS or AWOS replacement and is not connected to any transmitter. It is the layer that turns an authoritative observation into a briefing a person can actually use — rendered into standard phraseology by explicit rules, published with its transcript beside it, and voiced clearly in four languages for the briefing channels an operator already runs. The idea started in a cockpit at Fort Myers with a broadcast that was barely intelligible; the product it became is about the quality and auditability of the briefing, not about taking over the frequency.

Status Working proof of concept on live public weather data — thirteen airports, four languages. Not an ATIS or AWOS replacement, not connected to any transmitter, and not certified for operational use.

Hear the comparison Read what is not built first
Illustrative Legacy rendering against deterministic rendering — a diagram, not live data.

The problem

The briefing is where an accurate observation goes to be misunderstood.

The observation itself is good. What people receive is often not: fragments concatenated by decades-old equipment, read at speed, through a marginal receiver, at the end of a long day. Operators end up rekeying weather into briefing packets by hand, which is slow and introduces exactly the transcription errors the automation was supposed to remove. Every non-native English speaker in the same airspace has a harder version of the same problem, and adding a language to legacy equipment means recording a voice library, so it does not happen.

  • Hand-built briefings are where transcription errors enter a workflow that started out accurate.
  • Adding a second language to legacy broadcast equipment is effectively impossible, so mixed-language operations are served in one language.
  • Anything generative in the loop makes safety-relevant text unauditable — which is why the obvious fix has not been applied properly.

The answer

Render it by rule, publish the words beside the audio, keep a human in front of it.

AeroVox parses the authoritative observation into a language-neutral structure, then renders it into standard phraseology through per-language rule engines with no generative step anywhere in the text path. The result is published as text and as clear speech, together, so a qualified person can check the words against the source before the briefing is distributed. Adding a language is one new renderer, not a new voice library — and because the text is deterministic, the same observation produces the same briefing, in every language, every time.

What it does · 5 capabilities

The parts of AeroVox worth watching

Each capability below exists in the build described on this page. Anything planned rather than present appears under status, not here.

  1. Deterministic phraseology engine

    The observation is parsed into a language-neutral structure, then rendered into standard phraseology by explicit rules. The same observation produces the same script, always, and every spoken phrase traces back to a field in the observation.

  2. Native multilingual rendering

    Each language has its own rule-based renderer with its own digit words, lexicon, number handling and word order. Translation is never performed by a model — that would break auditability for safety-relevant text. Adding a language is one new renderer, not a re-recorded voice library.

  3. Text published beside audio

    Every rendered briefing is published with the source observation and the generated script next to it, so a reviewer checks words against fields rather than trusting what they heard. This is what makes human review practical rather than nominal.

  4. Clear briefing voice

    The generated script is spoken at a quality nobody has to strain to parse. The voice layer is the last step and the only step a model touches: the AI is the voice, never the author.

  5. Side-by-side comparison you run yourself

    The demonstration plays a legacy automated rendering of an observation against the AeroVox rendering of the same observation, back to back. It is an argument a listener settles for themselves in about fifteen seconds.

Boundaries

What it will not do, what it touches, and how it fails.

Three questions any operator should ask before an evaluation, answered before you have to ask them.

Human control Where the authority stays

AeroVox generates a briefing; it does not decide anything and it does not distribute anything on its own. Nothing it produces reaches an aviation frequency, and in any deployment a qualified person reviews the rendered text against the source observation before the briefing goes to crews — which the published transcript is specifically designed to make quick. The text path is deliberately free of generative models so that every word can be traced to the observation and defended to a regulator. Authority over what is published stays with the operator of the weather station and the people who brief from it.

Privacy boundary What it touches

AeroVox holds no personal data of any kind. Its only input is a public weather observation, retrieved from a public aviation weather service that requires no credential and identifies no individual. There is no user account, no manifest, no crew record and nothing to retain. It is the simplest privacy story in the portfolio, and that is a deliberate property of the design rather than a stage it will grow out of.

Degraded mode When something is unavailable

If the public weather service is unreachable, AeroVox does not render a briefing from stale data — the last good observation stays visibly timestamped and no new briefing is produced from nothing. If the voice layer is unavailable, the rendered text still publishes, because the words are the safety-relevant artefact and the audio is the delivery. The text path has no model dependency at all, so it cannot be taken out by one.

The same questions answered across the whole portfolio, with dates: trust & safety

Honest status · MVP

What is built — and what is not.

Working proof of concept on live public weather data — thirteen airports, four languages. Not an ATIS or AWOS replacement, not connected to any transmitter, and not certified for operational use.

Built and exercisable today

  • End-to-end pipeline: live observation, deterministic parse, per-language phraseology rendering, natural voice synthesis, published with transcript.
  • Thirteen airports in the demonstration build spanning major hubs, mid-size and uncontrolled fields, two military installations and three international sites.
  • Four languages — English, Spanish, French, Portuguese — each with its own rule-based renderer, all driven from one neutral observation.
  • Metric and imperial handling where regional convention differs, including pressure units and visibility.
  • A published transcript beside every rendered briefing, so the audio can be checked against the source.

Not built — named, not hidden

  • No transmitter, datalink or broadcast-system integration. Nothing produced here is transmitted on an aviation frequency, and AeroVox is not a replacement for an ATIS, AWOS or ASOS installation.
  • No workflow tooling for the human review step yet — review today means reading the published transcript against the observation, not clicking an approval in a queue.
  • Not certified, approved or accepted by any aviation authority. Any operational use of rendered weather content would be the operator’s decision in consultation with their own regulator.
  • Runway assignment in the demonstration is a placeholder, and automated runway selection from wind is future work.
  • Runway visual range, wind shear, runway condition codes and live notices to airmen are not in the phraseology set yet.

Claims and evidence

Every claim, at the tier its evidence supports.

If a claim below is worded more strongly than its basis justifies, it is a defect and we want to hear about it.

AeroVox — claims and their basis
Claim Tier Basis
The same observation always produces the same rendered text, in every supported language. Demonstrated Rule-based renderer with no generative step anywhere in the text path.
Thirteen airports are rendered in the public demonstration build across four languages. Demonstrated Demonstration build output — thirteen airports, twenty-one language renderings.
Briefings are generated from live public aviation weather observations, not fixtures. Demonstrated Public aviation weather service ingestion, no credential required.
A new language is added by writing one renderer, with no re-recording and no model involvement in the text. Demonstrated Four renderers implemented against one shared observation structure.
The rendered voice is easier to understand than legacy automated audio. Concept Listener judgement from the side-by-side comparison. No controlled intelligibility study has been run — a measured claim would require one, and we do not make one.

Fair questions

What people push back on — and the honest answer

These are the objections this product actually gets. None of them has a clever answer, which is why they are worth printing.

  • Are you proposing to replace our ATIS or AWOS?

    No. AeroVox is not a replacement for an ATIS, AWOS or ASOS installation, is not connected to any transmitter, and nothing it produces goes out on a frequency. It is a weather-communications layer that renders an authoritative observation into a reviewable briefing for the channels you already run. Anything beyond that would be a regulated change to a certified installation, and it is not what this product is.

  • If a model is involved at all, how is this auditable?

    Because the model is nowhere near the words. The text path — parse, render, phraseology, every language — is explicit rules end to end, which is why the same observation always produces the same script and why every phrase traces to a field. A model reads the finished script aloud. Remove it and you still have a complete, correct briefing in text.

  • Who is accountable for what goes out?

    The operator, exactly as today. AeroVox publishes the rendered text next to the source observation specifically so the review is a fifteen-second read rather than a leap of faith. What we have not built yet is a queue and an approval workflow for that review — it is on the "not built" list on this page rather than implied by the word "workflow".

Who buys this

Who AeroVox is built for

The operators whose problem this product is actually shaped around. Each has its own path from first contact to a decision.

Airports & FBOs

Airport operators and fixed-base operators responsible for the weather information that reaches pilots and operations staff on the ground.

Government & sovereign aviation

Public-sector, defence and state operators whose data cannot leave their environment and whose decisions must be defensible on the record.

Part 135, charter & fractional

On-demand and fractional operators flying short-notice missions where the schedule is written the night before and rewritten in the morning.

Next step

Hear the comparison

The fastest thing in the portfolio to judge: the same live observation rendered by legacy automation and by AeroVox, back to back, with both transcripts on screen. No briefing required.

Hear the comparison