Waymark Flight

Overview #

Waymark Flight answers the questions a pilot or drone operator asks about the airspace around them. You describe the airspace — a few circles and rings with floors and ceilings — and give the last seconds of the flight; it says which areas the aircraft is inside, whether it is flying under a shelf, what boundary it will cross next and when, how far it is from the nearest restricted area and what to do about it. It can also propose a route from one point to another that stays out of the areas it must avoid.

Waymark Flight is the airspace model of the Waymark series. It reads an airspace scene of up to 24 cylinder or ring-shaped volumes — Class B, C and D surface areas and shelves, restricted and prohibited areas, temporary flight restrictions (TFR) and military operations areas (MOA) — plus an observed flight track of up to twelve points and the kind of mover (drone, light aircraft, helicopter or jet). One forward pass returns the containment set, the ring tier, whether the mover is under a shelf, the next boundary event with its ETA, whether the projected track enters a hazard volume, lateral and vertical margins to the nearest active hazard, the ceiling overhead and an advisory. Its planning decoder proposes up to eight waypoints that avoid restricted, prohibited and TFR volumes and, unless a clearance is allowed, controlled airspace, within the mover’s altitude envelope (drones at most 400 ft above ground).

Containment, boundary events and route planning are all solvable exactly with code, and the Falcon API runs that code on every request. Waymark Flight’s value is a robust reading from noisy, partial tracks — where the exact check, applied to a jittery track, misses more hazard entries than the model does — and fast combined answers in one pass. The exact checker is the guarantee: every reading is returned beside the exact one, the served advisory is the more cautious of the two, and every served route has passed the exact validator.

Waymark Flight is decision support and education only. It is not certified for navigation, and its training airspace is synthetic.

Intended use #

• Flight-training and education tools that explain where an aircraft stands relative to layered airspace, with the exact answer shown beside the model’s.
• Drone-planning and simulation tools that want a quick reading of a noisy track and an early warning of a hazard entry.
• Proposing a route through a caller-supplied scene that stays clear of restricted, prohibited and TFR volumes, validated before it is returned.
• Research on learned airspace readings, using the exact check and the disagreements field as a running comparison.

Out of scope #

• Navigation, flight planning of record, or any decision where a wrong answer has physical consequences. Not a navigation or safety system.
• Knowing real airspace: Waymark Flight does not know real charts, NOTAMs or TFR schedules and never looks them up; the caller supplies every volume.
• Polygonal or irregular airspace, airways, terrain, weather, traffic and wind; volumes are circles and rings only.
• Altitudes above 18,000 ft MSL, more than 24 volumes, or tracks longer than twelve points.

Choose Waymark Flight when #

• The question is about an aircraft or drone in a described airspace: what it is inside, what comes next, and how to route around what it must avoid.
• The track is noisy or partial and a reading robust to tracker jitter matters, with the exact check alongside.
• The scene is a photographed street and the mover is a person — choose Waymark Extra to simulate a walk, or LIM3D-XL to read an observed track.
• Only an exact answer is needed and no model reading is wanted — the exact checker alone is the right tool; Waymark Flight returns its result in exact on every call.

Architecture #

Waymark Flight is a pre-LayerNorm transformer encoder over numeric tokens, with no text vocabulary: a global token (mover kind, task and track summary), a planning token (start, goal, constraints and envelope), twelve track-step tokens and up to twenty-four volume tokens. Each volume token carries its kind, its shape (cylinder or ring), its centre relative to the mover as distance and bearing, its radii and the signed distances to its rings, its floor and ceiling relative to the mover’s altitude, whether it is active, the field elevation, the tier and the closing and tangential speed toward it. Volume tokens carry no position embedding, so the reading is the same whatever order the volumes arrive in. Every feature is relative to the mover and scenes were rotated at random during generation, so the frame’s origin and orientation do not matter.

The encoder feeds per-volume heads — an inside logit and a next-event pointer with a “none” option — and scene-level classifiers for tier, under-shelf, event kind, advisory, hazard entry and route feasibility, plus regressions for the ETA, the two margins and the ceiling. A three-layer causal decoder with cross-attention to the encoder emits waypoints (east, north and altitude relative to the start) one at a time, with a stop logit, up to eight. The small size (5.3M parameters, 256 wide) exists in the trainer; the served model is the base size.

What is deliberately absent: no map, no terrain, no real airspace data and no clock — the model sees only the scene and the track it is given. The exact geometry checker and the A* planner are not part of the network; they run beside it on every request.

Inputs & outputs #

Input #

Every request carries an airspace scene. A volume is a cylinder, or a ring when inner_radius_nm is above zero, in a local east/north frame in nautical miles with any origin; altitudes are feet MSL, and a floor_ft of null means the volume starts at the surface. The full volume shape is on the input formats page. This scene is hand-built for illustration — a Class B surface area and one shelf around “Field A”, and a restricted area — and does not describe real airspace:

{
  "volumes": [
    {"id": "B0", "kind": "class_b", "center": {"x_nm": 0, "y_nm": 0}, "radius_nm": 5, "floor_ft": null, "ceiling_ft": 10000, "airport": "Field A", "field_elev_ft": 0, "tier": 0, "name": "surface area"},
    {"id": "B1", "kind": "class_b", "center": {"x_nm": 0, "y_nm": 0}, "radius_nm": 10, "inner_radius_nm": 5, "floor_ft": 3000, "ceiling_ft": 10000, "airport": "Field A", "field_elev_ft": 0, "tier": 1, "name": "shelf 1"},
    {"id": "R1", "kind": "restricted", "center": {"x_nm": -2, "y_nm": -7}, "radius_nm": 2, "floor_ft": null, "ceiling_ft": 6000, "name": "example restricted area"}
  ],
  "track": [
    {"t_s": 0, "x_nm": -12.9, "y_nm": -7, "alt_ft": 2500},
    {"t_s": 10, "x_nm": -12.6, "y_nm": -7, "alt_ft": 2500},
    {"t_s": 20, "x_nm": -12.3, "y_nm": -7, "alt_ft": 2500},
    {"t_s": 30, "x_nm": -12.0, "y_nm": -7, "alt_ft": 2500}
  ],
  "mover": "light"
}

Limits on the input:

• At most 24 volumes with unique ids (default V1 … Vn); kind is one of the seven volume kinds; active defaults to true, inner_radius_nm and field_elev_ft to 0 and tier to −1 (0 is a surface area, 1 and up are shelves).
• A track has 1–12 points in ascending t_s. The current state is the last point; velocity is a least-squares fit over the last five points with one outlier-rejection pass. A single point, or points with no time span, mean zero velocity and no projected events.
• Boundaries follow one convention: inner radius inclusive, outer radius exclusive, floor inclusive, ceiling exclusive. Inactive volumes never contain the mover, produce events or count for margins, ceilings or tiers.
• Every coordinate is within ±150 NM of the origin, every altitude between −2,000 and 60,000 ft and every radius at most 100 NM; values outside these ranges are rejected with 400.
• The body is at most 64 KB; a larger body is refused before it is read and the connection is closed without a JSON error. Coordinates may use any origin inside those bounds; the model works relative to the mover.

Output #

{
  "ok": true,
  "engine": "waymark-flight",
  "model": {"inside": [], "tier": "none", "under_shelf": false, "next_event": {"volume": "R1", "kind": "enter_lateral", "eta_s": 259}, "hazard_entry": true, "margin_lat_nm": 7.9, "margin_vert_ft": 10000, "ceiling_ft": 18000, "advisory": "monitor"},
  "exact": {"inside": [], "tier": "none", "under_shelf": false, "next_event": {"volume": "R1", "kind": "enter_lateral", "eta_s": 267}, "hazard_entry": true, "margin_lat_nm": 8.0, "margin_vert_ft": 10000, "ceiling_ft": 18000, "advisory": "monitor"},
  "advisory": "monitor",
  "disagreements": [],
  "notice": "Decision support and education only. Not certified for navigation."
}

How to read the result:

• model is the network’s reading and exact is the geometric checker’s reading of the same input; show both, and trust exact for what the track literally says.
• advisory is the more cautious of the two advisories; on a tie in caution (for example climb against descend) the exact answer is kept, and when the exact check puts the mover inside an active hazard it is at least turn_away.
• disagreements names the fields on which the two readings differ. Categorical fields count when they differ at all; margin_lat_nm counts beyond 0.5 NM and margin_vert_ft and ceiling_ft beyond 250 ft; next_event counts when the volume or kind differs or the ETAs are more than 30 s apart. An empty list means they agree; a non-empty one is the signal to look closer, not to pick the model.
• next_event is the first boundary event on a constant-velocity projection over 300 s, or null. hazard_entry is true when the projection enters an active restricted, prohibited or TFR volume at any point in the horizon, not only as the first event.
• margin_lat_nm is capped at 50 and margin_vert_ft at 10,000 (the vertical margin counts only hazards whose footprint contains the mover); ceiling_ft is the lowest floor of an active controlled or hazard volume overhead, 18,000 when there is none.
• The example values are illustrative of the shape; exact numbers depend on the weights.

Examples #

A route for the same scene, from the aircraft’s position to a point east of the restricted area, without a Class B clearance. The start and goal sit under the shelf at 2,500 ft, below its 3,000 ft floor, so the route stays outside controlled airspace:

{
  "volumes": [
    {"id": "B0", "kind": "class_b", "center": {"x_nm": 0, "y_nm": 0}, "radius_nm": 5, "floor_ft": null, "ceiling_ft": 10000, "airport": "Field A", "tier": 0},
    {"id": "B1", "kind": "class_b", "center": {"x_nm": 0, "y_nm": 0}, "radius_nm": 10, "inner_radius_nm": 5, "floor_ft": 3000, "ceiling_ft": 10000, "airport": "Field A", "tier": 1},
    {"id": "R1", "kind": "restricted", "center": {"x_nm": -2, "y_nm": -7}, "radius_nm": 2, "floor_ft": null, "ceiling_ft": 6000}
  ],
  "mover": "light",
  "start": {"x_nm": -12, "y_nm": -7, "alt_ft": 2500},
  "goal": {"x_nm": 6, "y_nm": -7, "alt_ft": 2500},
  "allow_controlled": false
}

{
  "ok": true,
  "engine": "waymark-flight",
  "source": "model",
  "feasible": true,
  "waypoints": [
    {"x_nm": -12, "y_nm": -7, "alt_ft": 2500},
    {"x_nm": -2, "y_nm": -9.8, "alt_ft": 2500},
    {"x_nm": 6, "y_nm": -7, "alt_ft": 2500}
  ],
  "check": {"valid": true, "reached": true},
  "latency_ms": 12,
  "notice": "Decision support and education only. Not certified for navigation."
}

The route bends south of the restricted area, keeping more than the 0.5 NM buffer, and passes under the shelf without entering the surface area. Had the proposal clipped the restricted area or missed the goal, source would read oracle and the waypoints would be the exact planner’s. A landing goal is written {"land_at": "B0"}; the planner then relaxes the envelope floor within 5 NM of that volume’s airport.

Training #

Waymark Flight was trained from scratch as a Google Cloud Vertex AI custom job on one NVIDIA L4. The job allowed 40 epochs and stopped early at epoch 22 — about 64 minutes of training and 68 minutes of job time — on a validation score dominated by the missed-entry rate. The dataset was generated on the owner’s machine and uploaded with the job.

The data is synthetic airspace only: 250,000 generated scenes, each yielding one tracking and one planning example, about 484,000 examples in all. A scene has a primary airport with Class B, C or D airspace built as a surface area plus stepped shelves, up to three more Class D airports, restricted areas (some scheduled inactive), prohibited areas, TFRs and MOAs, with field elevations from sea level to 5,000 ft; 12 % of scenes are dense (20–24 volumes). Movers are drones, light aircraft, helicopters and jets, flying behaviours chosen to graze boundaries: under a shelf, climbing into or descending through a shelf floor, crossing a ring, skirting or heading at a hazard, descending into Class D, circling, sitting on a boundary. Tracks carry none, light, medium or heavy tracker-style position and altitude noise and up to five dropped points, against labels computed on the clean track. 35 % of planning examples use hard layouts — dense restricted areas, narrow gaps, routes under a shelf, goals near a TFR.

Every label comes from the exact geometry oracle (version ring-oracle/1.0) and every route target from its weighted A* planner, followed by exact shortcutting to at most eight waypoints; examples the planner could not solve inside its search limit were dropped. The dimensions are illustrative, not regulatory data.

Recipe: base size, AdamW with a cosine schedule, peak learning rate 6e-4, batch 1,024, seed 7, bf16 autocast. Losses are weighted so that misses cost more than false alarms: hazard-entry positives weigh four times, inside labels on hazard volumes and next-event targets that are hazard entries three times, and action advisories twice.

What it was not trained on: real airspace, charts or NOTAMs; real flight tracks or ADS-B data; polygonal volumes, terrain, weather or traffic.

Evaluation #

The figures come from the 2026-09-18 Waymark Flight evaluation (report.md and results.json), scored against the exact oracle on fresh synthetic scenes. Tracking sets have 1,500 tracks each; planning sets 500 requests each. As a baseline the evaluation also runs the exact oracle on the same noisy track the model sees, which is what a checker alone would answer in practice.

On every tracking set the model misses fewer hazard entries than the exact check applied to the same noisy track, and on every set it raises more false alarms — the trade the serving threshold of 0.35 was chosen for. Held-out margin errors are 0.76 NM lateral and 320 ft vertical, and the ceiling error 136 ft; the exact check on the noisy track is far closer on margins, which is why the served response carries both.

Served validity is the model’s proposal plus the exact validator plus the exact-planner fallback, and it is 100 % on every set by construction. The model alone produces a valid route that reaches the goal in 78 % of held-out requests and 15 % of dense restricted layouts. Stated plainly: the exact planner is faster than the model’s proposals at the median on every planning set (1.3 ms against 11.1 ms held-out), though its 95th percentile reaches 225 ms on dense restricted layouts. The planning decoder is a proposer, not a replacement for the planner.

Known gaps. The ground truth is the oracle on synthetic scenes, so these figures say how well Waymark Flight reproduces exact geometry in its own world, not how it performs on real airspace or real tracker output. No real flight data, no human evaluation and no comparison with a certified system exist. Latencies were measured in the evaluation harness, not through the Falcon API.

API #

Route /v1/airspace/read · quota bucket spatial · body limit 64 KB.

Waymark Flight is public on the Falcon API at POST /v1/airspace/read and POST /v1/airspace/plan. Both count against the spatial preview quota bucket, shared with /v1/spatial and /v1/move, and each body is limited to 64 KB. The base URL, envelope, authentication, rate limits and retry guidance are documented in API conventions.

POST /v1/airspace/read HTTP/1.1
Authorization: Bearer fln_…
Content-Type: application/json

{
  "volumes": [
    {"id": "R1", "kind": "restricted", "center": {"x_nm": 0, "y_nm": 0}, "radius_nm": 2, "floor_ft": null, "ceiling_ft": 6000}
  ],
  "track": [
    {"t_s": 0, "x_nm": -6, "y_nm": 0, "alt_ft": 2500},
    {"t_s": 30, "x_nm": -5.1, "y_nm": 0, "alt_ft": 2500}
  ],
  "mover": "light"
}

{
  "ok": true,
  "engine": "waymark-flight",
  "model": {"inside": [], "tier": "none", "under_shelf": false, "next_event": {"volume": "R1", "kind": "enter_lateral", "eta_s": 101}, "hazard_entry": true, "margin_lat_nm": 3.1, "margin_vert_ft": 10000, "ceiling_ft": 18000, "advisory": "turn_away"},
  "exact": {"inside": [], "tier": "none", "under_shelf": false, "next_event": {"volume": "R1", "kind": "enter_lateral", "eta_s": 104}, "hazard_entry": true, "margin_lat_nm": 3.1, "margin_vert_ft": 10000, "ceiling_ft": 18000, "advisory": "turn_away"},
  "advisory": "turn_away",
  "disagreements": [],
  "notice": "Decision support and education only. Not certified for navigation."
}

/v1/airspace/read takes volumes, track (1–12 points {t_s, x_nm, y_nm, alt_ft}, ascending t_s) and mover (drone, light, helicopter or jet), all required. /v1/airspace/plan takes volumes, mover, start {x_nm, y_nm, alt_ft}, goal ({x_nm, y_nm, alt_ft?} or {land_at: volumeId}), optional allow_controlled (default false) and an optional track, and returns source (model or oracle), feasible, reason when infeasible, waypoints, check (the exact validator’s verdict, with valid and reached), latency_ms and notice; a full plan exchange is under Examples. engine is always ring. The values above are illustrative of the shape.

Errors:

An infeasible plan is not an error: it answers 200 with feasible: false and a reason such as start_in_blocked, goal_in_blocked, start_in_controlled_no_clearance, goal_outside_envelope, no_route or no_route_without_clearance.

Runtime & deployment #

Waymark Flight runs as a CPU service on Cloud Run, fronted by the Falcon API; a preview key never reaches the service directly. The container holds the weights, the exact geometry checker and the exact planner, and every request runs both the model and the checker. The service scales to zero when idle, so the first call after a quiet period waits a few seconds while it starts and may answer 503 flight_warming with a Retry-After of 20 s; later calls answer in milliseconds of model time plus the network.

• Pairing. /v1/airspace/read always returns model and exact side by side; /v1/airspace/plan validates the model’s proposal segment by segment and falls back to the exact planner, so a served route is always valid under the exact checker.
• Selection. There is no request field: both routes are bound to Waymark Flight, and engine reads ring.
• Metering. Both routes count in the spatial bucket, once per call that reaches the service.
• Retries. Retry 503 flight_warming after Retry-After; retry 503 flight_unavailable and 502 flight_failed once after 2.5 s.

What the host must provide:

• The airspace volumes, from an authoritative source the host is responsible for, converted to the local east/north frame in nautical miles and feet MSL.
• A track from its own tracker, at most twelve points, newest last.
• A presentation that shows the exact reading and the notice, and never presents a Waymark Flight answer as a navigation instruction.

Limits & safety #

• Not certified for navigation. Not a navigation or safety system; no answer is a clearance or an instruction.
• Synthetic, illustrative airspace: the training scenes use made-up dimensions, and Waymark Flight is not a source of real airspace data.
• The caller supplies the volumes. Waymark Flight does not know real-world airspace, NOTAMs or TFR schedules; a volume the caller leaves out does not exist for it, and active is whatever the caller says.
• Weakest near boundaries (within a few hundred feet or about 0.1 NM), under heavy tracker noise and for very slow drones. Missed hazard entries in the evaluation: 1.4 % held-out, 1.7 % dense, 0.9 % shelf transit, 4.2 % fast jets, 6.9 % slow drones, 7.1 % boundary-near and 9.3 % under heavy noise.
• False alarms are the price of fewer misses: up to 10 % of slow-drone tracks raise a hazard entry that the clean track does not have.
• The model’s own route proposals fail the exact validator often in dense layouts (27.8 % valid on dense restricted sets); only the served route, after the check and fallback, is guaranteed valid — and only against the volumes supplied.
• Circles and rings only, at most 24 volumes, twelve track points and 18,000 ft; a constant-velocity projection of 300 s cannot anticipate a turn.

Out of scope: real flight operations, dispatch, drone operations of record, and any use where a missed boundary has physical consequences. Hosts should show the exact reading beside the model’s and treat a non-empty disagreements list as a prompt to check, never as a vote.

Fixed weights per version; the model does not learn from requests.

Versions #

Compatibility. A major version bump means the request or response contract changes — a new required field, a different frame or units, or a changed catalogue of volume kinds, movers, tiers, event kinds or advisories — and a host must be updated to read it. A minor bump is a retrain with the same contract: readings and proposals may differ, but the fields and catalogues are the same, and the exact check is unchanged. A patch bump changes only metadata or runtime settings.

Current weights: the best checkpoint (epoch 22) of the 2026-09-18 Vertex AI job, exported as ring.bin, 85,400,498 bytes in float32, base size, 21,348,514 parameters, paired with the exact oracle ring-oracle/1.0. Weights are not distributed during the private preview; see Access.