RSRudraksh Syal

01 · Dynamic Pricing Engine

When capacity changes daily, price should too.

A fleet-wide pricing system that estimates sellable capacity, models price-sensitive booking behavior, and solves for a yield on every departure date—including when the right answer is not to quote.

Explore the system ↓View public reconstruction ↗
ContextVista · Private aviation
PilotOne 43-jet fleet
Outcome−28% off-fleeting · month one
My roleHands-on data science lead

The problem

Static pricing sees a product. Dynamic pricing sees a system.

Private-aviation capacity is perishable and constrained. A tail can be unavailable, committed to a program member, consumed by another trip, or likely to cancel. At the same time, higher yield changes the probability that a quote becomes a booking.

The task was not simply to predict a price. It was to make supply and demand comparable enough to support an operational decision.

Model lineage

The third generation changed the question—not just the algorithm.

  1. 01EnsembleUnderperforming model

    A first-generation pricing model that did not produce dependable operational decisions.

  2. 02AutoMLBetter accuracy, incomplete decision

    Accuracy improved 71% → 78% and RMSE 1.9 → 1.4, but the black box still lacked a supply–demand clearing mechanism.

  3. 03Dynamic Pricing EngineA different architecture

    Forecast supply, model price response, then solve the operating decision with visible guardrails and human override.

Generation two was a more accurate answer to the wrong question.

The system

Three models become one decision.

  1. 01

    Estimate supply

    Six component forecasts at region × fleet × 7/14/21-day windows, then subtract operational and contractual commitments.

  2. 02

    Model demand

    Use LOWESS to discover the shape, then fit exponential conversion decay after quote volume proves comparatively flat.

  3. 03

    Solve the decision

    Use bounded Brent root-finding to clear demand against supply across a 7 × 7 route grid, with floor, ceiling, and no-quote states.

Applied case · EU Light Jet

The pricing fix that made instant booking viable again.

A cost-to-serve model for Vista’s entry-level EU product line, where every booking depended on a third-party operator and the guaranteed quote had to absorb fulfillment risk before the customer ever saw a price.

Margin−8% → +17%25-point swing
Loss-making bookings55% → 20%full-quarter outcome
Fulfillment model100% off-fleetthird-party operators
Incremental margin~$7M / quarterdirectional estimate
Why the product broke

The customer promise was instant. The cost truth arrived months later.

The issue surfaced reactively in a quarterly business review. Vista owned no Light Jet tails in the EU, so every guaranteed booking was fulfilled through a volatile external operator network. Pricing bands inherited some US logic and had not kept pace with EU costs—especially positioning and ferry expense in a thinner operator network.

Because true fulfillment cost appeared only after operator invoices arrived, the drift was invisible in day-to-day quoting. A quarter of invoices made the pattern undeniable: more than half of bookings were losing money.

How the decision changed

Pause the exposure, then price the uncertainty at quote time.

Engineering temporarily replaced guaranteed instant booking with request-based booking so losses would not keep compounding. Over roughly six weeks in Q3, I built a GBM to predict expected fulfillment cost using only information known when the quote was requested.

The prediction grain mattered: expected cost across the likely operator pool, not a specific operator’s price, because operator assignment happens after booking. The model scored synchronously inside the pricing engine, so it stayed deliberately lean.

How we earned the relaunch

Validate against invoices—and against the demand that would return.

During the request-based window, shadow predictions were compared with real incoming invoices. I also backtested against invoices from the earlier instant-booking period: request-based customers skew toward more plannable trips, so shadow validation alone would not represent the spontaneous demand expected after relaunch.

Once both views held, engineering restored instant booking in Q4 with the GBM embedded in the pricing engine. Every guaranteed quote now accounted for expected fulfillment and positioning cost before it reached the customer.

What changed

A model with a direct, auditable P&L.

Over the first full quarter after relaunch, margin moved from −8% to +17% and loss-making bookings fell from 55% to 20%. On the fleet’s revenue base, the 25-point swing translates directionally to roughly $7M per quarter in incremental margin.

The outcome was not a proxy metric: predicted cost could be reconciled with real operator invoices. The model did more than improve pricing—it created the evidence needed for the product to operate safely.

Interactive evidence

Choose your level of depth.

Each view reconstructs a key idea from the project’s public HTML dashboards.

Supply signal

Start with what can actually be sold.

Gross fleet capacity is not open-demand capacity. Maintenance, program commitments, existing legs, and expected cancellations all change the usable supply for each departure date.

16do-not-quote days
10equilibrium days
5floor days
Raw capacity12.7
Scheduled maintenance−2.4
AOG−0.5
Unscheduled maintenance−0.8
Crew unavailable−0.2
Program commitment−5.8
Non-program legs−0.7
Cancellation adjustment−0.4
Open-demand supply1.9

Representative solved day · legs

The core insight

Inquiry was comparatively stable. Conversion was the real pricing lever.

Travelers still inquire when they need to travel. Price primarily changes whether that inquiry converts—so the solver focuses on the booking decision, not a simplistic assumption that demand disappears. LOWESS exposed the shape before an exponential curve was fitted (R² 0.973).

Modeling judgment

Use complexity only where it earns its place.

The architecture remains composable: each operational signal can use the simplest approach its data supports.

Every supply seriesACF / PACF first

Diagnose trend, lag structure, and seasonality before selecting a forecasting method.

Diagnosis before tooling
Stable weekly seasonalityProphet

The workhorse where diagnostics showed a genuine, repeatable weekly pattern.

Complexity earned
Simple lag-1 seriesBaseline over SARIMA

SARIMA barely improved the forecast and did not justify added operating complexity.

Baseline retained
Weekly + annual candidateBaseline over TBATS

One year of history could not support a dependable annual pattern; the constraint was data, not tooling.

Data limit made visible

My contribution

Hands-on modeling with operational ownership.

My work connected supply forecasting, demand elasticity, model selection, and solver behavior into a decision product that could be explained to product, engineering, and operational partners.

  • Rejected an end-to-end price model that would learn legacy MSRP rules and human overrides instead of true elasticity.
  • Framed the pricing decision around usable capacity, not gross fleet size.
  • Selected models component by component against transparent baselines.
  • Made guardrails—including floor, ceiling, and do-not-quote states—visible.
  • Kept every route-grid cell overridable by revenue managers and monitored the override gap as a trust signal.

Validation

Three levels of evidence, one operating outcome.

01

Components

MAE, median absolute percentage error, and forecast bias—reviewed by fleet, region, and time window.

02

Full pipeline

End-to-end historical backtests compared the complete pricing decision with realized capacity.

03

Human alignment

The override gap between engine recommendation and revenue manager choice surfaced trust, missing signals, and model weakness.

First month · one 43-jet fleet−28%off-fleeting

The north-star metric tracked accepted bookings that ultimately had to be fulfilled externally at a loss. Override gap remained the secondary operating signal, monitored by region.

2026 research extension · Public reconstruction

We tested whether an LLM should replace the forecasting engine. It shouldn’t.

The rebuilt project became a controlled research environment for comparing the existing forecasting recipes with direct GPT-5.5 forecasts and an agent that could plan, run, and evaluate bounded model experiments.

Synthetic three-way comparisonSupply RMSE · lower is better
270 simulated final-test days · 14 / 28 / 90-day horizons
Current ML3.594Lowest supply RMSE
Agent-directed ML3.634+1.1% vs current
Direct GPT-5.54.696+30.7% vs current

The current ML system also produced the lowest diagnostic price error across all three horizons. These simulator results test forecasting behavior—not real-world revenue impact.

01 · Hypothesis

Could an agent discover a better forecasting recipe?

GPT-5.5 could inspect training summaries, choose models, tune parameters, test ensembles, and record a reason for each final selection.

02 · Guardrails

Let the agent experiment—without letting it move the goalposts.

Local tools enforced trial bounds, kept final-test observations outside the workbench, recorded every action, and reserved spend before each model request.

Trials
24
Model requests
47
Cost
$2.86 / $4 cap
03 · Decision

Keep production unchanged.

Some component forecasts improved, but remaining-supply error and do-not-quote disagreement worsened. The evidence supported the existing forecasting engine, with LLMs retained for explanation and carefully bounded research—not as an automatic replacement.

Better evidence, not a forced AI win.

This extension is a portfolio experiment using retrospective and synthetic evaluation. It does not claim production deployment, untouched holdout performance, or measured revenue uplift.

Public artifacts

Inspect the reconstruction.

This public reconstruction uses aggregated, representative operational data from one fleet. It communicates the system’s modeling logic and decision behavior without reproducing every production detail.