Constructing Design Rows for New Cases

From a New Case to a Design Row

A fitted generalized linear model can be used to calculate a linear predictor for a case that was not in the data used to fit it. The arithmetic is simple once the case has been represented correctly. The main task is to translate its recorded predictor values into the exact features used by the model, in the model’s established column order.

A case’s raw information is not necessarily the row of the design matrix. A model might use an intercept and two numerical predictors; it might instead use indicator variables for a categorical predictor, a centered and rescaled covariate, or a transformed covariate. For a new case, the design row must be built by applying those same definitions. The response value is not part of that row.

Here \(v\) denotes the new case’s predictor information, while \(z_j(v)\) denotes the value of the \(j\)th model feature after its definition has been applied. Thus, when a column represents a transformed variable, the entry in that column is the transformed value, not necessarily the raw value. When a column represents an intercept or an indicator, its entry follows that column’s definition.

The row is a row vector and the coefficient vector is a column vector, so their product is a scalar. This is the same matrix multiplication used for an observed case: the difference is that the row is constructed from a new predictor profile. The model’s coefficients and feature definitions stay fixed.

A Reliable Construction Procedure

Start with the original model specification or design-matrix definition, not with a guess about what the row “should look like.” Record the columns in their established order. Then evaluate every column’s feature definition for the new case, including the intercept, indicators, transformations, and any centering or scaling constants. Finally, multiply the completed row by the coefficient vector in the matching order.

This procedure is deliberately literal. It prevents a frequent source of incorrect calculations: substituting a new, convenient representation of the predictors even though the fitted coefficients correspond to the original representation.

Features Defined by Indicators or Transformations

Not every design column is a raw numerical measurement. For a categorical predictor represented with indicator columns, first use the model’s stated category coding. For a transformed predictor, evaluate the stated transformation. The resulting entries still occupy ordinary positions in the design row, and the linear predictor is still the corresponding sum of feature values multiplied by coefficients.

For instance, if a categorical predictor has a reference category and a column \(I(B)\), that feature is 1 for category B and 0 otherwise. A case in the reference category receives 0 in that column. If there are multiple indicator columns, evaluate each separately according to its definition. The names or values of the categories alone do not determine the row without knowing the model’s coding.

Why the Feature Definitions and Order Must Match

The following basic result makes explicit why the construction procedure gives the model’s linear predictor. It also clarifies that the row’s entries are not chosen independently of the coefficient definitions: each entry must correspond to its matching coefficient.

Proof. By the definition of matrix multiplication for a row vector and a column vector of length \(p\), \(\mathbf{x}_{\mathrm{new}}\boldsymbol{\beta}=\sum_{j=1}^{p}(\mathbf{x}_{\mathrm{new}})_j\beta_j\). The \(j\)th entry of the constructed row is \(z_j(v)\), so this equals \(\sum_{j=1}^{p}z_j(v)\beta_j\), which is the stated definition of \(\eta(v)\). Therefore the constructed row product is the linear predictor. \(\square\)

A consistently reordered schema also gives the same predictor, but only when the coefficient vector is reordered with it. This is useful when software or a written calculation displays the columns in a different order. Reordering a row while leaving the coefficients fixed is not such a consistent change.

Proof. Write the original product as \(\sum_{j=1}^{p}x_j\beta_j\). Under a common permutation, the reordered entries are \(x_{\pi(1)},\ldots,x_{\pi(p)}\), paired with \(\beta_{\pi(1)},\ldots,\beta_{\pi(p)}\). Their product is \(\sum_{k=1}^{p}x_{\pi(k)}\beta_{\pi(k)}\). Because \(\pi\) visits every index \(1,\ldots,p\) exactly once, this sum contains exactly the same terms as \(\sum_{j=1}^{p}x_j\beta_j\), only in a different order. The value is unchanged. \(\square\)

For several new cases, apply the same construction separately to each case and stack the resulting rows in the desired case order. If there are \(m\) new cases and \(p\) design columns, the resulting matrix \(X_{\mathrm{new}}\) has \(m\) rows and \(p\) columns. Its product with the coefficient vector has \(m\) entries, one linear predictor per case: \(X_{\mathrm{new}}\boldsymbol{\beta}\). This dimension check is a quick way to detect an incomplete row or an incompatible coefficient vector.

Common Mistake: Changing the Row but Not the Model

A common mistake is to replace a model feature with a raw value or a newly computed value because it seems more natural for the new case. For example, if a fitted column is \((x-50)/10\), inserting \(x\) directly into that position does not merely express the same feature differently. It changes the value multiplied by the coefficient. Likewise, putting the same entries in a different order without reordering the coefficients pairs features with the wrong coefficients.

The correction is to treat the design specification as fixed: use the same feature definitions and constants used for the fitted model, then use the matching coefficient order. If a different feature definition or column order is intentionally adopted, the coefficients must be represented in the corresponding way as well; it is not valid to change one side of the product alone.