The LCO Hotel Optimizer is a research-grade platform implementing Lexicographic Constraint Optimization (LCO) for hotel revenue management. Rather than collapsing revenue, risk, operations, fairness, and sustainability into a single weighted sum, LCO solves six competing objectives in strict priority order — freezing each tier's optimal value as a hard floor that every subsequent tier must respect.

This guide is written for university faculty and research students who need to prepare datasets, run controlled optimization experiments, train the LCPG reinforcement-learning policy, and export results suitable for classroom use, theses, and peer-reviewed publication.

The six-tier lexicographic hierarchy, solved in priority order:

Why lexicographic, not weighted-sum?

A weighted sum forces the researcher to price ethics, risk, and energy on a common scale — a scientifically and ethically fraught exercise. LCO declares an explicit priority order (guests' rights before revenue, revenue before operations) and lets each objective reach its own optimum, producing a Pareto-efficient, ethically defensible policy.

The platform uses the notation from the paper's Tables 3–7. Key symbols:

Three tiers gate solver access. The right tier depends on the experiment scale.

For classroom and multi-student research, Pro is the recommended minimum — it unlocks the verified L3 floor-locking solver and LCPG training. The exact-MILP solver (NEOS/CBC) is the gold standard for reproducible benchmarks and requires Enterprise.

The core input is a booking dataset: one row per booking request, with stay and guest attributes. The platform accepts CSV uploaded through the LCPG Data Loader (Analytics & Data → LCPG Data Loader; Pro+ required). A downloadable Mykonos sample dataset (500 bookings, 180 days, 8 floors, 100 rooms)is available on the loader page to use as a template.

5.1 CSV Field Reference

5.2 Sample CSV Rows (Mykonos template)

start_day,length,price,show_prob,booking_channel,lead_time,day_of_week,customer_segment,is_vip,is_ada,event_indicator,rate_code,room_type,floor_number
1,3,360,0.92,Direct,21,Monday,Business,false,false,,BAR,Standard,4
2,2,300,0.85,OTA,8,Tuesday,Leisure,false,false,Athens Tech Conf,CORP,Deluxe,7
3,1,540,0.95,Corporate,2,Wednesday,Business,true,false,,BAR,Suite,8
4,5,190,0.88,OTA,45,Saturday,Leisure,false,true,Summer Peak,PACKAGE,Standard,1

5.3 Field Semantics That Affect the Math

• is_vip and is_ada are L1 hard constraints. VIP bookings are always accepted and assigned to a top-floor Suite; ADA bookings are pinned to floors 1–2. Mislabeling them defeats the ethical tier — label them accurately from your source data.
• show_prob drives the L3 overbooking model: expected shows = sum of (accepted × show_prob). Typical real-world no-show rates give 0.78–0.95; the platform default is 0.85.
• room_type applies revenue premiums: Standard 1.0×, Deluxe 1.35×, Suite 1.85×. floor_number adds a view premium up to +18% on the top floor.
• event_indicator tags demand-driving days; it feeds the Rate Pricing Report and Demand Forecast multipliers downstream.
• price is summed over accepted bookings to form the L2 objective. Keep it as total-stay price (or document your per-night convention consistently).

5.4 Best Practices for Reproducible Research

• One row per booking. Do not split a multi-night stay into daily rows — length captures the duration.
• Scale to your instance. The paper's Appendix A instance is 10 rooms × 5 days with 12 bookings. The Mykonos sample is 100 rooms × 180 days with 500 bookings. Match rooms/days to your research question.
• Start from the sample, then perturb. Download the Mykonos CSV, vary one column at a time (show_prob, price, event_indicator) to isolate effects.
• Record dataset metadata. When configuring, name the dataset and set room_count and analysis_period_days to match your CSV exactly.
• Keep booleans clean. Use true/false or 1/0 — mixed casing can cause parse errors.

1. Navigate to Analytics & Data → LCPG Data Loader (Pro+ required; Free users see an upgrade prompt).
2. Step 1 — Upload CSV: drag your CSV into the uploader. It parses, validates columns, and previews the bookings.
3. Step 2 — Configure Dataset: name the dataset, add a description, confirm room_count and analysis_period_days, then save. It is stored as an LCPGDataset record (one row, with the bookings array embedded).
4. The saved dataset appears in LCPG Analytics and can feed the Simulator and all solvers.

LCPG Analytics (Analytics & Data → LCPG Analytics) renders every saved dataset through a sequence of analytical modules. Each module is a publication-ready chart you can screenshot or feed into your results notebook:

The charts in LCPG Analytics are not just descriptive dashboards — each one maps directly to an input, constraint, or output of the LCO model. This section explains what the numbers actually mean for a revenue manager, using the bundled Mykonos sample (500 bookings, 180 days, 100 rooms, 8 floors) as a worked example. Load it via Sample Data Download on the LCPG Data Loader to follow along.

Summary Stats — the sanity check

• Total bookings (500): the demand pool the solver selects from. With 100 rooms over 180 days the theoretical capacity is 18,000 room-nights — 500 bookings averaging ~3 nights ≈ 1,500 room-nights sold, so the hotel runs ~8% occupied on average. That low base occupancy is the real Mykonos problem: the challenge is not capacity, it is selecting the right 500 from a much larger request stream.
• Total & average booking value: the sum of accepted price is exactly what L2 maximizes. A high average (~€420) skewed by a few Suite bookings tells you a handful of VIPs drive margin — protect them at L1.

Calendar Heatmap — where the money is made

The day × room occupancy grid makes the season legible. On Mykonos you will see a thin band of occupancy through spring, a dense red cluster in July–August, and a sharp cliff in late September. That cliff is the single most actionable insight in the dataset: demand collapses almost overnight, so any L3 overbooking you tolerate in August must be unwound by week 38. Read the heatmap left-to-right as the shape of the revenue function the L2 solver is maximising.

Channel Trends — margin, not just volume

A typical Mykonos split is OTA ≈ 55%, Direct ≈ 20%, Corporate ≈ 20%, Other ≈ 5%. Volume here is deceptive: OTA revenue carries 15–22% commission, so a booking booked through OTA is worth ~18% less to the hotel than the same price booked Direct. For the revenue manager this means the L2 objective (which uses gross price) overstates OTA contribution; when you compare scenarios, weight Direct/Corporate more heavily, or upload net price instead. The chart is the diagnostic — the solver is blind to commission unless you encode it in price.

Lead-Time Distribution — the overbooking signal

Mykonos shows a bimodal lead time: leisure guests book 30–60 days out, corporate guests book 1–7 days out. Long-lead leisure bookings have lower show_prob(plans change); short-lead corporate have higher certainty. This is precisely the information L3 exploits: overbooking slack is only worth accepting on days where lead-time is long and show probability is low. If your lead-time distribution is single-mode and short, L3 has little to gain — expect a flat revenue/risk frontier in the sensitivity sweep.

Segment Profitability — who to protect

Group and Business segments often show lower per-booking price but high repeat value; Leisure shows high price but high no-show risk. On Mykonos, Group drives the August peak (weddings, events) and Business the shoulder months. Use this to justify L1 VIP protection: theis_vip flag should capture the high-repeat Business segment, not just arbitrary high payers.

Rate Pricing Report — ADR, RevPAR and event multipliers

• ADR (Average Daily Rate): room revenue ÷ occupied room-nights. Mykonos ADR climbs from ~€180 in May to ~€640 in early August — a 3.5× swing that the Rate Recommendations engine amplifies with event multipliers.
• RevPAR (Revenue Per Available Room): ADR × occupancy. Because base occupancy is low, RevPAR (≈ €30–€55) looks weak even when ADR is strong — the lever is filling rooms, not raising price further. This reframes the L2 objective for off-peak days.
• Event multipliers: the event_indicator column (e.g. Athens Tech Conf, Summer Peak) marks days where the Demand Forecast raises projected occupancy. These multipliers feed Rate Recommendations — a 1.3× multiplier on a Conference day typically lifts the recommended rate 18–25%.

Demand Forecast & Industry Benchmark — context, not ground truth

The forecast projects the seasonal curve forward; the benchmark overlays an STR-style competitive set (e.g. Aegean luxury 5★ properties). If your ADR sits above the benchmark during peak but below it in shoulder months, the implicit recommendation is to raise shoulder rates and hold peak rates — exactly the move the Rate Recommendations page will suggest once you run it. Treat both as priors; the solver's L2 output is the decision.

The optimizers in this guide are not used in a vacuum — they are calibrated by previous-season (historical) data, which acts as the empirical prior that makes every decision defensible. Last season's records feed five distinct places in the platform:

1. The seasonality shape — Demand Forecast & Calendar Heatmap

The seasonal curve (the "thin spring band → dense July–August red cluster → late-September cliff" of §7A) is the shape of the L2 revenue function the solver maximises. A past season's bookings reveal where demand actually concentrates, so the Demand Forecast can project that curve forward and pre-position overbooking and price moves instead of estimating them in the abstract.

2. The ADR / RevPAR baseline — Rate Pricing Report

Historical ADR and RevPAR define the baseline the rate engine lifts from. The Mykonos swing of ~€180 (May) to ~€640 (Aug) is only visible with last season's daily ADR; the event_indicatormultipliers then layer on top of that baseline. Without the baseline, recommended rates have no anchor.

3. Lead-time & show probabilities — L3 overbooking

Past bookings reveal the bimodal lead-time pattern (leisure 30–60 days out, corporate 1–7 days out) and real no-show rates. These calibrate show_prob, which drives the L3 overbooking model. Overbooking only pays off on low-show-probability, long-lead nights — and you only know which nights those are from history.

4. The competitive reference — Industry Benchmark

The STR-style competitive set is overlaid on your ADR. If your peak ADR sits above the benchmark but shoulder-month ADR sits below it, the actionable read is "raise shoulder, hold peak" — a read that is impossible without last season's benchmark numbers.

5. Ground truth — Backtesting

The most direct use: any pricing or acceptance strategy is validated against historical PMS data before it is trusted live (§13). Previous seasons are the ground truth the strategy is scored against, closing the loop between the model and observed outcomes.

Where to source the data

• Internal — your own PMS (primary source). Oracle Opera, Mews, Cloudbeds, Apaleo, Hotelogix and similar property systems. The platform's PMS Sync page and the syncPMSData backend pull reservations, ADR and occupancy directly from your property system — the cleanest previous-season data because it is your hotel. Your channel manager / direct-booking engine supplies the Direct / Corporate vs OTA split the Channel Trends chart relies on.
• External benchmarks — rates & ADR/RevPAR. STR (CoStar Group) is the de-facto standard for hotel ADR, RevPAR and occupancy benchmarks — the same "STR-style competitive set" referenced in §7A. For competitor daily rates (consumed by fetchCompetitorRates and the Competitor Analysis module), use licensed rate-shopping tools (RateGain, OTA Insight, Snapshot/TravelClick) or the OTAs' partner APIs (Booking.com, Expedia, Agoda, Hotels.com). Note: scraping OTA pages directly usually violates their Terms of Service — use a licensed rate-shopper rather than DIY scraping.
• Open / research datasets (classroom & thesis work). Kaggle's "Hotel booking demand" (Antonio, de Almeida & Nunes — the H1 resort + H2 city-hotel dataset) contains real booking records with lead time, cancellations and segment that map cleanly onto the CSV schema in §5.1. The Expedia Hotel Recommendations dataset offers search and booking-intent logs. Inside Airbnb listings/calendar data can serve as a short-term-rental demand signal (not a direct hotel equivalent) for markets where STR rentals compete with hotels.

The Solver Panel (inside LCPG Analytics and the Simulator) exposes four backends. Pick the one that matches your tier and research question:

8.1 The Revenue-Floor Tolerance ε

ε controls how strictly the L2 floor is enforced when optimizing L3 and below. The platform default locks L3 to retain ≥ 95% of L2 revenue (ε = 0.05 of the floor). A larger ε trades revenue for more overbooking reduction; ε → 0 enforces the floor exactly. Sweep ε in the Simulator's sensitivity analysis to plot the revenue/risk frontier.

8.2 Reading Solver Results

• l2_heuristic / milp: returns accepted_revenue, accepted_count, occupancy_rate, revenue_floor, and (MILP) per-booking room assignments.
• l3_lock: returns a tier cascade object (l1…l4) with each tier's name, status, floor value, plus metrics: accepted/rejected bookings, overbooking slack, housekeeping turns, occupancy, avg price.
• lcpg_training: returns trained policy parameters and per-tier value estimates for application to future windows.

Research → Simulator is the hands-on experiment surface. Configure rooms, days, the revenue-floor tolerance ε, and a booking table, then run any solver. Notable capabilities:

• Toolbar actions: Save / Load scenario, Export CSV, Export PDF report, Reset to the 10×5 paper instance, Share scenario.
• Room Assignment Grid: color-coded booking-to-room calendar with VIP/ADA legends.
• Crisis Mode: evaluates ethical/revenue risk and activates an L1-prioritized re-optimization under disruption.
• Batch Sensitivity Analysis: vary show probability or price across a range and observe revenue, occupancy, acceptance.
• Market Pricing Overlay & Demand Forecast: overlay live competitor rates and seasonal demand onto your scenario.
• Version History & Collaboration: save labeled versions of a scenario and chat with co-researchers on a shared scenario.

Reproducing the paper (Appendix A): open the Simulator and click Reset to load the 10-room × 5-day, 12-booking instance, then run Optimize L₂ → Lock Floor → L₃. Expected: L2 revenue Z₂* around $1,847; L3 reduces overbooking slack ~55% while retaining ~98% of L2 revenue; measurable reductions in housekeeping turns and energy use at L4/L6.

Lexicographic Constrained Policy Gradient (LCPG) trains an RL policy that respects all six tier floors simultaneously. Run it via Train LCPG (Paper §4). Pseudocode:

Require: tiers {L1..L6}, simulator S, initial theta, lr eta,
         batch B, horizon H, floors {Z*_k}
1:  Enforce L1 hard feasibility (ADA, safety, VIP) in S
2:  for k from 2 to 6 do
7:      repeat
8:          generate B rollouts of length H with policy pi_theta
9:          estimate E[r_k] and E[c_j] for j <= k
10:         project infeasible actions to satisfy L1 and floors
11:         compute constrained gradient g
12:         theta <- theta + eta * g
13:         update duals lambda_j <- max(0, lambda_j + eta_lambda * [Z_j - E[r_j]])
14:     until convergence
15: freeze floor Z_k and inject into the nightly MILP

The constrained gradient (Eq. 28) is g = ∇_θ ( E[r_k] − Σ_{j<k} λ_j [Z_j − E[r_j]]⁺ ), where the dual variables λ_j penalize floor violations. The discount factor γ in (0,1) weights future rewards. Full derivation and correctness proofs are on the Advanced Methods → Certifications tab (Appendices B–D).

Componentwise Approximated Gradient (CAG) provides stable descent directions when the true gradient is noisy or undefined — common on non-convex hotel revenue surfaces with discrete inventory thresholds. It is documented on the Advanced Methods → CAG Method tab:

CAG is used inside LCPG training and the multi-property orchestration to guarantee floors are never violated during a gradient step.

For off-platform replication, the paper's Appendix A provides a Pyomo MILP you can run locally:

pip install pyomo highspy

# Mini LCO demo: 10 rooms x 5 days
# Tier L2: maximize revenue -> record Z2*
# Tier L3: minimize expected overbooking slack with a revenue floor
from pyomo.environ import (ConcreteModel, Set, Var, Binary,
    Constraint, Objective, maximize, minimize, SolverFactory)

DAYS, ROOMS = 5, 10
bookings = { 1:(1,2,120,0.92), 2:(1,3,110,0.85), ... }  # 12 bookings
# Build model, solve L2, lock floor, solve L3
# (full code on Advanced Methods -> Pyomo Code tab)

The platform's milp_neos solver runs an equivalent formulation on the NEOS CBC server — compare your local Pyomo results against it for cross-validation.

• Occupancy Calendar: daily occupancy/ADR/RevPAR projections with event overlays; click a day to model it in the Pricing Sandbox.
• Competitor Analysis: rate benchmarking, price-parity monitoring, and rate-change alerts.
• Rate Recommendations: AI-generated per-room-type rate suggestions with confidence and revenue-impact estimates.
• Multi-Property: Benders / ADMM decomposition across properties (Pro+).
• Dynamic & RL: live stochastic-arrival re-optimization demo with rolling horizon H.
• Advanced Methods: CAG, LCPG pseudocode, Pyomo code, notation tables, and correctness certifications (Appendices B–D).
• Backtesting: validate pricing strategies against historical PMS data; upload your own backtest dataset.
• Custom Reports: assemble reusable report widgets (KPIs, trends, calendar, distribution).
• Event Management: maintain the events that drive demand multipliers in forecasts.

• CSV export (Simulator toolbar & LCPG Report Exporter) — booking-level results for R / Python / Stata.
• PDF report (Simulator toolbar & MILP Results Report) — formatted summary with KPIs, accepted-booking tables, room assignments.
• LCPG Reports Hub — comprehensive analytical reports from trained datasets.
• API access (Pro+) — programmatic retrieval of solver results via base44.functions.invoke(...) for automated pipelines.
• This guide as PDF — the Download PDF button above captures the entire document to A4.

1. Record the dataset name, room_count, analysis_period_days, and booking count.
2. Record the solver ID (l2_heuristic / l3_lock / lcpg_training / milp_neos) and the ε tolerance used.
3. Save the scenario (Simulator → Save) and note its ID for later recall.
4. Export the CSV of accepted bookings and the PDF report; store both with the run.
5. For MILP runs, record the NEOS job number shown in the results panel.
6. For LCPG training, record the trained policy identifier and the horizon H.
7. Pin the platform build (v1.7.0) in your methods section so future readers can match behavior.

1. State the research question (e.g. "How does ε affect L3 overbooking slack at fixed L2 revenue?").
2. Prepare a booking CSV per Section 5, or start from the Mykonos sample and perturb one column.
3. Load it via the LCPG Data Loader; verify in LCPG Analytics summary stats.
4. Open the Simulator, set rooms/days/ε, run a solver; record the tier cascade.
5. Vary one parameter in Batch Sensitivity Analysis to build a frontier plot.
6. For exact benchmarks, run Solve MILP via NEOS (Enterprise) and compare against the heuristic.
7. For adaptive-policy research, run Train LCPG and apply the policy to a future window.
8. Save the scenario, export CSV + PDF, and attach them to your analysis notebook.
9. Cite the methodology (Section 18) and the platform build version.

• "Upgrade required" on LCPG Data Loader / Analytics: these are Pro+ features. Free users can still use the interactive Simulator with the l2_heuristic solver.
• "Save scenario first": the LCPG trainer requires a saved scenario to persist the trained policy — save before clicking Train.
• CSV parse errors: check boolean formatting (true/false or 1/0), quote text fields, ensure the header row matches Section 5.1 exactly.
• NEOS unavailable: the milp_neos solver falls back to a greedy solve if the NEOS server is unreachable; results will be heuristic, not exact — note this in your methods.
• L3 not reducing slack: ε may be too tight; increase the revenue-floor tolerance to allow L3 more freedom.
• Daily run limit (Free): 5 solver runs/day across all solvers; runs reset at midnight Athens time.

When publishing results produced with this platform, cite the underlying work and the platform build:

© 2026 Kapodistrian Academy of Science & Antonios Valamontes. All Rights Reserved.