Projected Measures and Entry Defaults
Future periods on a measure, Set to Previous Value and its siblings, and how projections and defaults interact with backfill.
Two under-documented mechanisms let a measure hold values for periods that haven't finished — or haven't started: projection (how many future periods a measure materialises) and entry defaults (what a period holds before anyone supplies a value). Several sites build forecasting on them; the tickets show where the mechanics surprise.
Projection: future periods, materialised#
A measure's Projected setting is a count of future periods the engine creates and maintains ahead of now. A daily measure projected 5 has today plus five future days materialised; as time advances, the window rolls forward.
What projection is for:
- Plans and forecasts on the same grid as actuals — a projected measure holding the plan for the coming month, chartable against actuals as the month fills in
- Entry ahead of time — operators entering next week's targets into a form
- Forward-looking calculations — a stockpile projection: known plan in, expected consumption out, for periods that haven't happened
The mechanics worth knowing before the tickets happen:
- Projection multiplies work. Every projected period is a real period the engine maintains per pass — recalculated as inputs change. A minutely measure projected far forward is thousands of live periods; the field reports of projected minutely measures timing out on open are this cost made visible. Project at coarse intervals (daily, weekly); if a fine-grained projection seems necessary, the model wants restructuring.
- Projected values are provisional by construction. As real data arrives, calculation replaces projection period by period. The classic pattern — actuals where known, plan where not — is a calculated measure choosing per period:
Measure_actual.Value != null ? Measure_actual.Value : Measure_plan.Value
- Projection needs the calendar to exist. Future periods can only materialise on a calendar that has them — a manual time scheme projected past its last defined period stalls exactly there. Extend the manual calendar beyond the projection horizon, always.
- Aggregations over projected ranges move constantly — a month-to-date over a projected month restates every pass as projections refine. Correct, but downstream consumers resend on every restatement; think before integrating a projected measure outward.
Entry defaults: what a period holds before a value#
Manual-entry measures choose what a new period contains before anyone types:
| Default | Behaviour |
|---|---|
| Set to previous value | The period opens holding the prior period's value |
| Set to 0 | Opens at zero |
| Set to null | Opens empty |
| Set to measure value | Opens holding another measure's value |
And for event-sliced manual measures, the slice split rule (SetToInitial vs SplitInitial) decides whether each slice takes the whole entered value or a share of it — the source of most "I entered 100 and got 33.3 per slice" confusion. See Time Slices.
Set to previous value is the one that generates tickets, because it is a default, not a calculation:
- It fills forward at period creation. It does not retro-correct: change a past value and later SPV periods that already exist keep what they had until touched or backfilled — the "SPV not backfilling on change" reports are this, working as built. Where "carry forward and track corrections" is the real requirement, use a calculated measure (
Measure_x.Value ?? Measure_x[-1].Value) whose dependency graph does recalculate on change. - SPV chains hide staleness beautifully: a value entered once and never again looks alive forever. Pair any operationally-significant SPV measure with a freshness check (Monitoring Infohub Health).
Set to measure value is the quiet powerhouse: a manual measure that defaults to a calculated baseline but accepts operator override — the survey-corrects-the-estimate pattern (stockpiles: calculation runs continuously; a monthly survey figure overrides; calculation resumes from the override).
The stockpile pattern, assembled#
The recurring ask — running total from flows, corrected by occasional surveys, projected forward — combines all of the above:
- Hourly stockpile calc: previous stockpile + inflow − outflow:
(Measure_self[-1].Value ?? 0) + Measure_in.Value - Measure_out.Value(a self-referencing previous-period read — the supported way to accumulate) - Survey override: a manual measure, default Set to measure value pointing at the calc — holding the calc's value until a survey replaces it; the calc chain reads the override measure as its previous value, so a survey re-bases everything after it
- Projection: the same structure with plan values feeding the projected window, real flows replacing plan as they land
Each layer is inspectable — which is the difference between this and one heroic expression when the stockpile number is challenged (it will be).
Diagnosing#
| Symptom | Cause |
|---|---|
| Projected measure won't open / times out | Projection count × interval too fine — reduce, or coarsen the interval |
| Projection stops at a date | Manual calendar ends there — extend it |
| SPV value wrong after correcting history | Defaults don't retro-fill — backfill the range, or use the calc pattern |
| "Aggregated measure doesn't move with my future substitute" | Aggregations read stored values; feed the projection through the measure the aggregation actually reads |
| Downstream flooded with restatements | You integrated a projected measure — send the actuals-only measure instead |