Grid Targets: When to Use Regression or Classification

A grid team needs a next-interval prediction. Should its model regress bus voltage or load change, or classify a switch state or voltage-limit event? The choice depends on the operator’s decision. A lower voltage error and a higher switch-classification score cannot be ranked on one leaderboard, and even a good voltage forecast may make poor alert decisions.

Decision summary

• Choose a numerical target when the size and direction of voltage or load change affect the action.
• Choose a categorical target when the action depends on whether an event occurred or which physical state holds.
• When both can serve the same workflow, map their outputs to the same operational outcome and compare them at matched forecast origins. Keep separate scorecards when no shared decision exists.

For a low-voltage screening task, this means comparing a thresholded voltage forecast with a direct event classifier on the same alerts. For load-ramp planning, the MW change remains essential; for switch-status work, define whether the task is forecasting a future state or identifying an unobserved current one. The cited power-system studies below examine related regression, classification, and topology questions in their own settings. The one-hour feeder and four voltage forecasts in this guide are hypothetical: the studies neither validate that example nor compare Sequifier on it.

Specify the operational decision before labelling

The target is a specification of the answer the model is expected to give. Its data type follows from the answer’s meaning, rather than from whether the raw CSV column contains numbers or strings.

Operational question	Candidate target at the next interval	Natural output	What the evaluation must preserve
How far might a monitored bus’s voltage move?	Voltage magnitude at that bus and phase, in per-unit or an explicitly stated physical unit	Numerical point forecast, or a predictive distribution if uncertainty matters	Error in the right unit, plus errors near any decision boundary
How much might feeder demand change?	Next load minus the latest available load, in MW	Signed numerical change	Ramp direction, size, and whether a level reconstructed from the change is useful
Will a particular switch be open?	Confirmed next-interval physical state of a named device	Categorical probability for open or closed	Rare changes, false alarms, missed changes, and label quality

There are different problems hiding in the third row. Forecasting tomorrow’s state uses only information available now, including a planned switching schedule if the operator really has it now. Identifying an unknown current state from present measurements is a state-estimation problem, with a different issue time. Predicting an operator command is yet another target; a command can fail or be delayed, so it should not silently stand in for the physical state. Research on distribution topology identification treats switching-device status as a distinct inference problem, often under limited measurements; that does not make a future switch action predictable from load history alone. See the topology-identification study and PNNL’s topology-ranking paper for examples of the separate problem formulation.

For voltage, specify which voltage before choosing a model: a measured or estimated magnitude, the bus, phase, voltage base, and aggregation interval. A per-unit error is meaningless if values from different voltage bases are pooled without a consistent convention. For load, specify whether the series is demand, net load, or another signed quantity; a behind-the-meter generation change can make net load behave differently from consumption. For a switch, specify the device identity and whether a missing or disputed telemetry state is excluded, adjudicated, or modelled explicitly. “Unknown” in a database is not automatically a third physical position.

An ML target also need not be the final business object. If the actual action is to inspect a possible voltage-limit breach, two defensible experiments are to forecast voltage and threshold it, or to train a classifier directly on the breach label. A contingency-screening study compares regression and classification for bus voltages and line loadings in its own power-system cases. A separate distribution-network study examines why constraint occurrence and violation magnitude can both matter. They motivate the comparison, but neither supplies results for the hypothetical feeder below or establishes a universal winner. The comparison has to be tied to the local decision.

Make one forecast origin unambiguous

Consider a hypothetical distribution feeder sampled hourly. At an issue time just after interval t closes, the service has validated readings through t and predicts interval t+1. Let V_t be voltage magnitude at one specified bus and phase, P_t be feeder net load in MW, and S_t be the confirmed position of one specified switch. With a history of L rows, the input is rows t-L+1 through t. Candidate targets are:

voltage target:     V_(t+1)
load-change target: ΔP_(t+1) = P_(t+1) - P_t
switch target:      S_(t+1) ∈ {open, closed}

This notation assumes a regular hourly grid and a deliberate policy for gaps. An event index is not an hour unless the data were made regular. Keep an audit timestamp and an availability timestamp for each input, even if the model table uses consecutive integer positions. A switch-status correction entered at t+2 but backdated to t was unavailable for the t+1 forecast. The same issue arises with revised meter values and weather observations. If a weather forecast was issued before the origin, use that vintage; do not substitute the later observed weather.

The row-oriented model table could contain sequenceId, itemPosition, voltage_pu, net_load_mw, delta_load_mw, switch_state, and calendar features. Keep feeder, bus, phase, timestamp, and device identifiers in a separate audit manifest or as appropriately designed features. delta_load_mw at row t is computed from P_t - P_(t-1), so it is known at the origin. Its value at t+1 is a target, never an input to that origin’s prediction. The switch label at t+1 should be joined from a trustworthy post-interval state record; an issued command is not sufficient evidence of the resulting position.

Field at the issue time	May enter the model?	Reason
Validated V_t, P_t, and S_t	Yes, if they had arrived by issue time	They are part of the observed history.
P_t - P_(t-1)	Yes	Both operands are historical.
Pre-announced switching plan for t+1	Yes, if actually available and permitted in the serving workflow	It is a known future covariate, not a future observation.
Realised V_(t+1), P_(t+1), or S_(t+1)	No	These define outcomes.
A corrected S_t entered after the issue time	No for a historical replay at that origin	A historical event timestamp does not prove availability.

Choosing the origin is particularly consequential for switch states. If an operations plan already specifies the action, a model that sees the plan might simply reproduce a known instruction. That can be useful for consistency checking, but it is a different value proposition from anticipating an unplanned transition. If the plan is withheld, sparse transitions may have little predictable signal. Evaluate those two use cases separately rather than attributing a plan lookup to sequence learning.

Define the scoring population before training

Create a manifest with one row per eligible (feeder, origin_time, target_time, target_id) before comparing models. Record whether each target is observed, its quality flag, and which input fields were available at the origin. A voltage target might be missing because the bus has no validated reading; a switch target might be disputed; a load target might cross a meter reset. Do not quietly drop different rows for each candidate and then compare their headline scores as if they described the same hours.

For a within-target model comparison, score exactly the same target IDs and origins. For a cross-target decision comparison, restrict to the subset where the downstream outcome can be evaluated for every candidate, and also report each candidate’s coverage on the full deployment population. The common subset answers “which method makes the better decision when both can speak?” Coverage answers “how often can each method speak?” Both matter.

Numerical error and categorical decisions are different scorecards

For voltage, mean absolute error (MAE) in per-unit or volts gives a readable average point-error measure. Root mean squared error gives large misses more weight. Neither alone tells an operator how often a threshold decision is wrong. Report the signed bias too: persistent overprediction near a low-voltage boundary is operationally different from persistent underprediction. Slice errors by bus, phase, topology, demand regime, distance to the limit, and sensor-quality flag. If probabilistic voltage output is needed, define the interval or distributional target and assess calibration and sharpness; a point estimate alone does not supply a defensible event probability.

For load change, report MAE in MW and signed bias for ΔP. Split positive ramps from negative ramps, and ordinary periods from large changes defined by a training-set threshold. A model can achieve small average ramp error by predicting almost no change, yet miss the rare changes that matter. Reconstructing the level as P_t + predicted ΔP_(t+1) lets the team check whether direct level forecasting or a persistence baseline is preferable for the actual decision. If a ramp alarm is the objective, set its size and direction threshold before looking at the test period and evaluate the resulting alarms.

For a switch state, overall accuracy is often the least informative primary number. If a device rarely changes, “copy the current state” can look strong while missing every transition. Report a confusion matrix, precision and recall for the actionable class, false alarms per device-time, and detection lead time when that is part of the task. Score next-state accuracy and transition detection separately. A probability-based classifier also needs a calibration check on the relevant operating population; its alert threshold should be chosen on validation data to reflect the cost of a false call versus a missed change. If the target is one of several switches, independent per-switch labels are not the same as one mutually exclusive network-topology class. Define the output structure accordingly.

The following tiny calculation shows why the target and downstream decision must both appear in the report. Suppose the hypothetical alert rule is “flag the bus if next-interval voltage is below 0.950 pu.” That number is an illustrative local rule, not a grid standard. Two voltage models make these four point forecasts:

Forecast origin	Observed V_(t+1)	Model A	Model B	Actual alert?
1	0.951	0.948	0.960	No
2	0.949	0.952	0.946	Yes
3	0.940	0.945	0.930	Yes
4	1.000	0.996	0.990	No

Model A’s MAE is (0.003 + 0.003 + 0.005 + 0.004) / 4 = 0.00375 pu. Model B’s is (0.009 + 0.003 + 0.010 + 0.010) / 4 = 0.008 pu. A is clearly better on this four-row point-error metric. But thresholding the same forecasts gives A one correct alert, one false alert, and one missed alert; B gives two correct alerts and no false or missed alerts. This is arithmetic on invented values, not performance evidence. On a real dataset, four origins would be far too few for a decision. The example isolates the criterion: if the decision is an alert, low MAE does not guarantee good alerts.

The comparison must still account for alert severity. Missing a 0.949-pu point and missing a much deeper excursion may carry different consequences. Conversely, a classifier that correctly flags a breach may give no estimate of its magnitude. The team can report event metrics and voltage error together, or define an agreed cost function that explicitly weights missed alerts, false alerts, and magnitude errors. That cost function is a statement about the operational workflow, not an intrinsic ML metric. Fix it before test evaluation and examine its sensitivity to plausible cost assumptions.

The same discipline applies across the three proposed targets. Raw voltage MAE, load-ramp MAE, and switch cross-entropy have different units and denominators. They cannot be ranked by their numeric values. To compare candidate systems, map each system to a shared decision and outcome. For a voltage-screening decision, the voltage model can be thresholded and the direct breach classifier can produce an alert; a switch-state forecast can be used only if a specified downstream rule or model converts it to that same alert. For a switching-workflow decision, compare methods on verified switch outcomes instead. If no shared decision exists, publish separate scorecards and stop calling it one contest.

Compare models under one reproducible experiment

The first comparison should be with simple methods matched to each target. A credible voltage baseline is the latest measured voltage or an existing engineering forecast; for some networks, a state estimator or power-flow workflow with known inputs is a more relevant reference than a generic ML model. For next-interval load change, start with zero change, a seasonal change estimate where a season is defensible, and a tree or linear model with recent lags and known covariates. For switch state, start with persistence, a documented operating-plan rule where applicable, and a classifier over recent status and telemetry. These baselines expose whether history, calendar, plans, or network calculations already answer the question.

Comparison dimension	Voltage or load-change regression	Switch-state classification
Target label	Measured or adjudicated real value at the fixed horizon	Adjudicated physical state at the same fixed horizon
Training objective	A loss appropriate to a real-valued target	A categorical loss appropriate to the class definition
Primary task metric	MAE in physical or per-unit terms; add bias and relevant tails	Precision/recall, false calls per device-time, and transition performance
Probability check	Only if a predictive distribution is actually produced	Reliability and threshold choice on validation data
Shared decision metric	Predeclared action outcome or cost	The same action outcome or cost, when the question truly overlaps

Use a chronological development period, later validation period, and untouched test period. If the deployment question is transfer to new feeders, add a feeder-held-out evaluation; a time split on familiar feeders is not evidence of cross-feeder generalisation. Keep the origin manifest fixed across the models being compared. Fit normalisation, categorical maps, imputation, and any event threshold from training data only. Tune hyperparameters and decision thresholds on validation data. Freeze them before one final test pass. Avoid random window splits that put nearly identical neighbouring histories on opposite sides of a boundary.

Power-system regimes complicate a time split. Switching, maintenance, sensor replacement, solar penetration, and changed control policies can alter both the input distribution and the meaning of a label. Keep a dated event ledger so poor performance around topology changes can be diagnosed rather than silently averaged away. Report denominators: number of feeders, buses, devices, origins, voltage excursions, load ramps, and switch transitions. A confidence interval or paired difference should respect correlated observations within a feeder and day; treating every overlapping hourly window as an independent experiment makes uncertainty look artificially small. Multiple cutoff periods are useful if the data span enough distinct regimes.

For numerical targets, examine a small set of diagnostic plots: actual versus predicted traces around large errors, error versus distance to the decision boundary, and error by asset. For switch targets, inspect transition timelines, command versus confirmed-state discrepancies, and periods with missing telemetry. Inspect resource costs too: inference latency, memory, retraining cadence, and how many assets require a separate output. A small metric gain may be irrelevant if the prediction arrives after the operator’s decision point.

When a shared sequence model is worth testing

Voltage, load, and switch histories interact. A switching event can change the network configuration that connects loads to measured voltages; load and generation changes can precede voltage movement. A sequential model can therefore be a reasonable candidate when the task depends on order and timing, the data preserve those relationships, and simpler lag or engineering baselines leave a measurable gap. It is a hypothesis to test, not an automatic advantage. A network with sparse telemetry, very few switch transitions, or reliable physical calculations may favour a simpler method.

Separate single-target models make the first evaluation easiest to interpret. A shared model with several output heads can then test whether one history representation benefits multiple targets. That experiment needs explicit loss weights and per-target metrics: adding an easy, frequent voltage target can dominate optimisation while doing little for rare switch changes. A multi-target model should be compared with single-target models under the same origin and input contract. Its value might be lower serving cost or better decision quality; neither follows from sharing parameters alone. A transformer trained on one feeder history is also not thereby a foundation model. Reusable representations require a separate transfer evaluation across tasks or networks.

Map the contract into Sequifier

Sequifier is one implementation path after the target and evaluation are fixed. Its README describes multivariate tabular sequences with numerical and categorical fields, selectable target columns, and a causal next-value objective. The preprocessing guide documents the required sequenceId and itemPosition ordering, explicit real_columns and categorical_columns, and training-only fitting of numerical statistics and dynamic category maps when normalize_on_all_data: false. That is useful for a grid table containing voltage and load as real fields and switch position as a categorical field.

For the hourly example, prepare the audited row table first. Use real_columns for quantities whose size matters, including an integer-valued count if it should be treated numerically; use categorical_columns for switch states or operating modes whose codes have no numeric distance. Preserve a separate as-of manifest because a model-format table alone does not prove that a reading had arrived by the issue time. Select the voltage, load-change, or switch column as the target for a dedicated first run. The training guide places input_columns and target_columns in the model interface and a per-target criterion in the dataset configuration. A categorical target’s class loss and a real target’s regression loss are different experiments, even if the backbone is the same.

For one-step-ahead causal prediction with an L-row context, the documented window arithmetic is a physical window_length of at least L + 1, preprocessing max_target_offset: 1, and training target_offset: 1. The final row is reserved as the future target; it must not enter that origin’s input. Sequifier’s preprocessing guide also supports chronological value_cutoff splits and prediction_aligned_splits for validation and test. If those are used, check the actual target positions and split ownership against the predeclared origin manifest. The inference guide documents generated predictions and optional full categorical probabilities via output_probabilities: true. Use those probabilities to evaluate calibration and select an alert threshold on validation data; the default top class is insufficient for that analysis.

This is a configuration map, not a drop-in YAML recipe: project paths, context size, architecture, metadata route, device, and data quality rules depend on the actual experiment. Sequifier supplies windowing and model execution. The grid team still owns the label definition, as-of joins, engineering baselines, physical plausibility checks, and decision-level evaluation. The practical next step is to build one verified origin manifest, run one simple baseline for each target, and then test a Sequifier causal model on whichever target has both a clear operational decision and a credible sequential signal. Once the target is fixed, context-length selection is a separate experiment: choose how much history is useful without changing the forecast question mid-comparison. If Sequifier proves useful for your experiments, you can star its GitHub repository.