Handbook of Regression Modeling in People Analytics With Examples in R and Python

1. 1State the purpose before you run anything: inferential (understand what influences the outcome) or predictive (forecast it). Inferential means you must be able to explain how each variable acts on the outcome, which variables matter, and how much of the outcome the variables explain. People analytics is usually inferential. Samples are rarely big enough for accurate prediction, and stakeholders who bear the consequences want to know how a result is generated.
2. 2Write the model in the source's notation before you fit it: y = f(X) + ϵ. X is several columns measuring your constructs, y is one column for the outcome, f is the relationship you are testing, and ϵ is random error you cannot control. If you cannot name each piece for your project, you do not yet understand the model.
3. 3Name the population and the sample S explicitly. Ask which population the sample is meant to speak for, and whether your confidence statements apply to that population or only to S. Generalizing from S to the population is the main purpose of inferential modeling.
4. 4Classify f as parametric or non-parametric. In a parametric model the modeled y is known once you apply the formula to X. A non-parametric model needs extra information, such as y values in observations with similar X. Know which one you are using so you can say how a predicted value is produced.
5. 5Attach a mathematical meaning to every output you report. For each coefficient or fit measure, write one sentence on what scale it is on and what it means. For logistic models that means being able to move between log odds, odds and probability (the book devotes sections 5.2.1 to 5.2.3 to this). Never quote a log-odds coefficient as if it were a probability change.
6. 6Separate 'a relationship exists' from 'one causes the other'. Before drafting conclusions, strike any causal verb that the modeling cannot support. Say 'is associated with' unless you have grounds for more.
7. 7Write down two or three hard questions a skeptic will ask, then answer each using only the mechanics of the model: what f is, what the sample is, what the coefficient scale is, what the generalization claim rests on. If you cannot answer one, close the gap in your understanding before presenting.
8. 8Match depth to need. You do not need the deepest theory to run and interpret models fluently, but you need enough to judge results and defend them. Stop when you can explain every number you plan to show.

Take the Chapter 4 walkthrough: students' results in their first three years and their results in the fourth year. Notation: X is the three yearly scores, y is the fourth-year score, and f is tested as a linear relationship, which makes the model parametric because the formula gives the modeled y once X is known. The population is all past, present and future students who take similar examinations. The sample S is the students who completed their studies in the past three years. The analysis establishes that the linear relationship can be generalized to the whole population with a substantial level of statistical confidence. A critic asks, 'Does this show that strong early scores cause strong fourth-year scores?' An analyst with the right grounding answers that it shows a statistical relationship that holds beyond the sample, not causation. A second critic asks why you trust it for future students. The answer is that the population was defined to include them and the inference is about the population, with the confidence level stated as such. Both answers come directly from understanding y = f(X) + ϵ and the S-to-population logic.

• If the stakeholder needs to know why an outcome happens or will act on individuals, choose a model you can open up (an inferential regression) over a more accurate black box.
• If your data set is small, as most people analytics data sets are, expect inference rather than prediction to be the realistic goal and say so.
• If you are about to report a coefficient, then first state its scale and translate it into plain language; for logistic models, move explicitly between log odds, odds and probability.
• If a sentence contains 'causes', 'drives' or 'leads to', then check whether the analysis supports it; otherwise rewrite it as an association.
• If you cannot answer a likely critique from the model's own mechanics (f, S, population, scale), then you are not ready to present; study that piece first rather than skipping the math.

• Running multivariate models without understanding the mathematics behind them. The tell: you can produce output but stall when asked 'what does this number mean?' or 'why this model?'
• Reading correlation as causation in the conclusions. The tell: the write-up says a construct 'causes' or 'drives' the outcome when all you showed was a statistical relationship.
• Treating a sample result as a population fact. The tell: no statement of who the population is, or findings stated about S with no generalization logic.
• Confusing inferential and predictive aims. The tell: you defend a model on accuracy when stakeholders asked how it works, or you cannot explain which variables matter and how much of the outcome they explain.
• Skipping the math because it seems optional. The tell: coefficients are reported on a transformed scale such as log odds with no translation, and the audience cannot tell what a change means.

• ▸Purpose: inferential or predictive? Write one sentence on why, including who is affected by the result.
• ▸Population and sample S: define who the findings are meant to apply to and who is actually in the data.
• ▸Outcome y: name the single outcome column and how it is measured.
• ▸Inputs X: list the columns and the construct each one measures.
• ▸Form of f: parametric or non-parametric, and the specific structure tested (for example linear).
• ▸Scale of each reported coefficient: say whether it is on the raw outcome scale or on log odds, and write the conversion to odds or probability if relevant.
• ▸Plain-language translation: one sentence per key result that a non-analyst could repeat.
• ▸Generalization and causation check: state what you can claim about the population and list any causal words you removed.
• ▸Anticipated critique and answer: write the hardest question you expect and answer it using only the model's mechanics.

1. 1Build fluency from the process, not from the output. Walk the steps in order: define the outcome and input constructs, confirm reliable measurement, sample and clean, run EDA, format data per model, run models, interpret outputs and diagnostics, select a model, then state which inferences generalize. Write each step in your own project notes so you can say where any number came from.
2. 2Master the statistical foundations before the model. Be able to explain, without notes, the sample mean, variance, standard deviation, standard error, the t-distribution and a confidence interval. The source places these (Chapter 3) ahead of regression because they determine whether a model is judged useful.
3. 3Reproduce one worked calculation by hand. Take a random sample of 100 customer_rate values from the salespeople data, compute the mean and the standard error (sd/sqrt(n)), find the multiplier with qt(p = 0.975, df = n - 1), and build the 95% interval. Confidence comes from knowing why the interval is ±1.98 standard errors, not from reading it off the output.
4. 4Run the sampling experiment from Figure 3.1. Draw 10, 100 and 1000 samples of size 50, 100 and 150 and plot the means. Watch more samples give a more normal shape and larger samples give a narrower spread. You will then be able to defend why a small people-analytics sample limits precision.
5. 5Decide the aim before you pick the model: inference (understand what influences the outcome) or prediction. In people analytics, inference is usually required, because data sets are rarely large enough for satisfactory prediction accuracy and stakeholders will not accept decisions affecting individuals without some understanding of how the predictions are generated.
6. 6For each model, state in plain language what each coefficient says, which inputs are meaningful, and how much of the outcome the inputs explain. Then run the diagnostics and assumption checks the source requires. Do not present a model whose assumptions you have not tested.
7. 7Before communicating, write the claim at the strength the evidence supports. Say a relationship generalizes from sample S to the population with a stated level of statistical confidence. Never say one variable causes another. Pair every finding with its interval and any footnoted caveat, such as a variable found non-significant or a non-linearity that improved fit.
8. 8Document the work so it can be re-run (R Markdown, per Section 2.8). Reproducibility is the evidence that your fluency is real and lets others check your judgments.

The source's Chapter 4 example relates students' scores in the first three years of a program to their fourth-year score. The population is all past, present and future students taking similar examinations, and the sample S is those who completed their studies in the past three years. The inputs X are the three yearly scores and the outcome y is the year-four score. The analyst tests f as a linear relationship and finds it generalizes to the population with a substantial level of statistical confidence. A fluent analyst also reports two findings from the footnote: the first-year score plays no significant role in f, and adding some non-linearity improves the statistical accuracy of the inferred relationship. The analyst states the conclusion as a relationship that holds beyond the sample, not as proof that earlier scores cause later results. The same fluency applies at the foundation level: with the sample of 100 customer_rate values, the mean is 3.6485 and the standard error is 0.0849. Multiplying by 1.984 gives a 95% interval of about 3.48 to 3.82. The analyst can explain that this range is built to contain the true population mean with 95% confidence.

• If you cannot explain a number's derivation (e.g. why 1.98 standard errors gives a 95% interval), then stop and rebuild it by hand before presenting it.
• If the decision affects individuals and stakeholders need to trust the output, then choose a model whose inner workings you can explain (inference power) over one that only predicts accurately.
• If the sample is small (under about 50 observations), then treat the t versus z distinction as material, and expect wider intervals and more limited methods.
• If the evidence shows a relationship between a construct and an outcome, then report it as an association with its confidence level, and make no causal claim unless the design supports it.
• If an input is non-significant or the fit improves with non-linearity, then report it, including in a footnote, instead of smoothing it out of the story.

• Stating causation from a correlational model. The tell: verbs like 'drives' or 'causes' appear in findings built only on a fitted relationship.
• Reading output without understanding the foundations. The tell: you can quote a p-value or interval but cannot say what a p-value of 0.01 means or how a standard error produces the interval.
• Defaulting to prediction when the audience needs explanation. The tell: you report accuracy but cannot say which variables matter or how each acts on the outcome.
• Skipping assumption checks and diagnostics because the model ran. The tell: results are presented with no linearity, error-variance or other checks, especially for models the source says cannot be used blindly.
• Overstating precision from small samples. The tell: narrow-sounding conclusions on a few dozen employees, with no standard error or interval, and no mention of how sample size limits the method.

• ▸Outcome and inputs: name the outcome y and each input X, and the broader objective they serve.
• ▸Aim: mark inference or prediction, with a one-line reason tied to who bears the consequences.
• ▸Sample and population: state who is in sample S, who the population is, and the sample size n.
• ▸Key estimate and interval: record the coefficient or mean, its standard error, and the 95% confidence interval.
• ▸Plain-language explanation: write one sentence a non-analyst could repeat about what the result means.
• ▸Diagnostics run: list each assumption check performed and its result.
• ▸Non-significant or unexpected findings: note any inputs with no significant role or non-linearity found.
• ▸Claim strength: write the conclusion as association or generalization, and note what you cannot claim (e.g. causation).
• ▸Can I derive it?: list any number you cannot explain from first principles, to rebuild before presenting.

1. 1Name the inferential question before touching sample size. The source defines inferential modeling as learning a relationship between X (measures of constructs) and y (the outcome) from a sample S, then generalizing it to the population with high statistical certainty. Power analysis protects that generalization, so write the relationship you want to detect in one sentence.
2. 2Match the power calculation to the analysis you will run. The book's power chapter is organized by method: simple hypothesis tests (Welch's t-test for a difference in means, the t-test for correlation, the Chi-square test for frequency differences), linear regression, log-likelihood regression models, and hierarchical regression. Pick the section that matches your planned model rather than using one generic calculation.
3. 3Fix the three inputs the book's power chapter is built on: the error rates you will tolerate (Type I and Type II, the 'Errors' in the chapter title), the effect size, and the significance level. Decide these before looking at the data you have. Justify the effect size from the smallest relationship that would matter to the decision, not from what the data happens to show.
4. 4Solve for the required sample size. Treat the sample size, effect size, significance level and power as a linked set: fix any three and the fourth follows. The book covers this in R and in Python. Use the same tool you will use for the final model so the assumptions match.
5. 5Compare required n to the n you can actually obtain. The foreword notes that employee populations are often relatively small, which can limit the methods you can use. Count usable observations, not headcount. Chapter 4 treats sparseness ('missingness') as a separate input problem, so complete cases may be fewer than the rows you have.
6. 6Scale the requirement to model complexity. Each extra input variable and each hierarchical or grouped structure is a separate section of the power chapter. Re-run the calculation for the model you intend to fit, not for a simpler stand-in.
7. 7If the sample is short, change the design rather than the claim. Options consistent with the source are to narrow to a simpler test, reduce the number of inputs, collect more data, or accept and state a larger minimum detectable effect. Because people analytics data are rarely large enough for satisfactory prediction accuracy, frame the work as inference and report it that way.
8. 8Document the calculation in your analysis file (the book promotes R Markdown) with the inputs, the method used and the resulting n. Anyone who later reads a non-significant result can then judge whether the study was able to detect an effect at all.

The source supplies the framework and the context but no worked power numbers, so this example is an illustration of the sequence, not a result from the book. An HR analytics team wants to test whether two employee groups differ in mean outcome using Welch's t-test (section 3.3.1). Before analysis, they follow the power chapter's logic and fix the significance level, the target power, and the smallest mean difference that would change a decision. They then solve for the required n per group (section 11.2) and write the three inputs and the result into their R Markdown file. They count usable records per group after removing missing values, because missingness shrinks the effective sample. If one group is smaller than the required n, they do not report a null result as 'no difference'. They report the smallest difference their sample could have detected, or they increase the minimum meaningful effect only if the decision genuinely supports it. The same procedure moves to the linear regression section (11.3) once they add inputs.

• If your planned analysis is a simple test (Welch's t, correlation t-test, Chi-square), then use the simple-hypothesis-test power approach; if it is multiple regression, a log-likelihood model or a hierarchical model, then use the section written for that model.
• If the available usable n is below the required n, then do not run the planned model and report the result as 'no effect'; simplify the model, gather more data, or restate the claim as exploratory.
• If your population is small (typical of employee data), then prioritize inference over prediction, because small data rarely supports satisfactory predictive accuracy.
• If you cannot defend the effect size by a decision-relevant minimum, then do not size the study on an optimistic effect pulled from prior results; use the smallest effect that would change the decision.
• If missing data removes many rows, then calculate power on the complete-case count, not the raw row count.

• Running the power analysis after the results are in and reverse-engineering the effect size to match what was found. Tell: the stated effect size equals the observed one and no one can say why it matters.
• Reading a non-significant result as proof of no relationship in a small sample. Tell: the write-up says 'no effect' with no statement of the smallest effect the sample could detect.
• Sizing for a simple test and then fitting a model with many inputs or a hierarchical structure. Tell: the power calculation names a t-test but the final model is a multivariable or grouped regression.
• Counting headcount instead of usable observations. Tell: the stated n differs from the n in the model output because of dropped missing rows.
• Treating a small organizational sample like a large general data set and expecting predictive accuracy. Tell: the report promises predictions to individuals from a few hundred or fewer records without any accuracy or power justification.

• ▸Research question: State the relationship between the construct(s) X and outcome y that you want to detect, in one sentence.
• ▸Planned method: Name the test or model (Welch's t-test, correlation t-test, Chi-square, linear, log-likelihood, hierarchical).
• ▸Smallest meaningful effect: Write the smallest effect that would change a decision and the reason it matters.
• ▸Significance level: Record the Type I error rate you will accept.
• ▸Target power: Record the probability of detecting the effect you require (Type II error tolerance).
• ▸Required n: Enter the sample size produced by the power calculation, plus the tool and code used (R or Python).
• ▸Usable n available: Enter the number of complete observations after handling missing data, per group if relevant.
• ▸Number of inputs/structure: List the input variables and any grouping or hierarchy that the model will include.
• ▸Gap and action: If usable n is below required n, record the chosen response (simplify, collect more, restate the minimum detectable effect, or label as exploratory).

1. 1Clean the data before fitting anything. Run sum(is.na(salespeople)) and confirm it returns 0 after complete.cases() filtering. Missing values silently shrink or distort the sample your conclusions describe.
2. 2Check each column's type and values. Run unique(salespeople$performance) to see the four values (1, 2, 3, 4). Convert it with as.factor() so the model treats it as categories, not a continuous number. A wrong type is a measurement distortion built into the model.
3. 3Read every message, warning and error as evidence. Errors halt the code, but warnings flag a problem with the output, such as a model that did not converge. R still returns results in that case, so those results cannot be trusted until you resolve the warning.
4. 4Keep the input set small and justified. The more inputs, the harder the model is to interpret and the greater the risk of multicollinearity. Do not add inputs derived mathematically from inputs already in the model. In extreme cases you end up with more inputs than observations.
5. 5Compare candidate model versions with AIC(). Lower AIC means a more parsimonious model. Compare the sales-only, sales-plus-customer-rating and full models side by side.
6. 6Do not read AIC as a quality or confidence measure. The lowest AIC can still be a poor fit, so judge fit and significance separately.
7. 7When many inputs are unavoidable, apply coefficient regularization such as LASSO to control complexity.
8. 8For survey items, test the measurement before the outcome. In a structural equation model, run a confirmatory factor analysis to confirm that the item groupings form a high-quality measurement model. Only then regress the outcome on the latent factors.
9. 9Fit the sample to the claim. People analytics data sets are rarely large enough for accurate prediction, so frame conclusions as inference and explain how the model reaches them. Stakeholders who bear the consequences will not trust an unexplained output.

The promotion model in the passages uses salespeople data with promoted, sales, customer_rate and performance. First the data is checked: sum(is.na(salespeople)) returns 0, and performance has four unique values, so it is converted to a factor. Three logistic regression versions are then fitted. AIC is 76.49508 for sales only, 71.13145 for sales plus customer rating, and 76.37433 for the full model. The simpler two-input model has the lowest AIC, so it is the most parsimonious, and its two inputs are the significant ones. The source warns that AIC does not measure quality or confidence, so the lowest AIC could still be a poor fit. The conclusion is therefore limited to saying the two-input model achieves similar fit with fewer inputs, which lowers the risk of multicollinearity. It does not say the model is accurate.

• If sum(is.na(data)) is not 0, then remove or resolve the missing rows before modeling and re-confirm it returns 0.
• If a numeric column has only a few distinct values (like performance with 1 to 4), then check unique() and convert with as.factor() so it is treated as categories.
• If R returns a warning such as non-convergence, then treat the results as suspect and fix the model before reporting, even though output was produced.
• If a simpler model reaches the same or a lower AIC than the full model, then adopt the simpler model, but still assess its fit separately.
• If you have many survey items measuring a few underlying themes, then use a measurement model (confirmatory factor analysis) first, and move to the structural model only once the factors are satisfactory.

• Reading AIC as proof of a good model. The tell: you describe the lowest-AIC model as accurate or confident without any separate fit check.
• Ignoring warnings because output appeared. The tell: a non-converged model's coefficients end up in the report.
• Piling on derived inputs to please a boss or client. The tell: inputs are mathematical transformations of existing ones, and multicollinearity or inputs outnumbering observations follows.
• Leaving a categorical code as a number. The tell: performance (1 to 4) is left as numeric, so the model treats it as continuous.
• Presenting a black-box prediction in a people decision. The tell: stakeholders cannot explain how the output was generated and withhold trust.

• ▸Missing values check: record the result of sum(is.na(data)) after complete.cases() filtering; the target is 0.
• ▸Column types verified: list each categorical column and confirm it was converted (e.g., performance via as.factor()).
• ▸Warnings and errors log: list every warning or error from the model run and how you resolved it.
• ▸Inputs and rationale: list each model input with one line justifying it, flagging any derived from other inputs.
• ▸Observations vs. inputs: record the number of observations next to the number of inputs.
• ▸Model comparison (AIC): list each model version with its AIC and note which is lowest.
• ▸Separate fit assessment: state the evidence of fit and significance that does not rely on AIC.
• ▸Measurement model status (if using survey items): record whether the confirmatory factor analysis grouping is satisfactory before the structural model.
• ▸Stated limits of the conclusion: write one sentence on what the model supports (inference) and what it does not (prediction).

1. 1Start from the decision, not the model. Write the consequential people decision in one sentence, name who makes it, and say what they currently rely on (gut instinct or a borrowed 'best practice'). That incumbent is what your evidence has to beat. It is the first step of inferential modeling: define the outcome and input constructs from a broader evidence-based objective.
2. 2Classify the question as inference or prediction before choosing a method. If the stakeholder needs to know why an outcome happens, build an inferential model. You need to see how each variable acts on the outcome, which variables matter, and how much of the outcome your variables explain. Choose prediction only if accuracy is the whole point and the data set is large enough to deliver it.
3. 3Default to inference when people bear the consequences. The passages give two reasons: people analytics data sets are rarely large enough for satisfactory prediction accuracy, and stakeholders will not trust or bear the consequences of a model whose output they cannot understand. Select regression-type models that give both inferential and predictive value.
4. 4Check measurement before modeling. Confirm the outcome has reliable measurement data, decide which data actually measure each construct, and define the sample. Then run exploratory analysis, such as a pairplot of univariate and bivariate patterns, before proposing candidate models. Impact depends on the audience believing the inputs.
5. 5Fit the model structure to the decision. For an unordered outcome with more than two categories, choose between separate one-versus-rest models (stratified, no common comparison) and a multinomial model with a reference category. Use the multinomial model when the decision depends on relative odds. Before you commit, check the independence of irrelevant alternatives (IIA) assumption.
6. 6Run the models, interpret the outputs, and run diagnostics before you select an optimal model. Be ready to explain the mechanics in plain terms. The passages argue that you cannot credibly answer questions or critique about a multivariate model without understanding its underlying mathematics.
7. 7Report the effects in terms the decision-maker acts on. Name the variables that are meaningful, say how each moves the outcome, and state how much of the outcome the model explains. Remember that effects can be subtle or meaningful only in combination, so show the combinations that matter to the decision.
8. 8Make the work reproducible. Deliver the analysis as an integrated document of text and code (for example R Markdown) so others can obtain and run it. The source states that code others cannot easily run has a very limited impact and lifetime. Also record the regulatory or evidentiary requirements the analysis was built to satisfy.

The passages describe a scenario: an organization wants to understand mid-tenure career path changes. These have several unordered categories, so a single binary outcome does not fit. Option one is a stratified approach: separate 'Category A versus the others' binomial logistic models. This lets you refine each model differently, but there is no common comparison category, so the results cannot be compared across paths. Option two is a multinomial logistic regression with a reference category, probably the most common career path. Every other path's odds are then read relative to that reference, which suits an HR leader asking what makes someone more likely to take path X than the usual path. Before relying on it, check the IIA assumption: no excluded alternative should disproportionately pull membership from one of the included categories. If IIA fails, fall back to the stratified or a nested approach. Deliver the result with the interpretable coefficients, the model-fit and diagnostic results, and a reproducible document. The leader can then act on a stated mechanism rather than a hunch. No numerical results are given in the source, so none are invented here.

• If the stakeholder asks 'why is this happening?' or the decision affects individuals, then build an inferential model, even if a black-box predictor might score slightly higher.
• If your data set is small, as employee populations often are, then do not promise predictive accuracy. Frame the deliverable as inference about what influences the outcome.
• If the outcome has more than two unordered categories and the question is about relative odds, then use a multinomial model with an explicit reference category. If the categories need separate model refinement and no cross-comparison, use the stratified approach.
• If the IIA assumption looks violated, then switch to a stratified or hierarchical/nested alternative rather than reporting the multinomial coefficients as is.
• If the analysis cannot be re-run by someone else from your documents, then it is not finished. Package the code and narrative together before presenting.

• Running a model without understanding its mathematics. The tell: you cannot answer a basic challenge about what a coefficient means or why a variable was dropped, and credibility collapses in the meeting.
• Delivering an opaque predictive score for a consequential people decision. The tell: stakeholders ask 'how does it arrive at that?' and decline to act on it or bear the consequences.
• Treating outcomes with several categories as one binary question, or reading stratified models as comparable. The tell: there is no shared reference category, yet the deck ranks the odds across categories.
• Ignoring multi-factor complexity by reporting single-variable stories. The tell: the recommendation rests on one variable, even though effects may be subtle or visible only in combination.
• Leaving the work undocumented and unreproducible. The tell: the code lives on one laptop, nobody else can re-run it, and the insight fades after the first presentation.

• ▸Decision and owner: one sentence naming the consequential people decision and who makes it.
• ▸Current basis: what the decision rests on today (gut instinct, borrowed best practice, other).
• ▸Question type: inference (why) or prediction (will it happen); justify the choice given sample size and impact on individuals.
• ▸Outcome and measurement: define the outcome variable, its data source, and why the measurement is reliable.
• ▸Input variables and sample: list the inputs, the sample S, and the cleaning steps applied.
• ▸Model choice and structure: model type, and for multi-category outcomes, stratified or multinomial with the named reference category plus the IIA check result.
• ▸Diagnostics and fit: key diagnostics run and the explained share of the outcome in the model's own fit metrics.
• ▸Plain-language findings: which variables matter, how each acts on the outcome, and any effects that appear only in combination.
• ▸Constraints and reproducibility: regulatory or evidence requirements met, and the location of the runnable code-plus-narrative document.

1. 1Inspect the outcome column y first: check its data type, count of distinct values, and whether values are numeric, labeled categories, or a time/event pair. This single inspection dictates the entire model family.
2. 2If y is numeric and can take any value on a continuous scale, route to linear regression (Chapter 4) and plan to test its assumptions: linearity/additivity, constant error variance, normally distributed errors, and low multicollinearity.
3. 3If y has exactly two categories, route to binomial logistic regression (Chapter 5); model the log odds rather than the raw probability, then convert coefficients to odds and, where needed, to probabilities.
4. 4If y has three or more unordered categories, route to multinomial logistic regression (Chapter 6): pick a reference level and estimate one binomial-style contrast per remaining category against it.
5. 5If y has three or more ordered categories, route to proportional odds logistic regression (Chapter 7) and explicitly test the proportional odds assumption using stratified binomial coefficients and the Brant-Wald test before trusting the model.
6. 6If y is a singular event measured over time (with censoring), route to survival analysis: fit a Cox proportional hazard model (Chapter 9) and check the proportional hazard assumption; add a frailty term if grouped observations share unobserved risk.
7. 7If observations are nested in explicit groups (hierarchy), add random effects via a mixed model (Chapter 8.1); if the construct itself is latent and measured by multiple indicators, use a structural equation model (Chapter 8.2).
8. 8Confirm the same technique is available in your language of choice (R or Python via statsmodels OLS, logistic, multinomial, SEM, survival) before committing, so implementation matches the outcome type.

Consider the salespeople data set, which records sales, average customer ratings and performance ratings. If you model 'sales' (a continuous numeric column) as the outcome, linear regression is appropriate: you fit y = f(X) + ε with a linear f, interpret each coefficient as the change in sales per unit of input, and then check constant error variance and normally distributed errors. If instead you recode the outcome to whether a salesperson was promoted (yes/no), the outcome is now binary, so you switch to binomial logistic regression and interpret coefficients as log odds. If the outcome were an ordered performance rating (low/medium/high), you would move again to a proportional odds model and test that assumption with the Brant-Wald test. The same X columns feed all three, but the measurement nature of y forces three different techniques.

• If y is continuous, then use linear regression and validate the four assumptions before interpreting coefficients.
• If y has two categories, then use binomial logistic regression and model log odds, not raw probability.
• If y has unordered categories ≥3, then use multinomial logistic regression with a chosen reference level; if the categories are ordered, then use proportional odds logistic regression instead.
• If y is a time-to-event with censoring, then use a Cox proportional hazard model and verify the proportional hazard assumption.
• If observations are nested in known groups or the construct is latent, then add random effects (mixed model) or move to an SEM rather than a flat single-level regression.

• Treating an ordinal outcome as nominal (multinomial) and discarding the ordering — the tell is coefficients that trend monotonically across categories, signaling proportional odds would fit more parsimoniously.
• Fitting a proportional odds model without testing the assumption — the tell is divergent coefficients across stratified binomial models and a failed Brant-Wald test.
• Running linear regression on a binary or count outcome — the tell is predicted probabilities outside 0–1 and non-constant error variance in residual plots.
• Ignoring censoring by modeling time-to-event as a plain continuous outcome — the tell is systematically biased time estimates because incomplete follow-up is treated as the event time.
• Fitting a flat model when data are hierarchically grouped — the tell is underestimated standard errors and correlated residuals within groups that a mixed model or frailty term would absorb.

• ▸Outcome column name: name the single y column you are modeling.
• ▸Data type: record numeric, categorical-labeled, or time+event pair.
• ▸Distinct value count: count unique outcome values.
• ▸Ordered?: state whether categories have a natural order (yes/no).
• ▸Censoring present?: note if any observations are incomplete over time (yes/no).
• ▸Grouping structure: list any nesting or repeated-measure groups in the data.
• ▸Selected technique: write the routed model (linear / binomial / multinomial / proportional odds / Cox / mixed / SEM).
• ▸Assumption to test: name the key assumption for that technique (e.g., proportional odds, proportional hazard, constant error variance).

1. 1Write the outcome (y) and the inputs (X) in one sentence before touching a model. The source treats defining the outcome and input constructs from a broader evidence-based objective as step 1 of inferential modeling. Technique selection comes after that sentence, not before it.
2. 2Classify y by what its values are: continuous (e.g., sales, retail price, total_donations), binary (e.g., whether a recent donation was made), ordinal (ranked categories), or time-to-event (e.g., employee attrition). The book gives each family its own chapter: linear regression for continuous outcomes, proportional odds for ordinal outcomes, and survival/Cox models for time-to-event. Pick the family that matches y.
3. 3State the inference goal separately from the outcome type. Ask whether you need to explain what drives y (coefficients you can interpret, e.g., 'comparing two cars of the same make, each extra dollar of manufacturing cost changes price by…') or only to predict it. The source says many analysts choose the more interpretable model even when a more complex one fits slightly better.
4. 4Check the independence assumption before committing. Plain methods assume the data are independent and identically distributed. Ask whether one row's value could be influenced by or share a source with another row, such as colleagues serving the same customers. If so, the data have hierarchy and the technique must be adjusted, for example with the frailty models the book covers in the survival chapter.
5. 5Run EDA first (e.g., a ggpairs pairplot shows every univariate and bivariate pattern at once). Look at the shape of y and the relationship of each input to y. This is step 5 of the process, and it confirms or challenges the family you picked in step 2.
6. 6Use linear regression as the benchmark when y is continuous. The source describes it as often the first method trialed, giving an immediate benchmark against which to judge more complex techniques. Check its assumptions explicitly: linearity and additivity, via true-versus-fitted and residuals-versus-predicted plots.
7. 7If an assumption fails, change something deliberately. Either change the model form (the source's student-examination example found that introducing some non-linearity into f improved accuracy) or change the technique family. Do not report results from a model whose assumptions you have seen fail.
8. 8Record the choice and the reason in your R Markdown document: outcome type, inference goal, assumptions checked, and the alternative you rejected. Reproducibility covers the reasoning as well as the code.

Take the salespeople data set, where sales is a continuous outcome. Step one is to classify y: continuous, so linear regression is the natural benchmark. Step two is to test independence. The source reasons that one person's sales are not influenced by another's, so the independent-and-identically-distributed assumption is reasonable here. It then gives the counter-case: if the salespeople worked together serving the same customers on the same products, and each person's sales were a proportion of the overall sales to that customer, the data would not be independent. You would expect hierarchy and would need to adjust the technique. Same outcome type, different data structure, different technique. Now switch outcomes. In the vehicle example, retail price is continuous, so linear regression applies. Make is a categorical input, so the model creates dummies with Audi as the reference. The coefficient for Ford is then read as the price difference versus an Audi of the same manufacturing cost. By contrast, the charity_donation exercises ask whether a recent donation was made (yes/no). That outcome is not continuous, so ordinary linear regression is not the default there.

• If y is continuous and rows are independent, start with linear regression as the benchmark and interpretable baseline.
• If y is ordinal, use a method built for ordered categories (proportional odds regression) rather than treating the ranks as continuous.
• If y is time-to-event, such as attrition over time, use survival analysis (Cox proportional hazard) rather than a standard regression on the outcome.
• If rows share a source (same customers, same teams) and independence fails, adjust the technique for the hierarchy before interpreting any coefficients.
• If a more complex model fits only slightly better than the simpler one and your goal is explanation, keep the simpler, more interpretable model.
• If the linearity check fails (curved pattern in true-versus-fitted or residuals-versus-predicted), add non-linearity to the model or change technique before reporting.

• Choosing the technique by familiarity rather than outcome type. Tell: you can't state the type of y in a sentence, or you apply OLS to a yes/no or ranked outcome.
• Assuming independence without testing it. Tell: rows are grouped by a shared customer, team or product, yet the model treats each row as an unrelated observation.
• Skipping assumption checks after the model runs. Tell: no true-versus-fitted or residual plot appears in the work, and results are reported as final.
• Ranking inputs by coefficient size. Tell: you conclude a dummy variable matters more than manufacturing cost because its coefficient is larger. Units differ, since a dummy is all-or-nothing and a dollar is a tiny unit.
• Chasing fit over purpose. Tell: you swap in a complex model for a small fit gain and lose the ability to explain the relationship you were asked to explain.

• ▸Outcome of interest (y): one sentence defining what is measured and why.
• ▸Outcome type: continuous / binary / ordinal / time-to-event.
• ▸Inference goal: explain drivers, test a hypothesis, or predict.
• ▸Input variables (X) and their types: list each, marking categorical inputs and their reference level.
• ▸Independence check: could rows influence one another or share a source? Describe any hierarchy.
• ▸Candidate technique and reason: name the method and why it matches the outcome type and goal.
• ▸Assumptions to verify: list each (e.g., linearity and additivity) and the plot or test used.
• ▸Result of assumption checks: pass/fail and what you changed if it failed.
• ▸Alternative rejected and why: the other technique considered and the reason you set it aside.

1. 1Write down the outcome and the candidate inputs before touching the data. Tie each input to the evidence-based objective, as in step 1 of the inferential modeling process. In the promotion example the inputs are sales, customer_rate and performance, because management named those three factors.
2. 2Look at the raw rows first (head of the data), then run a full summary. Confirm the data 'looks as expected' before modeling. Check each field against what it should contain: the outcome is 0/1, sales are in thousands of dollars, customer ratings fall between 1 and 5, performance ratings run 1 to 4.
3. 3Count missing values per field. If the number is small, remove those observations, as the walkthrough does. If it is not small, stop and decide on a treatment deliberately. Do not let the model silently drop rows.
4. 4Check the outcome balance in the summary. In the promotion data about a third of individuals were promoted. You need this later to judge whether the model's output is sensible.
5. 5Judge each input's relevance by fitting the model and reading the coefficient significance, not by assumption. In the student-results example the first-year score (x1) turned out to play no significant role in the relationship. An input you expected to matter can drop out.
6. 6Decide how each input enters the model. Continuous measures (sales, customer_rate) go in as numbers. A field with a few discrete levels, such as the four performance ratings, needs an explicit choice between numeric and categorical. Any categorical input becomes dummy variables, with one level held out as the reference.
7. 7Before trusting any coefficient, test the inputs for high collinearity and multicollinearity (the book's step 4.5.4). Examine the correlation between each pair of inputs and look at the set as a whole. Remove or combine inputs that largely duplicate each other.
8. 8Keep a record of every removal, recode and exclusion so the model can be reproduced and explained to stakeholders.

You are the analyst on the salespeople data set. It has promoted (1 if promoted, 0 if not), sales (thousands of dollars), customer_rate (average customer satisfaction) and performance (most recent rating, 1 to 4). You print the first rows, for example promoted = 0, sales = 594, customer_rate = 3.94, performance = 2, and confirm they look as expected. Then you run summary(). It shows a small number of missing values, so you remove those observations. It shows about a third of individuals promoted. Sales range from $151k to $945k. Customer ratings span 1 to 5, as a satisfaction scale should. Performance shows four distinct ratings. That last point forces a decision: treat performance as a number, or convert it to dummy variables with a reference rating. After that you fit the model and check whether each input earns its place, as x1 failed to in the student-results example. Finally you check the inputs for collinearity before interpreting any coefficient.

• If the summary shows only a small number of missing values, remove those observations and note how many you removed. If the gaps are many or concentrated in one field, investigate why before removing anything.
• If an input is categorical (text or a handful of discrete levels), convert it to dummy variables and name the reference level. Do not feed it to the model as if it were a continuous number unless you have justified treating it that way.
• If a field's range or levels differ from what the data definition says (a rating outside 1 to 5, an unexpected number of performance levels), resolve the discrepancy before modeling.
• If an input is not significant in the fitted model, treat it as a candidate to drop, as with first-year scores. Do not keep it merely because it seemed relevant.
• If two or more inputs are highly collinear or multicollinear, remove or combine them before interpreting coefficients. Do not read the coefficients of a collinear set as independent effects.

• Skipping the raw look and the summary. The tell is a coefficient that makes no sense because a field held values outside its defined range or an unexpected number of levels.
• Deleting missing rows without counting them. The tell is that you cannot say how many observations were lost or whether the loss was small.
• Treating a multi-level categorical field as a plain number by default. The tell is a single coefficient for a field like performance rating, with no stated reasoning for that choice.
• Keeping an input because it is theoretically appealing after it shows no significant role. The tell is a cluttered model with insignificant terms you still defend.
• Interpreting coefficients before testing collinearity. The tell is unstable or implausible coefficients on inputs that clearly measure similar things.

• ▸Outcome and objective: state the outcome variable and the decision it informs.
• ▸Input name and definition: list each candidate input with its unit and meaning.
• ▸Expected range or levels: record what the data definition says the field should contain.
• ▸Observed range or levels: copy from summary() and flag any mismatch with the expected values.
• ▸Missing count and action: record the number of missing values per field and whether you removed, kept or investigated them.
• ▸Variable type and encoding: mark each input continuous, ordered or categorical. For categorical inputs, list the dummy variables and the reference level.
• ▸Relevance verdict: record the coefficient significance after fitting. Mark keep or drop with a one-line reason.
• ▸Collinearity check: list the input pairs or groups examined, the result, and whether you removed or combined any.
• ▸Final input set and change log: list the retained inputs and every removal or recode so the model can be reproduced.

1. 1Write the assumption list before you fit anything. Name the model family, then the assumptions that family carries. Linear regression carries linearity and additivity, constant error variance, normally distributed errors, and no high collinearity or multicollinearity. Proportional odds regression carries proportional odds. Cox regression carries proportional hazards. Every model also inherits the baseline assumption that observations are independent and identically distributed.
2. 2Run the independence check first, and run it from the data-generating story, not from a plot. Ask whether one person's outcome can be influenced by another's. In the book's salespeople data, one person's sales are assumed not to influence another's. If people share customers and each person's sales are a share of one customer's total, the assumption fails and you expect hierarchy in the data.
3. 3For linear regression, test the four assumptions in the order the book lists them (Section 4.5): linearity and additivity, constant error variance, normally distributed errors, then collinearity and multicollinearity among inputs. Record a pass, concern or fail for each one. Do not read coefficients or p-values until all four are recorded.
4. 4For a proportional odds model, test the assumption in two passes (Section 7.3). First, sight the coefficients of the stratified binomial models, meaning the separate binary splits of the ordered outcome. Check whether each input's coefficient is similar across the splits. Second, run the Brant-Wald test as the formal confirmation.
5. 5For a Cox proportional hazards model, check the proportional hazards assumption explicitly after fitting (Section 9.2.2). Do this before reporting any hazard-based conclusion.
6. 6Match each failure to the remedy the book points to. A failed proportional odds assumption sends you to the alternatives to proportional odds models (7.3.3). Hierarchical or non-independent data sends you to mixed models (Chapter 8). Survival data with unmodeled heterogeneity sends you to frailty models (9.3). A failed linearity assumption sends you to the extensions in 4.6: interactions and quadratic or higher-order polynomial terms.
7. 7Refit after any remedy and repeat the same checks on the new model. Keep the assumption log with the model so a reader can see what was tested, what failed and what you changed.

The book's salespeople data holds 351 salespeople, with promoted, sales, customer_rate and performance for each. Before modeling, the book tests the independence assumption in plain language. Here, one person's sales are not influenced by another's, so treating sales as independent and identically distributed looks reasonable. The book then gives a case where the assumption breaks. Suppose the salespeople worked together serving the same customers on the same products, and each person's sales were a proportion of the overall sales to that customer. The data would no longer be independent and identically distributed, and you would expect hierarchy in it. The prescribed response is to adjust the technique, which points to the mixed models of Chapter 8, rather than to run a standard model and trust its standard errors. The lesson is that an assumption check can be a question about how the data arose, answered before any fitting.

• If you can name a mechanism by which one observation influences another, such as shared customers, then treat the data as hierarchical and move to a mixed model rather than a standard regression.
• If the stratified binomial coefficients for an input differ materially across the splits, or the Brant-Wald test rejects, then drop the proportional odds model and choose from the alternatives in Section 7.3.3.
• If the proportional hazards check fails in a Cox model, then do not report a single hazard ratio as if it held over the whole period. Consider the alternatives the book offers, such as frailty models.
• If a linear model shows non-linear structure, then add an interaction or polynomial term from Section 4.6 and re-test all four assumptions on the new model.
• If any assumption is unresolved, then label the model's inferences provisional in the write-up. Do not present them as settled.

• Testing only the assumptions that are easy to run and skipping independence. The tell is a clean diagnostic report on data where people share customers, teams or other groupings.
• Running the formal test but never looking at the coefficients. The book pairs sighting the stratified binomial coefficients with the Brant-Wald test, and the tell is a bare p-value with no sense of how large the departure is.
• Checking assumptions once on a first model and not after changes. The tell is that adding an interaction or polynomial term, or removing inputs, is never followed by a re-check.
• Treating a failed assumption as a footnote and reporting the same coefficients. The tell is a write-up that says 'assumption violated' and then interprets the model as usual, without moving to an alternative model.
• Assuming the right model family guarantees valid assumptions, for example choosing proportional odds because the outcome is ordered. The tell is that ordinal outcome, Cox model or linear model is offered as the justification and no test is shown.

• ▸Model and outcome: name the model family and the outcome variable it predicts.
• ▸Independence story: state in one sentence whether any observation can influence another, and what hierarchy you checked for.
• ▸Assumptions to test: list every assumption the model family carries (linearity and additivity, constant error variance, normal errors, collinearity, proportional odds, proportional hazards).
• ▸Test or check used: for each assumption, name the specific diagnostic and the section or method it comes from.
• ▸Result: record pass, concern or fail per assumption, with the evidence in one line.
• ▸Input-level observations: note any single input whose behavior looks off, such as a coefficient that shifts across stratified binomial splits.
• ▸Remedy chosen: state the alternative model or term added, or write 'none' with a reason.
• ▸Re-test outcome: record the results after the remedy for every assumption again.
• ▸Confidence statement: write whether inferences are firm or provisional, and why.

1. 1Fit the full model first, then identify inputs with no significant effect on the outcome. These are the candidates to drop. The passages show this move in both the linear and logistic chapters.
2. 2Refit with only the significant inputs. Keep each iteration as a separate named model object (for example sales_model, simpler_model, full_model) so you can compare them side by side.
3. 3Compute AIC for every iteration with AIC(model_name). Compare them in one list. A lower AIC marks the more parsimonious model.
4. 4Choose the model with the lowest AIC, then check that its fit is nearly equivalent to the fuller model's. Parsimony means the same or very close to the same fit with fewer inputs.
5. 5Run the goodness-of-fit checks separately (for example the Hosmer-Lemeshow test for logistic models). AIC does not measure model quality or confidence, so the lowest-AIC model can still fit poorly.
6. 6Control complexity at the source. Resist adding inputs derived mathematically from variables already in the model, and stop well before inputs approach the number of observations.
7. 7If a large number of inputs is unavoidable, apply a coefficient regularization method such as LASSO regression to keep the model parsimonious.
8. 8Write one sentence stating what each retained input contributes to the primary inference objective. Any input that cannot be justified that way adds communication burden for no analytic benefit.

The book's promotion model is a binomial logistic regression with sales and customer rating as inputs. Three iterations are compared. The sales-only model has AIC 76.49508. The model with all inputs has AIC 76.37433. The model with sales and customer rating, the two significant inputs, has AIC 71.13145. The two-input model has the lowest AIC, so it is the most parsimonious. The full model, despite carrying more variables, scores barely better than sales alone, so the extra inputs add complexity without paying for it. Dropping them cuts the explanation burden and the exposure to measurement problems such as multicollinearity. The AIC does not show that the two-input model fits well in absolute terms. That claim rests on separate goodness-of-fit tests. In the book, almost all of those tests, Hosmer-Lemeshow first among them, suggest the model fits.

• If an input has no significant effect on the outcome and no role in the inference objective, then drop it and compare AIC before and after.
• If two models have nearly equal fit, then choose the one with fewer inputs and the lower AIC.
• If the lowest AIC belongs to a model you have not checked with goodness-of-fit tests, then do not call it good. AIC ranks candidates and does not certify quality.
• If the number of inputs is large and cannot be cut by judgment, then use regularization such as LASSO instead of hand-picking.
• If someone proposes a new input derived from existing ones, then require a clear inferential reason before adding it, because it raises complexity and multicollinearity risk.

• Reading a low AIC as proof of a good model. The tell: no goodness-of-fit test appears next to the AIC, and the 'best' model has never been checked for fit.
• Comparing AIC across models for different purposes or different data. The tell: the AIC values come from models that do not describe the same outcome.
• Padding the model with derived or speculative inputs to please a client or boss. The tell: inputs are mathematical transformations of existing variables, and the input count approaches the number of observations.
• Keeping every variable because the full model 'fits' slightly better. The tell: the AIC barely moves (76.37 vs 76.50 in the example) while the explanation grows longer.
• Ignoring measurement problems that come with many inputs. The tell: coefficients are hard to interpret, and multicollinearity shows up in a model with many correlated inputs.

• ▸Outcome and inference objective: state in one line what the model must explain.
• ▸Candidate model names: list each iteration (full, simplified, minimal).
• ▸Inputs per model: list the variables in each candidate.
• ▸Significance of each input: note which inputs show no significant effect on the outcome.
• ▸AIC per model: record the AIC() output for every candidate.
• ▸Lowest-AIC model: name the model with the lowest AIC.
• ▸Goodness-of-fit check: record the test used (for example Hosmer-Lemeshow) and the result for the chosen model.
• ▸Inputs dropped and why: justify each removal in relation to the inference objective.
• ▸Complexity guard: record the input count against observations, and whether regularization such as LASSO is needed.