Helping travelers identify ticket flexibility

We’ve added an optional airline selector to the inputs widget: if the user specifies an airline, we’ll check for applicable waivers along their itinerary. While airlines have meaningfully improved general rebooking flexibility by eliminating change fees for most tickets, a fare difference can still inhibit rebooking in the face of interruption. These waivers unlock an additional level of flexibility to navigate yourself around potential disruption.

We’re manually collecting waivers to minimize investment in an unproven feature, but with signs of traction will automate this process1. Until then, there’s likely to be latency in adding them to our database (or even some missed waivers).

From a former SITREP author with ❤️

We also now allow users to specify a single airport, rather than origin and destination (and layover). We think this is especially well-suited for operators, who we hope will use this to save time while writing briefs and SITREPs.

Accordingly, we’ve encouraged GPT to output longer responses when summarizing just one airport and will likely explore further prompt differentiation (like permitting it to use more technical language) in the future.

Latest version is available at close-in.aerology.ai—blue skies and tailwinds!

But as the above-linked post suggested, we’ll mostly be using this space to update readers on what we’re building. So what’ve we been hacking on this last week? We think it’s something that’s especially relevant as travelers start to look ahead to their Thanksgiving return flights. Give us the airports you’ll be traveling from, to and via; and we’ll distill our much-loved forecast discussions from the National Weather Service using OpenAI’s GPT-4 Turbo.

Some readers might draw parallels to earlier iterations of this newsletter, when we were writing mostly about weather. While those posts could be quite practical, we struggled to provide ample coverage relative to all the airports a traveler might transit (and by the time we had finished writing, some information could already be stale). This distillation delivers much of the utilitarian value that our outlook posts provided, with the benefit of encoding the most recent information and a geographical focus tailored to your travels. You could almost consider it an on-call Tim.

We’ve experimented some with how we prompt the model, but—here especially—we welcome feedback: a broad cross-section of outputs will help us more scientifically tweak how we guide the model in its task. We’ve asked it to overweight the contents of the forecast discussion’s aviation section, avoid jargon or highly technical concepts, and highlight uncertainty. If you’re seeing summaries that are not consistent with this prompt engineering, please pass it along! Finally, we’ve initially designed this product with the mobile experience prioritized, but as we iterate on this new tool alongside our months-ahead forecasts, we’re likely to deliver some desktop improvements.

A beta version is available at close-in.aerology.ai; no credentials are required. Smooth travels!

Tim has also strayed further from Excel in the last few months, tempted more and more by chatGPT and Jupyter notebooks. So he spun up a quick Prophet model (and of course drew from the posterior predictive distribution to keep it probabilistic). Survey says? Perhaps most impressively, it gives the Sunday after Thanksgiving nearly a 1 in 5 chance of reaching 3 million screened. It also gives that Sunday about a 50/50 chance of setting a new all-time record (it even thinks the Wednesday before has about a 1 in 8 chance to reach 2.885 screened).

But while we’re liable to spend a paragraph or two on goings-on around the industry, for the foreseeable future, this newsletter will be about what we’re building. To that end, you can expect us back in your inbox a bit more frequently—probably just under once per week. What’s this first update hold? Let’s get to it.

Giving mobile users some love

Our first version was designed with desktop users in mind1; users could access it on a mobile device, but the ported-over desktop layout was cramped (enough so that usability was impaired, especially on smaller phones oriented in portrait).

With this update, mobile users will see more elements distributed vertically in the search section. And once they click get chances, they should benefit from relatively wider prediction visualizations [such that mobile users should horizontally scroll within the results section].

We expect to continue optimizing the at-booking layout for desktop then remold a serviceable mobile experience (though Google Analytics could prove this assumption wrong). But looking ahead, as we develop a next-day/day-of product, we expect to optimize that layout for mobile users.

Multi-airline itineraries are ‘Coming soon’ no more

Version 1.0.0 included a multi-airline switch, but—if we’re in the trust tree—it was really just there to provide some visual balance. Users would discover it was disabled, with a ‘Coming soon’ tooltip at least teasing its future availability. Version 1.1.0 leaves less to the imagination in this regard, with users able to create an itinerary that features different airlines for leg 1 and 2.

That leaves our Stops selector as the only decorative element, though if users were to think the layout’s visual order guides our task prioritization… we wouldn’t discourage them.

Heads up about that itinerary you’re considering!

Last but not least for this update, we’ve built the plumbing for alerting that’s conditional to the itinerary a user is evaluating. For the moment, we only have two alerts loaded: (1) when you’ve selected a date that is likely beyond airlines’ most recent major load and (2) if you’re transiting SFO when 28L is liable to be closed next year.

We’d love suggestions on other events that you think travelers should be advised of before hitting book—particularly ones our model might not “see.” SFO’s 28L closure is a good example in this respect, as it hasn’t learned the impact of these construction-induced capacity reductions.

As always, general feedback appreciated! Latest version is running at at-booking.aerology.ai.

Because that’s the thing: most OTA’s and aggregators prognosticate about the direction of prices (even if you ignore it). And increasingly, price forecasts are presented alongside emissions estimates. So you’re guided towards the most sustainable option with the most economical timing. But what about the most reliable option? Frequent fliers can recognize a red flag in a routing, though a behavioral economist would wince at the most well-tuned mental model of the national airspace system. (To say nothing of the infrequent flier.)

Layovers and it’s-gonna-be-tight arrival times can be a gamble; we think travelers should be better informed about the odds. To that end, we’ve developed an algorithm that answers how likely is an itinerary to get you there when advertised. More technically, we built a density network. It’s an AI architecture that taps the power of neural networks to estimate the range of possible outcomes—and the likelihoods within that range.

In our case, we’re aiming it at the distribution of delays, a problem where uncertainty abounds even with a prediction horizon of a couple hours. Is your aircraft going to require an unplanned tire change? Is your pilot going to sleep through their alarm? Your catering truck? Could get in a fender bender. Passengers? Pesky things are one airport beer too many away from having to be deplaned. Plus a ripple effect. And that’s when you have a reasonably good idea what the weather is doing and where your plane is coming from!

At a months-ahead horizon—when weather forecasts are more coarse and less skillful—it’s all the more important to frame flight outcomes in terms of chances, not single estimates. Within a practical range of over-blocked, tailwind-aided 60 minutes early to might-as-well be cancelled 24 hours late, no exact delay minute is all that likely. While it might not feel like it, arrival delays gravitate towards negative values (read: early arrival); but even within this relative peak, the single most likely outcome (10 minutes early) only happens about 2.5% of the time.

One approach to dealing with this uncertainty is binning several delay minutes together (see below), rather than treating each delay minute as its own unique possibility (like the above chart does). It makes for an easier prediction task: you’d be trying tease apart fewer outcomes with higher likelihoods. If you bin arrival delays into less than 30 minutes, between 30 and 60 minutes, between 60 and 120 minutes and greater that 120 minutes—like Amadeus does—the bin with the lowest frequency (120+ minutes) is more probable than our most probable single value (-10 minutes exactly).

But easier for the forecaster doesn’t mean more usable for the traveler. The bins mask some material differences. Maybe you can absorb as much as 90 minutes delay, but beyond that you’ll miss the start of the meeting. Or even more consequentially, maybe your 65-minute layover is doable with a 30 minute delay but hopeless with a 55 minute delay.

Our density network is well suited for capturing this uncertainty with much higher resolution, i.e. distinguishing between the 30 and 55 minute delay. Let’s see what that looks like.

Get chances

Consider somebody flying from Syracuse (SYR) to Nashville (BNA) on the Tuesday before Thanksgiving. They’ve found two options with similar travel times that allow for a close-to-full day of work.

They’re a frequent enough flyer to vaguely know EWR’s reputation, but 95 minutes seems generous? And they’re seriously averse to getting in the door after midnight—so the 40-minute earlier arrival should provide a better chance to be in the Uber by 11:45 p.m., right? They switch from their Expedia tab to Aerology’s forecast, input the details for the via EWR option and hit “Get chances.”

Under-the-hood, we’ll estimate the distribution of arrival delays for the SYR-EWR flight and the distribution of departure delays for EWR-BNA, then randomly sample from those distributions. That first sample might “draw” an arrival delay of -6 minutes and a departure delay of 2 minutes; given the scheduled layover of 95 minutes, that first simulation nets out to 103 minutes of available connecting time. Then we do it 9,999 more times and visualize 100 representative outcomes. By default, simulations that provide less than 30 minutes to connect are considered missed and, in the case of our BNA-bound traveler, we forecast they’ll be left with an insufficient layover duration about 9% of the time1.

And while a missed connection is a good bet to screw up your schedule, there’s likely some amount of delay to your originally scheduled arrival that you can’t afford. For this reason, we’ll also sample from our estimated distribution of arrival delays to your second leg (EWR-BNA, in this setup). Here, by default, we’ll assume you can only absorb about an hour of delay; for our BNA-bound, the default is about right with respect to getting in the door by midnight.

Because we don’t need to net out the layover or a second delay for this part of our forecast, you can also use it as a workaround to one our design decisions. To maximize applicability, we’ve geared this initial version towards one stop itineraries; it may be a bit hack-y, but if you want to glean disruption chances for a non-stop itinerary, you can treat the second leg as your non-stop (i.e. use the layover airport as your origin). You’ll need to invent a first leg and, depending on the fictional first leg, the misconnection and headline chances should only be referenced for a laugh. But because our forecast of the second leg’s arrival delay is independent from the first leg, the too late forecast is representative of your non-stop’s chances.

That last sentence is an important distinction. The too late forecast does not ask what are the chances I arrive by this time, given that I make my connection. It provides the chances that the flight arrives by that time—whether you’re on it or not. It’s also why the headline number (12% for our SYR-EWR-BNA option) may not equal the sum of misconnects and too late: there’s some too-late outcomes that could have still resulted in a misconnect. The headline asks what are the chances that I misconnect or arrive too late; it could also be framed as what are the chances I make my connection and arrive on time-ish.

To contextualize that 12% disruption probability, it’s about the same as parents having three children of the same sex. But we think our forecasts are best employed in bunches. It provides better context than thinking through the boy/girl mix of your friends and family. So our BNA-bound traveler opens another tab (… our design road map takes note), inputs the details for the via-ATL option, adjusts the too-late threshold to 11:30 p.m., and finds something like an 8.1% chance to mis-connect or arrive too late. Despite a scheduled arrival time that’s 40 minutes earlier, the over-EWR option is nearly 50% more likely to leave our hypothetical traveler short of their door by midnight.

🤨 And why should I trust you guys?

It’s a fair question. A single prediction can be hard to judge on its own, especially when it’s of the percentages variety. For that reason, we took great care to create a test set numbering more than 4.5 million flights that we can use to evaluate our models’ performance. Because we’ve approached this problem probabilistically (i.e. we’re not making a single estimate but rather estimating likelihoods within a range of possible outcomes), one of our most important metrics is the degree to which forecasts are well-calibrated. If they are well-calibrated, it means an outcome actually occurs at roughly the same frequency as we predicted.

For each flight in our test set, we can segment our predicted distribution. For example, calculate the minute where we’d say there’s a 35% chance that actual delay will be less than or equal to that threshold—then we should find, with a well-calibrated forecast, that actual delay falls into this segment about 35% of the time. In the case of the predicted segment where we’d say there’s a 35% chance for delay less than or equal to that minute, 34.5% of actual values fell within the segment.

We tend to be a bit over-confident at lower probabilities, which is to say these events actually happen less often than we forecast. For the segment where we’d predict 15% of delays will fall in, just 5% actually do. Oppositely, we exhibit some under-confidence for probabilities higher than 50%. But, overall, we think our forecasts performed quite well—certainly well enough to underpin an MVP. It’s an open beta, so no credentials required and feedback welcome!

But! We’re not here to prognosticate about what travelers face this weekend. At least not directly. Today’s post is filed under our favorite category: Product launch.

We sent our first such post in November, wherein we shared our airport arrival capacity predictions.

Aerology

Introduce? Unveil? Announce? Anyways, we've got our first deep learning model to share

We’ve been writing for about a year now and when a post veered into more quantitative waters, it was generally underpinned by Tim working in Excel. Don’t get us wrong, Excel is great—communication ✅, trust ✅, physical intimacy ✅, curiosity ✅, conflict resolution ✅. But its suitability for blog posts doesn’t extend to machine learning and ML engineering…

Read more

4 years ago · 7 likes · 2 comments · Tim Donohue

Somewhere between the Excel sex joke and discussion about our forecast error reduction, we wrote in that product launch:

Admittedly there’s an interpretability hurdle for travelers, especially… For now, we’d recommend travelers pair our [capacity] predictions with the FAA’s airport arrival demand chart (AADC), which helpfully encodes hourly arrival demand by way of the stacked columns. It’s an important piece of information—and not yet piped into Aerology—to triangulate capacity, demand and more-interpretable delay.

Capacity is generally measured in arriving aircraft handled per hour; it’s a sneakily technical concept that some operators don’t entirely grasp. We instructed users on how to manually perform that triangulation but knew it was a tall task for travelers. And even if users gleaned some sense of delay from our capacity predictions, any insight was more or less binary: They could determine if unpublished delay existed or not, but how much delay remained obfuscated.

Minutes, not arrival rates

So the next mile marker on our data science roadmap was a pipeline to gauge demand; that was followed by an algorithm to translate that enigmatic demand overage to more-interpretable delay minutes. With a minimally viable pipeline and translation program built, we’re excited to launch our first delay beta. We think it represents a step change in usability.

Ergo, we don’t think its necessary to spend a few paragraphs instructing users on how to combine this product with other information. But we should define what type of delay we’re predicting (and pin a few qualifiers to these forecasts). In service of a definition, let’s review: When arrival demand for an airports’ runway(s) exceeds its capacity, air traffic control will explicitly or effectively assign arrivals a landing slot. It’s these landing slots we’re aiming to predict—after which we can measure delay relative to some planned landing time. For starters, we’re aggregating the resulting delays; later we’ll reproduce how airlines swap slots among their flights.

We want to highlight a few corollaries to this definition. It reflects air traffic dynamics at the arrival airport—not an imbalance in en-route airspace1 or at the departure airport. So we're not trying to assimilate any delay that occurs at a flight's departure gate or during taxi to takeoff. (Yet.) Similarly, these predictions stop short of modeling any taxi-in delay; nor do they simulate how this landing delay can ripple through the network. (For now.)

That’s a lot of things it’s not. But the type of delay it is—let’s call it airport arrival imbalance delay—was responsible for at least one-third of arrival delays at Core 30 airports in 20192. With a lot of delay types to eventually account for, we think this a good place to start.

It’s also analogous to the delays resulting from ground delay programs and ground stops3 that the FAA communicates via their NAS dashboard. We’re frequent visitors to their dashboard, but Google Trends suggests we’re in a pretty small minority. FlightAware, however—which had more site visitors than Geico in January—has done their part to promote awareness of these delays. They repackage FAA data: when we grabbed the FlightAware screenshot, the NAS dashboard coincidentally featured an active BOS ground delay program with 73 minute average delays.

Delay minimization and you

So why go to some lengths to predict what the FAA already shares? Because of the FAA’s wait-and-see approach to administering these delays. On average, ground delay programs are published less than 60 minutes4 before the first effected flight lands; delays from ground stops are effective immediately with no notice. It's a rational, if optimistic, tack from the FAA. By assuming demand won't materialize or the weather forecast verifies favorably, they avoid creating unnecessary delay. But their wait-and-see approach betrays airlines' ability to plan and squanders rebooking options for travelers.

For the moment, Aerology isn’t charged with minimizing delay. We “just” fit known demand5 to our best, unbiased estimate of capacity. Our delay modeling shares our capacity predictions' 16-hour forecast horizon; flights scheduled or estimated to land inside of 16 hours may be delayed beyond the horizon. Like our capacity predictions, we've used Newark (EWR) to prototype when modeling delay—though our infrastructure and modeling readily scales with customers. And we’ll initially re-forecast delay hourly—around the 6th minute of the hour after the capacity model runs—though could refresh more frequently with the latest demand information.

We’re ultimately trying to identify the still-lurking downside. To that end, we encourage you to focus on the ‘Predicted Unpublished Delay’ series; for flights scheduled to land in a given hour, this answers how many minutes of delay, on average, arrivals can still expect to absorb. We’ve also included average published delays to contextualize the situation—are we predicting 15 additional minutes of delay on top of 44 or 4 minutes of already-posted delay?

Delay, disruption and denominators

If you're comparing our delay predictions to the averages provided by the FAA—whether directly via their dashboard or piped to places like FlightAware—you’ll find they diverge in cases where the FAA geographically partitions flights or airlines implement cancellations. In the case of the former, the Command Center may exclude trans- or mid-continental flights from delay assignment; because we spread predicted delay across all arrivals scheduled to land in an hour, our per flight amount could be lower.

In the case of the latter, that slinking downside is somewhat amorphous. In response to FAA-assigned slots, airlines will occasionally cancel flights to mitigate the ensuing delays6. This, too, is on our data science roadmap; however, until we’re reproducing this behavior, we’re liable to over-predict unpublished delay at longer lead hours. In the interim, as airlines work through their schedule reductions, we’ll re-forecast delays: Absent the cancelled demand, our unpublished delay predictions should drift down to reflect the amount of delay allocable to still-operating flights. While we re-forecast with the latest demand, the FAA continues to broadcast the delay associated with their original advisory.

And when the Command Center originally runs a ground delay program, average delays can be eye-watering. But after the fact—with the cancellation dust having settled—average hourly delays exceeded 60 minutes just 2% of the time in EWR7. So, until we're predicting cancellations, we'd bet on a schedule reduction when unpublished delay approaches 60 (or even 40) minutes.

In this way, you can think of our predictions as unpublished disruption—cancellations might reduce average delays, but they still leave planes, crews and passengers out of place.

Like our capacity forecasts, we’re launching a decidedly beta version of delay predictions. If you’re curious about what you’ve read and can put up with some bugginess, reach out to tim@aerology.ai: We’ll get you set up beta access!

So as Tim wrote, he dropped hints that his co-founder, Yamaç, was working on a proper ML product. And today we’re really excited to launch a public beta for our first model.

What is it? And what is it not (yet)?

We trained a deep learning model to predict airport arrival capacity, deployed it to the cloud (so that it can infer in real-time) and built a simple frontend that visualizes the results. If you’ve been reading our Substack for a time, you know that we have a complicated relationship with Newark Airport (EWR)—so naturally we chose to start there.

Aerology

The one about EWR

Disruption at Newark Airport (EWR), oft-featured in our air travel outlooks, has been spotlighted after comments from United CEO Scott Kirby during the company’s first quarter earnings release. Kirby (straining to remain calm by his own account) responded to a question about capacity and demand at the airport by saying…

Read more

4 years ago · 4 likes · 5 comments · Tim Donohue

While we’re curious if airports can be featurized—such that the same algorithm outputs predictions for multiple airports—even by itself, our EWR model is trained on a billion data points.

Given how frequently we reference weather and its various models, you’ll likely be unsurprised to learn that ingesting NOAA’s high-resolution rapid refresh (HRRR) is a critical pipeline. There’s tradeoffs (refresh rate, time steps, subscription cost, ensembling), but we think it’s an appropriate solution for an MVP: it allows us to re-forecast capacity once per hour (around the 12th minute of the hour) and provide predictions in hourly time steps out to 15 hours in the future.

For the moment, the model assumes all runways are open, though we’re a couple days away from switching on the pipeline that will read runway status from NOTAMs. We’re also working on the pipeline that ingests actual arrival rates for a window leading up to our prediction. We’ll share on Twitter (provided it’s still around) when these pipelines are up and running.

Follow us on Twitter

As for the model itself? Well that’s sorta the secret sauce, but we will share that it’s based on the same transformer architecture that’s made headlines recently as it relates to generative AI.

If readers aren’t surprised by the initial focus on EWR or the HRRR’s prominent role, they might be surprised to see point estimates of arrival rates. After all, we’ve spilled a fair bit of virtual ink to convey uncertainty… bets, odds, chances, probabilities are oft-used words. So why the single, best estimate of capacity and not a more probabilistic product (e.g. communicating low- and high-end rates)? We’re evolving our model architecture to better quantify the uncertainty around predictions, but Yamaç only has so many Jupyter notebooks. We’re just as excited to iterate as we are to launch and to do the former—with the benefit of feedback—first requires the latter. To that end, we wanted to launch as soon as it contained some value that otherwise doesn’t exist; we think the point estimates satisfy that criteria.

In the meantime, we’ve charted the three most recent initializations to convey some sense of uncertainty. A relatively wider spread in predicted values for the same valid time (e.g. the 22:00 hour above—it’s in UTC) should be interpreted to mean there’s greater uncertainty. Conversely, more tightly grouped initializations (e.g. 17:00 hour) suggest higher confidence on our part.

Cool. What can I do with this?

Admittedly there’s an interpretability hurdle for travelers, especially. For both operators and travelers, we think probabilistic predictions will significantly increase utility. For now, we’d recommend travelers pair our predictions with the FAA’s airport arrival demand chart (AADC), which helpfully encodes hourly arrival demand by way of the stacked columns. It’s an important piece of information—and not yet piped into Aerology—to triangulate capacity, demand and [more-interpretable] delay. Low capacity by itself isn’t necessarily problematic; it’s only when capacity falls below demand that queueing (read: delays) results.

The black horizontal line forecasts the same arrival rate as our dashboard—but reflects the FAA’s outlook. Essentially, we’ve challenged ourselves to forecast rates set by the FAA more accurately than the FAA themselves. Fortunately for the prospects of our burgeoning company, indications are we can do so with a good degree of success. We ultimately want to benchmark using a deployed model, though need to finish the arrival rate pipeline (and collect a sufficiently large sample); in the interim, a trained-but-not-yet-deployed model looks to reduce forecast error by as much as 44%1.

Much of this outperformance likely owes to the FAA's wait-and-see approach to ground delay programs, or GDPs. From where the FAA is sitting, this optimism is largely defensible—it minimizes the chances that they’ll introduce unnecessary delay to the national airspace system. But shifting that decision right—nearer the potential capacity/demand imbalance—costs operators optionality in how they distribute delay (if metering traffic does prove necessary). And loss of operator optionality also flows through to travelers, whose best rebooking alternative might depart before the delay is published.

After sending two or three outlooks per week since August, we think this beta launch is a good opportunity to re-evaluate Substack cadence and content. We want to be metrics-driven and the shorter, more frequent outlooks didn’t really grow subscriber numbers. Now that we have a product we’re iterating on, that figures to provide some previously-inaccessible content. And we might return to the in-depth outlooks for peak travel dates (or author a post on macro trends). So we’re not entirely sure what Substack looks like for us going forward, but we’ll still be writing.

Aerology is, for the moment, unconstrained by this wait-and-see gamble; we’re just making our best estimate of capacity, unbiased by optimism. (And our probabilistic predictions will enable a more scientific, tactical wait-and-see approach… call it hedge-and-see.) So, if the AADC denotes “No GDP”—like the screenshot above—and Aerology’s forecasted rates differ substantially from the FAA’s outlook, we’d bet they’re waiting for some trigger (perhaps demand to exceed some threshold or an updated weather forecast) to publish reduced rates.

Take, for example, the 19:00 GMT hour in the two charts above. Aerology had most recently predicted a rate of 38.8 at 13:00 GMT (which would have been visualized at 13:12); forecasted capacity for the 13Z hour trended generally downward from the previous two initializations (39.2 to 39.6), though not so erratically as to convey high uncertainty. The FAA, for their part, was publishing a 50 arrival rate at the time. Arrival demand was estimated at 40 (less a forecast and more an accounting). If predicted capacity is below both the FAA’s forecasted rate and estimated demand, it’s an indicator that unpublished delay exists.

This can also be the case if a GDP is active and suggests a downward revision to the program may be forthcoming—which would increase delays. If, on the other hand, Aerology’s predicted rates are higher than the FAA’s outlook, we might see an upward revision or cancellation of the program. But delays are sticky. Passengers scatter, agents are reassigned, gate changes are made: It’s the reason the FAA and airlines are inclined to publish a delay only when they’re nearly certain it will occur. Expect the FAA to be quicker with downward revisions than rate increases (or cancellations).

Now the exciting part

We think there will be a step change in traveler interpretability—and therefore utility—when we’re providing probabilities that capacity will be lower than currently-published rates. And another step change when our output is not just capacity, but also delay. However, iterating takes weeks (in the case of probabilities) or months (to reach delay predictions) and we have a product to share today! So comment below or email Tim (tim@aerology.ai) and we’ll get you set up with a username and password; the dashboard is an otherwise publicly accessible website (nothing to download, no VPN required). We intend to leave the beta open for a few weeks, after which point it will be, at least partially, moved behind a paywall.

And it’s just that: A beta. So please expect (and report!) any bugginess. To that end, don’t limit feedback to bug fixes—what would improve the usefulness of the product? As we referenced above, feedback from users is critical to successful iteration. (Perhaps particularly helpful beta users get an extra week of beta access.)

🚀,

Yamaç & Tim