Forecasting

Overview

Forecasting brings registration, cash-flow, and production outlooks into one planning workspace. It is for deciding what to watch and when to follow up; it does not change capacity, prices, inventory, or money records.

Use it alongside Rego Analytics, Finance Analytics, and Inventory Analytics. Those pages report current operational facts. Forecasting estimates what may happen next and always keeps its ranges, evidence level, and as-of time visible.

Dashboard route

• /ems/manage/forecasting?id=:eventId

Horizon and period controls

Use the horizon rail to switch between the next 4 weeks, next 30 days, next quarter, and event day. The period control switches the outlooks between weekly and monthly presentation where that view is available.

Changing a control changes the planning view only. It does not recalculate past transactions or update event configuration.

Registration outlook

The registration outlook estimates cumulative attendance and shows 80% and 95% ranges. Tier detail helps teams see where likely demand is concentrated.

Signal	How to use it
Expected final regos	Planning midpoint, not a guarantee.
80% / 95% ranges	Use the wider range for conservative capacity and production decisions.
Still expected	Expected registrations beyond records already observed.
Capacity pressure	A planning warning, not an automatic change to event capacity.
Sell-out timing	A possible timing signal when the model has enough evidence.

Cash-flow outlook

Cash-flow separates expected registration receipts, recorded scheduled inflows and outflows, and the ledger-derived cash position. Scenario views show downside, base, and upside planning cases.

Only recorded ledger entries are treated as actual cash movement. Do not use the forecast as a replacement for Accounting or as approval to spend money that has not been received.

Production outlook

Production outlooks estimate period demand, stock targets, shortfalls, and at-risk item ranges. Use the high end of a range as a review trigger when lead times or replacement cost are high.

Forecasting never creates purchase orders or inventory movements. Confirm stock, reservations, and item availability in Inventory Tracking before committing to production or purchasing.

Forecast methodology

The current engine is a transparent, deterministic forecasting service: fph-forecast-v2. It does not use a generative AI model, a black-box machine-learning service, or attendee personal-profile scoring. Its registration forecast starts with live registration pace, compares it with completed events from the same partner, and uses back-testing to select the more suitable of two booking-curve models.

The model only considers active registrations whose creation time is at or before the forecast’s as-of time. It uses the configured registration opening and closing times where available. If an opening time is missing, it falls back to the first registration, then to an estimated window before the event. Gift reservations are retained as a separate current-capacity signal.

Forecasts are unavailable for the first 24 valid live hours. This prevents a newly opened registration form from displaying a misleading estimate based on a handful of early sign-ups.

How the forecasting service is built

Forecasting is a server-side service in partners-api, not logic that runs in a browser. Its implementation is deliberately split into a data-loading layer and a pure calculation layer so that the model can be tested against a known input snapshot.

Operational records → forecast service → pure model functions → saved forecast vintages → dashboard planning views

The service reads the event definition, active registrations and gifts, tiers, add-ons, inclusions, financial records, approved refunds, accounting entries, inventory on hand, and completed POS/shop sales. In parallel, it loads up to 12 recently completed events from the same partner and their registration observations for comparison.

It then passes normalized records into three pure functions:

Calculation	Output	Dependency
Registration forecast	Attendance point, ranges, tiers, add-ons, capacity signal, and booking outlook	Current registration data plus completed comparable events
Finance forecast	Gross, net, expected cash, payment mix, scenarios, and cash-flow outlook	Registration result plus financial and accounting records
Logistics forecast	Item demand, stock target, shortfall, and production risk	Registration result plus inclusions, sales, and stock records

The finance and logistics outputs are therefore explicitly downstream of the registration model. They reuse its evidence level and uncertainty rather than presenting invented precision from separate, unproven models.

Each domain has a stable input fingerprint containing its relevant source records, the model version, data-contract version, and a five-minute calculation window. When a fingerprint has changed, the service writes a new immutable forecast vintage. If nothing material changed, it returns the latest vintage instead of creating a duplicate. Durable invalidations trigger recalculation after relevant operational records change, with a scheduled backstop for stale work.

The API returns the current result together with its as-of time, source-change time, persistence state, and prior vintage when available. The dashboard only renders that returned forecast; it does not change source records, choose models, or silently modify the result.

Registration models

The service evaluates these model families:

Model	Method	When it is used
collecting	Holds the forecast until 24 valid live hours have passed.	A newly opened event.
front_loaded_pace	Extrapolates current active registrations using a default front-loaded booking curve.	Default fallback, including when there are fewer than three usable comparables.
matched_booking_curve	Uses the median booking progress and final attendance of completed comparable events, blended with live pace.	At least three usable comparables exist and its back-tested mean absolute error is no worse than the baseline.
final_actual	Reconciles the forecast to the observed attendance signal and collapses ranges.	Registration has closed.

For the baseline, registration progress is the elapsed share of the registration window. The expected fraction booked at progress p is:

booking fraction = clamp(p^0.42, 0.02, 1.00)
baseline final attendance = current active registrations / booking fraction

This curve intentionally assumes registrations are front-loaded rather than arriving evenly across the window. It is a fallback assumption, not a claim that every event has the same demand pattern.

For the matched model, each completed comparable event is replayed at the current point in its own registration window. The service calculates how much of that event’s final attendance had already been booked, takes the median comparable progress and final count, and blends that prior with current live pace. The comparable prior carries more weight early in the registration window and less weight as live evidence accumulates.

Comparable events are completed events from the same partner. The service excludes events with no final active registrations or no registrations by the equivalent cutoff. It uses recent completed-event history and reports the usable comparable-event count, training cutoff, and warnings in the result.

Calculation reference

The following is the actual calculation structure in plain notation. Values are rounded to whole registrations at the final attendance step.

p = clamp((asOf - registrationOpen) / (registrationClose - registrationOpen), 0, 1)
f(p) = clamp(p^0.42, 0.02, 1)

p is registration-window progress and f(p) is the default fraction expected to be booked by that point. If there is no accepted comparable model, the live-pace estimate is:

live estimate = active registrations / max(f(p), 0.01)

For each historical comparable event i, the service calculates its equivalent-cutoff ratio:

ratio_i = registrations at comparable cutoff / final active registrations_i

It then calculates the median usable ratio_i and median final count. The matched live estimate divides current registrations by the median ratio. Both the historical back-test and the live forecast blend that live estimate with the median comparable final count:

prior weight = clamp(48 / (live hours + 72), 0.05, 0.60)
forecast point = live estimate × (1 - prior weight) + median comparable final count × prior weight

The service chooses matched_booking_curve only when there are at least three usable comparable events and its leave-one-out back-test mean absolute error is less than or equal to the baseline’s mean absolute error. Otherwise it chooses front_loaded_pace. Finally:

point = max(active registrations + reserved gifts, round(forecast point))
point = min(point, configured event capacity)     // only when capacity exists

This is why the displayed point can never be below confirmed attendance or above configured capacity. It also explains why an early forecast can move materially as new registrations arrive: the comparable prior is deliberately more influential before live evidence has accumulated.

How ranges are calculated

The forecast range is proportional to the selected point. The service computes a default relative width that decreases as registration progress increases:

default 80% width = clamp(0.72 × (1 - p) + 0.10, 0.14, 0.90)
default 95% width = clamp(1.25 × (1 - p) + 0.20, 0.28, 1.55)

For each comparable back-test, relative error is abs(prediction - actual) / max(1, actual). The range width is the larger of the default width and the historical 80th or 95th percentile error for the selected model. The final range is:

lower = max(current capacity signal, floor(point × (1 - relative width)))
upper = min(configured capacity, ceil(point × (1 + relative width)))  // when capacity exists

The 95% interval always contains the 80% interval. These are empirical planning bands calibrated from the available history; they are not a promise that exactly 80% or 95% of future outcomes will fall inside them.

Capacity, tiers, and add-ons

The final registration point and lower bounds cannot fall below active registrations plus reserved gifts. When an event-wide capacity is configured, the point and upper bounds cannot exceed that capacity. A capacity-capped forecast cannot measure demand that may have existed beyond the cap.

Tier forecasts distribute the total forecast across observed tier choices while respecting configured tier capacity. Add-on forecasts use observed selection share with light smoothing, so a currently unselected add-on does not imply zero eventual demand. These breakdowns inherit the registration forecast’s uncertainty; they are not independently trained demand models.

Cash-flow model

Cash-flow is registration-linked, not an independent revenue model. It begins with active financial records, separates committed from pending records, and preserves recorded discounts, platform fees, processor fees, approved refunds, and accounting entries.

Future registration gross is estimated as projected future registrations multiplied by the observed average registration value. Expected cash applies the current committed share of eligible financial records to pending and future registration gross. Recorded future accounting income and expense entries are then included in the cash-position outlook.

In simplified form:

average registration value = active registration gross / active registration count
future registrations = max(0, registration point - gift reservations - current registration rows)
projected gross = observed gross + average registration value × future registrations
conversion rate = clamp(committed eligible records / active eligible records, 0.25, 0.98)
future gross = max(0, projected gross - observed gross)
expected cash = committed gross + pending gross × conversion rate
                + future gross × conversion rate
cash position = expected cash + recorded/scheduled inflows - refunds - recorded/scheduled deductions

The gross 80% and 95% scenarios substitute the matching registration interval bounds into the future-registration calculation. This shares registration uncertainty with finance instead of presenting a separate confidence claim.

This means the cash-flow view is most useful when registration pricing and payment behaviour remain broadly similar to the event’s current mix. It deliberately does not invent revenue for future POS, Event Shop, or Dealers Den activity, and it does not estimate unrecorded expenses or payment-provider payout timing.

Production and inventory model

Production demand starts with current required quantities from tier inclusions, then adds observed POS and shop sales. Where a tier-level forecast is available, it is used for that item’s registration demand; otherwise current required quantity is scaled by the registration forecast.

For each item, the recommended stock target is the 95% upper demand bound. The item is marked:

Status	Condition
Covered	On-hand quantity covers the 80% upper demand bound.
Watch	On-hand quantity covers the point but not the 80% upper bound.
Production required	On-hand quantity is below the 95% upper demand bound.

Cold-start items with no live selection data are flagged. Their demand is registration-scaled and should be reviewed before purchasing. Supplier lead-time variability and unobserved walk-up demand are not yet modelled.

For an item without a tier-specific demand forecast, registration-linked demand is calculated as:

projected item demand = max(current required quantity,
                            round((current required quantity / current registration count) × forecast registration count))
recommended stock = item 95% upper demand bound
safety shortfall = max(0, recommended stock - on-hand quantity)

Observed POS and shop sales are retained in item demand rather than extrapolated. This avoids assuming that walk-up purchasing will follow the same curve as registration selections.

Ranges, reliability, and evaluation

The 80% and 95% ranges are planning intervals, not guarantees. The service starts with wider default relative ranges early in a registration window and narrows them as the event matures. When historical comparable forecasts are available, it widens a range if the empirical 80th or 95th percentile historical error is larger than the default. Ranges always contain the current observed capacity signal and are bounded by configured event capacity.

The reliability panel reports the evidence level, comparable-event count, and back-test metrics for the selected and baseline models:

• MAE — average absolute error.
• RMSE — error measure that weighs larger misses more heavily.
• WAPE — total absolute error relative to total actual attendance.
• Bias — average tendency to over- or under-estimate.
• 80% / 95% coverage — how often comparable final outcomes fell inside their corresponding historical ranges.

Evidence is labelled low while data is early or sparse, medium after at least 72 live hours with three usable comparables, and high after at least 14 days with eight usable comparables and benchmark coverage. A final event is labelled final actual. Warnings remain part of the result so planners can see why a forecast is less dependable.

Every saved forecast is a vintage: it stores its as-of time, source fingerprint, model/data-contract version, forecast payload, and reliability information. Vintages are only added when the relevant source data or calculation window changes. After the event, registration and production vintages are evaluated after seven days; finance vintages are evaluated after 30 days. Evaluation records the final actual, error, percentage error, interval coverage, and interval width.

Evidence and limitations

Forecasts begin after enough valid live history is available. Early evidence produces deliberately wide ranges and visible warnings. The page refreshes while open, and each result records when the underlying data was checked.

The first release does not predict unrecorded future costs, provider payout timing, supplier lead-time uncertainty, future walk-up revenue, or future shop revenue. Treat every forecast as a planning aid, not a final financial statement.

Related actions

• Use Rego Analytics to investigate current tier, add-on, waitlist, and prefill facts.
• Use Finance Analytics and Accounting to reconcile real money movement.
• Use Inventory Analytics and Inventory Tracking before purchasing or reserving stock.