Infohub (Flow)Concept

Time Slices and Event-Sliced Measures

The slice model underneath event-contextualised measures — the slice chain, and what "non-continuous time slicing" actually means.

Updated 15 Oct 2026Infohub Docs

When a measure carries an event in its context — production sliced by run, consumption sliced by batch — Infohub does not store one value per period. It stores values against time slices: the sub-periods produced by intersecting the calendar with the events. The slice model is load-bearing at every event-contextualised site and, until now, undocumented. Its failure mode ("non-continuous time slicing") stops schemes dead.

What a slice is#

Take an hourly measure sliced by a Production Run scheme. The 14:00 hour during which a run ended at 14:38 becomes two slices: 14:00–14:38 (run A's tail) and 14:38–15:00 (whatever followed). Values are stored per slice; the period's value is the slices' combination; the event's value is its slices' combination across periods.

That double bookkeeping is the entire point: one set of stored values serves both the calendar view (hourly/daily totals) and the event view (per-run totals), and they reconcile by construction.

Slices are chained: each slice knows its predecessor, and the chain must tile time — every slice's start equal to its predecessor's end. Manual-entry behaviour on sliced measures is governed by the split rules you choose (all slices take the initial value, or the value is split across slices — the two ManualEntryTimeSliceType options), which is why entering one number against a sliced period can land differently than expected.

"Non-continuous time slicing" decoded#

The error family looks like:

Non continuous time slicing: Previous time slice ID …
Previous time slice end 2026-05-27 14:00  From date 2026-06-16 10:00
Processing of event scheme set with ID … will stop

Meaning, literally: the slice chain has a gap — the next work item's start does not meet the previous slice's end — and rather than fabricate values across an undefined stretch, the engine stops processing that event scheme set. Every measure sliced by that scheme then freezes at the gap date while the rest of the model runs on, which is exactly the confusing symptom sites report: "16 measures stuck since May, everything else fine."

What creates the gap#

Retroactive event surgery — the top cause. Editing, deleting, or splitting events in already-sliced history can orphan the chain (the 7.2.0-era work hardened several of these paths; older versions are more fragile).
Boundary edits that stretch instead of insert — closing a gap by extending a neighbouring event rather than inserting into it (see Event Lifecycle Operations).
A scheme's events genuinely stopping while its measures continue — the watermark advances weeks past the last slice, and when the next event finally arrives, the chain cannot bridge.
Interrupted rebuilds — a split or backfill that regenerated part of the chain before failing.

Fixing it#

The error names everything you need: the previous slice's end (the gap's left edge) and the from-date (its right edge).

Backfill the affected measures across the gap — the standard repair. The engine rebuilds slices for the range and the chain reconnects. Set the backfill just before the gap's left edge.
If backfill re-sticks at the same date, the events in the gap are the problem — an open-ended or overlapping event in that range. Fix the event (close it, or repair the boundary), then backfill again.
Where history is genuinely unreconstructable (source purged), the pragmatic end-state is accepting the gap: backfill from after it and let the earlier chain stand as-is. The forensic check for whether events tile correctly is in the internal playbooks.

Prevention follows from the causes: insert rather than stretch, complete attributes after events close, treat bulk event edits as surgery with a backup, and keep long-outage periods on their own scheme.

Event scheme sets#

The error says "event scheme set" because slicing is computed per set — the grouping of scheme + calendar(s) the engine processes together. One implication worth knowing: a slicing failure stops the set, so several measures across metrics freeze together at the same date. Seeing a cohort of measures stuck at one timestamp is the signature that distinguishes a slicing stop from an ordinary stuck measure — diagnose it as slicing first.

Slices in expressions and forms#

Expressions see slices: Measure_<id>.Slices and the per-window SliceCollections exist in the calculation API precisely so event-aware calcs can work below period level.
Forms writing into sliced periods write per-slice; a cell that refuses entry immediately after event surgery usually means the slices for that period do not exist yet — backfill regenerates them.
Archived slice values follow the same retention rules as event data — purge takes them together. See The Maintenance Window.