{"text_format":"1","workbook":"xlsx","n_sheets":14,"sheets":["DS","Case1","Case2","Case3","Case4","Case5","1Definitions","2Features","3Framework","4EDA","5FE","6Model","7Workflow","8Production"],"not_rendered":{"charts":0,"images":0,"macros":0,"external_links":3,"defined_names":25,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"DS","index":0,"n_rows":0,"n_cols":0,"rows_kept":0,"cut":false,"hidden":false,"merged":[]}

{"sheet":"Case1","index":1,"n_rows":1,"n_cols":1,"rows_kept":1,"cut":false,"hidden":false,"merged":[]}
["Sygefravær"]

{"sheet":"Case2","index":2,"n_rows":1,"n_cols":1,"rows_kept":1,"cut":false,"hidden":false,"merged":[]}
["Sygefravær"]

{"sheet":"Case3","index":3,"n_rows":1,"n_cols":1,"rows_kept":1,"cut":false,"hidden":false,"merged":[]}
["Sygefravær"]

{"sheet":"Case4","index":4,"n_rows":1,"n_cols":1,"rows_kept":1,"cut":false,"hidden":false,"merged":[]}
["Sygefravær"]

{"sheet":"Case5","index":5,"n_rows":1,"n_cols":1,"rows_kept":1,"cut":false,"hidden":false,"merged":[]}
["Sygefravær"]

{"sheet":"1Definitions","index":6,"n_rows":145,"n_cols":1,"rows_kept":145,"cut":false,"hidden":false,"merged":[]}
["How to Write a Strong Data Science Definition for a Case"]
[]
["4-point summary of How to Write a Strong Data Science Definition:"]
[]
["1. Start with the Decision"]
["Begin by clearly defining the business decision to be improved, not the model or data. Focus on who decides, what decision is made, and when."]
[]
["2. Translate into an Analytical Question"]
["Convert the decision into a precise predictive or analytical question that specifies the outcome, unit of analysis, and time horizon."]
[]
["3. Define Output and Scope Clearly"]
["Specify the unit of analysis (e.g., customer, department) and ensure the model output is actionable (e.g., risk score, ranking) and aligned with real-world decisions."]
[]
["4. Include Constraints and Value"]
["A strong definition acknowledges practical constraints (data, interpretability, timing) and ends with a clear value hypothesis explaining the business impact."]
[]
["1. Start With the Decision, Not the Data"]
[]
["A good data science definition begins with the business decision that must be improved, not with models, algorithms, or datasets."]
["The purpose of data science in a case is decision support, not technical sophistication."]
[]
["Ask explicitly:"]
[]
["Who is making a decision?"]
["What decision needs to be improved?"]
["When does the decision need to be made?"]
[]
["Example"]
[]
["“The goal is to help operations managers decide which units to intervene in next month to reduce sickness absence.”"]
[]
["Avoid definitions such as:"]
[]
["“Build a machine learning model to predict absence.”"]
["This describes a method, not a decision."]
[]
[]
[]
["2. Translate the Decision Into a Predictive or Analytical Question"]
[]
["Once the decision is clear, translate it into a concrete analytical question."]
["Strong case definitions express the problem in outcome, unit, and time."]
[]
["A useful template is:"]
[]
["“Can we predict / estimate / explain [outcome] for [unit of analysis] over [time horizon], using available data?”"]
[]
["Example"]
[]
["“Can we predict the probability of high sickness absence at the department level over the next 4–8 weeks?”"]
[]
["This step is crucial: it bridges business language and data science language."]
[]
[]
[]
["3. Define the Unit of Analysis Precisely"]
[]
["Ambiguity around the unit of analysis is one of the most common case mistakes."]
[]
["Be explicit about whether the model operates at the level of:"]
[]
["individual"]
["team"]
["department"]
["asset"]
["customer"]
["transaction"]
[]
["Example"]
[]
["“The unit of analysis is departments, not individual employees, to align with how interventions are applied.”"]
[]
["This prevents misalignment between model output and real‑world action."]
[]
[]
[]
["4. State the Output in Actionable Terms"]
[]
["A data science definition should specify what the model produces in business‑usable terms."]
[]
["Examples of clear outputs:"]
[]
["risk score"]
["probability"]
["ranking"]
["classification (high / medium / low risk)"]
["forecast range"]
[]
["Example"]
[]
["“The model outputs a ranked list of departments by absence risk, enabling targeted intervention.”"]
[]
["Avoid vague outputs like “insights” or “patterns” unless they are directly tied to an action."]
[]
[]
[]
["5. Acknowledge Constraints and Trade‑offs"]
[]
["Strong case definitions demonstrate realism. Briefly acknowledge key constraints without over‑engineering."]
[]
["Typical constraints to mention:"]
[]
["data availability or quality"]
["interpretability requirements"]
["timing or latency"]
["governance or ethical considerations"]
[]
["Example"]
[]
["“Model interpretability is prioritized over marginal accuracy to ensure managerial trust and adoption.”"]
[]
["This signals judgment and maturity, especially in interviews."]
[]
[]
[]
["6. Conclude With the Value Hypothesis"]
[]
["End the definition by stating why solving this problem creates value."]
[]
["Example"]
[]
["“This enables earlier, more targeted interventions, potentially reducing short‑term sickness absence by 5–10%.”"]
[]
["Even if the number is illustrative, a directional impact hypothesis anchors the case in outcomes."]
[]
[]
[]
["Example: Full Data Science Definition (Case‑Ready)"]
[]
["The objective is to support operational managers in deciding where to intervene to reduce sickness absence. The task is to predict the risk of high sickness absence at the department level over the next 4–8 weeks, using historical HR and absence data. The model outputs a ranked risk score per department, enabling targeted preventive actions. Interpretability is prioritized to support managerial adoption. Solving this problem is expected to shift absence management from reactive reporting to proactive intervention, with material operational impact."]
[]
[]
[]
["Final Checklist (Before You Move On)"]
[]
["A strong data science definition answers all six:"]
[]
["1. What decision is being improved?"]
["2. What is the analytical question?"]
["3. What is the unit of analysis?"]
["4. What output will be produced?"]
["5. What constraints matter?"]
["6. Why does this create value?"]
[]
["If any are missing, the case definition is incomplete."]

{"sheet":"2Features","index":7,"n_rows":128,"n_cols":1,"rows_kept":128,"cut":false,"hidden":false,"merged":[]}
["Problem Features: Defining a Data Science Case"]
[]
["4-point summary of Problem Features in a Data Science Case:"]
[]
["1. Clear Aim / Target"]
["The problem must define a specific, measurable outcome tied to a real decision, including the time horizon and level of analysis (e.g., individual, department). The target should be concrete (e.g., probability, classification), not vague."]
[]
["2. Well-Defined Variables"]
["Clearly distinguish between target variables, predictor (feature) variables, and control/constraint variables. All variables should be available at decision time and, where needed, interpretable for stakeholders."]
[]
["3. Structured Inputs and Outputs"]
["Inputs are the data used by the model (clean, timely, aligned), while outputs are actionable results (e.g., risk scores, rankings, forecasts) that directly support decisions and are understandable to users."]
[]
["4. Alignment for Real Impact"]
["A strong case ensures alignment between target, variables, inputs, and outputs, making the problem robust, interpretable, and actionable—so the model leads to real-world decisions rather than abstract analysis."]
[]
["1. Aim / Target"]
[]
["The aim (or target) defines the objective of the analysis or model. It should be explicitly tied to a real‑world decision or outcome and framed in a way that is both measurable and actionable."]
[]
["A clear target answers:"]
[]
["What outcome are we trying to predict, estimate, classify, or explain?"]
["Over what time horizon does the outcome occur?"]
["At what level (individual, group, asset, transaction) is the outcome measured?"]
[]
["Best practice"]
[]
["Define the target as a concrete variable (e.g., probability, class label, forecast value)."]
["Avoid vague goals such as “gain insights” or “find patterns.”"]
["Ensure the target aligns with how decisions are actually made."]
[]
["Example"]
[]
["Predict the probability that a department will exceed a predefined sickness‑absence threshold in the next 4–8 weeks."]
[]
[]
[]
["2. Variables"]
[]
["Variables describe the measurable characteristics that relate the real‑world system to the target. They provide the explanatory and predictive structure of the problem."]
[]
["Variables can be grouped logically:"]
[]
["a. Target Variable"]
[]
["The outcome the model is trained to predict or explain."]
["Must be clearly defined, observable (historically), and consistently measured."]
[]
["b. Predictor (Independent) Variables"]
[]
["Features used to predict or explain the target."]
["May include:"]
["historical performance measures"]
["behavioral or operational indicators"]
["contextual or environmental factors"]
[]
["c. Control or Constraint Variables"]
[]
["Variables required for fairness, governance, or operational constraints."]
["Often used for filtering, grouping, or interpretation rather than prediction."]
[]
["Best practice"]
[]
["Variables should be available at decision time (no look‑ahead bias)."]
["Prefer interpretable variables when results must be explained to stakeholders."]
["Explicitly distinguish between what is predicted and what is used for prediction."]
[]
[]
[]
["3. Inputs and Outputs"]
[]
["The inputs and outputs translate the analytical problem into a format usable by both models and decision‑makers."]
[]
["Inputs"]
[]
["Inputs are the data elements consumed by the model at run time. They typically include:"]
[]
["structured datasets (tables, features, historical records)"]
["time‑indexed or cross‑sectional measurements"]
["engineered features derived from raw data"]
[]
["Inputs should be:"]
[]
["consistently available"]
["timely"]
["aligned with the unit of analysis"]
[]
["Example inputs"]
[]
["historical absence rates"]
["workforce composition metrics"]
["recent trend indicators"]
[]
[]
[]
["Outputs"]
[]
["Outputs are the model results delivered to users or systems. They must be designed for direct action, not just technical evaluation."]
[]
["Common output formats include:"]
[]
["probability or risk score"]
["classification (e.g., low / medium / high risk)"]
["ranked list"]
["numerical forecast with confidence bands"]
[]
["Best practice"]
[]
["Outputs should map directly to decisions or interventions."]
["The output format should be understandable by non‑technical stakeholders."]
["Precision and interpretability often matter more than marginal accuracy gains."]
[]
["Example output"]
[]
["A ranked list of departments by predicted absence risk, with an associated probability score."]
[]
[]
[]
["Summary"]
[]
["A well‑defined data science problem clearly states:"]
[]
["The aim/target: what outcome is being optimized or predicted"]
["The variables: how the system is represented analytically"]
["The inputs and outputs: how data flows into decisions"]
[]
["When these elements are explicit and aligned, the case becomes robust, interpretable, and actionable—maximizing the likelihood that data science leads to real impact rather than technical dead‑ends."]

{"sheet":"3Framework","index":8,"n_rows":137,"n_cols":1,"rows_kept":137,"cut":false,"hidden":false,"merged":[]}
["A Practical Data Science Framework"]
[]
["4-point summary of A Practical Data Science Framework:"]
[]
["1. Core Tools & Approach"]
["Python is the primary language, supported by Pandas (data handling) and NumPy/SciPy (math & statistics), with ML libraries used when appropriate. Model complexity should follow the problem—simple, interpretable models are often more effective."]
[]
["2. Clear Data Flow (Inputs → Outputs)"]
["A strong framework separates raw inputs, engineered features, and model outputs, ensuring data is aligned with decision timing and outputs are actionable, interpretable, and stable."]
[]
["3. Robust Validation"]
["Evaluation goes beyond accuracy, emphasizing out-of-sample testing, robustness, interpretability, and stability across conditions. In practice, calibration and ranking quality often matter more than predictive precision."]
[]
["4. Engineering & Guiding Principles"]
["Professional workflows require reproducible code, version control, and governance (fairness, explainability, auditability). The key principle: prioritize decision relevance, interpretability, and robustness over complexity or novelty."]
[]
["1. Core Tools: What to Use and Why"]
[]
["Python as the Primary Language"]
[]
["Python is the de‑facto standard for applied data science due to its balance of:"]
[]
["readability and speed of development,"]
["a mature scientific ecosystem,"]
["easy integration into production systems."]
[]
["Python is particularly strong for end‑to‑end workflows—from data preparation to modeling, validation, and deployment—making it suitable for both experimentation and operational use."]
[]
[]
[]
["Pandas: Data Manipulation and Feature Engineering"]
[]
["Pandas is the backbone of structured data work in Python."]
[]
["It is used to:"]
[]
["load and clean tabular data,"]
["manage time series and panel datasets,"]
["engineer features aligned with the unit of analysis,"]
["perform joins, aggregations, and transformations."]
[]
["Best practice is to:"]
[]
["treat Pandas as the single source of truth for analytical datasets,"]
["keep transformations transparent and reproducible,"]
["align feature construction strictly with decision timing (to avoid leakage)."]
[]
[]
[]
["SciPy / NumPy: Mathematical and Statistical Foundations"]
[]
["NumPy and SciPy support the numerical and statistical core of data science."]
[]
["They are used for:"]
[]
["numerical computation and linear algebra,"]
["probability distributions and sampling,"]
["hypothesis testing and statistical diagnostics,"]
["optimization and distance calculations."]
[]
["These libraries provide theoretical rigor, ensuring models rely on sound statistical foundations rather than ad‑hoc assumptions."]
[]
[]
[]
["Modeling & ML (Contextual, Not Default)"]
[]
["Additional libraries may include:"]
[]
["scikit‑learn for classical machine learning,"]
["statsmodels for statistical inference and interpretability,"]
["XGBoost / LightGBM for performance‑driven predictive tasks."]
[]
["Importantly, model complexity should follow the problem—not the other way around."]
["In many cases, simple, interpretable models outperform complex ones in real decisions."]
[]
[]
[]
["2. Inputs, Outputs, and Data Flow"]
[]
["A sound framework enforces a clear separation between:"]
[]
["raw inputs (available at decision time),"]
["engineered features (derived, documented, reproducible),"]
["model outputs (scores, probabilities, forecasts)."]
[]
["Outputs should always be:"]
[]
["aligned with the business decision,"]
["interpretable by end‑users,"]
["stable under small data variations."]
[]
[]
[]
["3. Validation and Evaluation"]
[]
["Evaluation goes beyond accuracy."]
[]
["Key considerations include:"]
[]
["out‑of‑sample and out‑of‑time validation,"]
["robustness across segments and regimes,"]
["interpretability and consistency,"]
["sensitivity to missing or noisy data."]
[]
["In decision‑oriented cases, calibration and ranking quality often matter more than raw predictive performance."]
[]
[]
[]
["4. Engineering, Reproducibility, and Governance"]
[]
["A professional data science framework treats code and results as production assets, not experiments."]
[]
["Best practices include:"]
[]
["modular, readable Python code,"]
["version‑controlled notebooks and scripts,"]
["reproducible environments,"]
["documented assumptions and data lineage."]
[]
["Governance considerations may include:"]
[]
["fairness and bias monitoring,"]
["model explainability,"]
["auditability and traceability,"]
["stakeholder trust and adoption."]
[]
[]
[]
["5. Guiding Principle"]
[]
["Tools enable insight—but structure, discipline, and judgment create impact."]
[]
["A strong data science framework prioritizes:"]
[]
["decision relevance over algorithmic novelty,"]
["interpretability over marginal accuracy gains,"]
["robustness over complexity."]

{"sheet":"4EDA","index":9,"n_rows":148,"n_cols":1,"rows_kept":148,"cut":false,"hidden":false,"merged":[]}
["Exploratory Data Analysis (EDA): Best Practice Framework"]
[]
["4-point summary of Exploratory Data Analysis (EDA):"]
[]
["1. Start With the Problem"]
["EDA should be driven by the business question and decision context, not by the data alone. Clearly define the target, unit of analysis, and time horizon to guide focused and relevant analysis."]
[]
["2. Validate Data Before Analysis"]
["First ensure data integrity and structure—check completeness, consistency, granularity, and timing. Reliable insights depend on trustworthy data."]
[]
["3. Focus on Target and Relationships"]
["Analyze the target variable in depth (distribution, stability, imbalance) and explore relationships between variables using correlations and visualizations to form hypotheses, not conclusions."]
[]
["4. Detect Risks and Inform Modeling"]
["Identify biases, leakage, and anomalies early, then translate findings into modeling decisions. EDA should end with clear implications, documented insights, and a better understanding of how to build robust models."]
[]
["1. Begin With the Question, Not the Dataset"]
[]
["EDA should be anchored in the problem definition, not in curiosity alone."]
[]
["Before analyzing any data, clarify:"]
[]
["the target variable and unit of analysis,"]
["the decision the analysis will support,"]
["the time horizon and decision timing."]
[]
["EDA questions should follow from this, e.g.:"]
[]
["Is the target well‑defined and observable?"]
["Do patterns align with how decisions are made?"]
[]
["This prevents unfocused analysis and premature conclusions."]
[]
[]
[]
["2. Assess Data Structure and Integrity First"]
[]
["The initial step in EDA is validating what the data actually represents."]
[]
["Key checks include:"]
[]
["dimensions and granularity,"]
["time coverage and frequency,"]
["missing values and duplicates,"]
["consistency across sources."]
[]
["At this stage, the goal is trustworthiness, not insight."]
["If the data structure is flawed, later findings will be unreliable regardless of model choice."]
[]
[]
[]
["3. Understand the Target Variable Deeply"]
[]
["The target variable deserves disproportionate attention during EDA."]
[]
["Best practice involves:"]
[]
["inspecting distribution, skewness, and outliers,"]
["checking stability over time and across segments,"]
["validating alignment with business logic."]
[]
["Questions to answer:"]
[]
["Is the target rare or imbalanced?"]
["Does it drift over time?"]
["Is it noisy, aggregated, or lagged?"]
[]
["If the target is unstable or mis‑specified, model performance will be misleading."]
[]
[]
[]
["4. Explore Relationships, Not Just Summaries"]
[]
["Descriptive statistics are necessary but insufficient."]
["EDA should focus on relationships, not isolated variables."]
[]
["Key analyses include:"]
[]
["correlations and conditional patterns,"]
["group‑level comparisons,"]
["trend and seasonality inspection,"]
["interactions between features."]
[]
["Visualizations are preferred where possible, as they reveal:"]
[]
["non‑linearities,"]
["structural breaks,"]
["regime behavior."]
[]
["EDA should start forming hypotheses, not conclusions."]
[]
[]
[]
["5. Detect Leakage, Bias, and Artefacts Early"]
[]
["One of EDA’s most important roles is risk detection."]
[]
["Explicitly check for:"]
[]
["look‑ahead bias (future information in predictors),"]
["point‑in‑time inconsistencies,"]
["survivorship or selection bias,"]
["proxy variables that leak the target."]
[]
["These issues are often invisible during modeling but fatal in deployment."]
["Finding them during EDA saves significant downstream cost."]
[]
[]
[]
["6. Translate Findings Into Modeling Implications"]
[]
["EDA should always end with clear implications, not just observations."]
[]
["For example:"]
[]
["heavy skew → transformation or robust models,"]
["structural breaks → segmented modeling,"]
["strong collinearity → feature selection,"]
["unstable patterns → simpler, more robust approaches."]
[]
["A strong EDA naturally informs:"]
[]
["feature engineering choices,"]
["model complexity,"]
["validation strategy."]
[]
[]
[]
["7. Document Insights, Assumptions, and Open Questions"]
[]
["EDA is an analytical asset and should be documented accordingly."]
[]
["Effective documentation includes:"]
[]
["key findings and visual evidence,"]
["assumptions made about the data,"]
["known limitations and uncertainties,"]
["hypotheses to be tested in modeling."]
[]
["This ensures continuity, transparency, and explainability—especially in team or client settings."]
[]
[]
[]
["Guiding Principle"]
[]
["EDA is not about finding answers—it is about understanding the problem well enough to ask the right modeling questions."]
[]
["Strong EDA reduces model risk, increases interpretability, and ensures that analytical effort translates into real‑world impact."]

{"sheet":"5FE","index":10,"n_rows":140,"n_cols":1,"rows_kept":140,"cut":false,"hidden":false,"merged":[]}
["Feature Engineering: Best Practice Framework"]
[]
["4-point summary of Feature Engineering:"]
[]
["1. Align With Decision Context"]
["Features should be designed based on the decision, unit of analysis, and available information at prediction time, ensuring they reflect real-world signals and avoid data leakage."]
[]
["2. Respect Time and Causality"]
["All features must use only past data, with proper lags and rolling windows. Maintaining correct time structure is essential to avoid unrealistic results and model failure in production."]
[]
["3. Use Domain Knowledge and Simplicity"]
["Strong features encode expert knowledge (e.g., ratios, thresholds, interactions) and favor simple, interpretable transformations, which improve robustness, explainability, and generalization."]
[]
["4. Evaluate, Handle Imperfections, and Document"]
["Feature engineering is iterative—evaluate feature stability and contribution, handle missing data and scaling carefully, and document logic and assumptions to ensure reproducibility and long-term reliability."]
[]
["Feature engineering is the discipline of translating raw data into meaningful representations that enable robust, interpretable, and actionable models. In practice, feature engineering often has a larger impact on model performance and reliability than algorithm choice."]
[]
["1. Start From the Decision Context"]
[]
["Feature engineering should be driven by how predictions will be used, not by data availability alone."]
[]
["Before creating features, clarify:"]
[]
["the unit of analysis (e.g., individual, department, asset),"]
["the prediction horizon,"]
["the information available at decision time."]
[]
["This ensures features reflect real‑world signals, not artifacts."]
[]
["Best practice:"]
["Only engineer features that would be known at the moment a decision is made. This prevents leakage and false performance gains."]
[]
[]
[]
["2. Respect Time and Causality"]
[]
["Time awareness is critical in feature engineering."]
[]
["Key principles include:"]
[]
["strict separation of past and future information,"]
["consistent lag definitions,"]
["rolling or window‑based aggregates aligned with the prediction horizon."]
[]
["Common feature types:"]
[]
["lagged values (e.g., last 4 weeks),"]
["trends and deltas,"]
["rolling means, volatility, or counts."]
[]
["Failure to respect time structure is one of the most frequent causes of model breakdown in production."]
[]
[]
[]
["3. Encode Domain Knowledge Explicitly"]
[]
["The most valuable features usually reflect domain understanding, not statistical novelty."]
[]
["Effective feature engineering translates expert intuition into data:"]
[]
["ratios and normalizations (per unit, per capita),"]
["threshold indicators aligned with business rules,"]
["interaction terms capturing known mechanisms."]
[]
["Features that “make sense” to domain stakeholders are:"]
[]
["easier to validate,"]
["easier to explain,"]
["more resilient to regime changes."]
[]
[]
[]
["4. Prefer Simple, Interpretable Transformations"]
[]
["Complex transformations are not inherently better."]
[]
["Strong feature engineering favors:"]
[]
["monotonic transformations (log, winsorization),"]
["aggregations over arbitrary non‑linear mappings,"]
["stable encodings over high‑variance constructs."]
[]
["Simple features:"]
[]
["reduce overfitting,"]
["increase robustness,"]
["improve trust and adoption."]
[]
["Feature complexity should increase only when justified by clear signal."]
[]
[]
[]
["5. Handle Scale, Sparsity, and Missingness Deliberately"]
[]
["Feature engineering must address data imperfections explicitly."]
[]
["Best practices include:"]
[]
["consistent scaling where required (especially for distance‑based models),"]
["meaningful handling of missing values (informative vs accidental),"]
["indicators for missingness when it carries signal."]
[]
["Missing values are often information, not just noise, and should be treated accordingly."]
[]
[]
[]
["6. Evaluate Features, Not Just Models"]
[]
["Feature engineering is iterative and evidence‑based."]
[]
["Good practice involves:"]
[]
["inspecting individual feature distributions,"]
["testing stability over time and segments,"]
["measuring incremental contribution (e.g., ablation)."]
[]
["Features that improve in‑sample performance but degrade stability or interpretability should be removed, even if accuracy drops slightly."]
[]
[]
[]
["7. Document Assumptions and Feature Logic"]
[]
["Feature engineering decisions must be transparent."]
[]
["Effective documentation includes:"]
[]
["how each feature is constructed,"]
["why it should be predictive,"]
["known limitations or edge cases."]
[]
["This supports reproducibility, governance, and hand‑over—and prevents “feature debt” in long‑running systems."]
[]
[]
[]
["Guiding Principle"]
[]
["Feature engineering is where data science becomes applied understanding—not just computation."]
[]
["Strong feature engineering aligns data, time, and domain knowledge to produce models that perform well and survive real‑world use."]

{"sheet":"6Model","index":11,"n_rows":163,"n_cols":1,"rows_kept":163,"cut":false,"hidden":false,"merged":[]}
["Data Science Model Selection: A Practical Framework"]
[]
["4-point summary of Data Science Model Selection:"]
[]
["1. Match Model Type to Problem Context"]
["Choose models based on data type and decision needs:"]
[]
["Classical ML for structured data (default choice)"]
["Deep learning for large-scale, unstructured data"]
["Reinforcement learning for sequential decision problems"]
["LLMs for language-based tasks and human interaction"]
[]
["2. Understand Trade-offs of Each Approach"]
["Simpler models (classical ML) are more interpretable, stable, and easier to deploy, while complex models (deep learning, RL, LLMs) offer flexibility but require more data, computation, and governance."]
[]
["3. Follow Core Selection Principles"]
["Start with a simple baseline, ensure outputs align with decisions, respect constraints (interpretability, latency, governance), and prioritize robustness over marginal accuracy gains."]
[]
["4. Focus on Real-World Impact"]
["The best model is the simplest one that reliably solves the decision problem, balancing data, business needs, and deployment constraints to ensure lasting, practical value."]
[]
["Model selection is the process of aligning analytical capability with decision needs, data constraints, and operational reality. Strong model choices favor fitness for purpose over novelty or complexity."]
[]
["1. Machine Learning (Classical / Supervised & Unsupervised)"]
[]
["Typical methods"]
["Linear/logistic regression, tree‑based models, random forests, gradient boosting, clustering."]
[]
["When to use"]
[]
["Structured, tabular data"]
["Clear target variable"]
["Limited or moderate data volume"]
["Need for interpretability and governance"]
[]
["Strengths"]
[]
["High performance on structured data"]
["Fast to train and validate"]
["Interpretable and explainable"]
["Easier to deploy and monitor"]
[]
["Limitations"]
[]
["Requires explicit feature engineering"]
["Less effective on raw unstructured data"]
[]
["Best practice"]
[]
["Treat classical ML as the default starting point. More complex methods should justify themselves against it."]
[]
[]
[]
["2. Deep Learning"]
[]
["Typical methods"]
["Neural networks, CNNs, RNNs, Transformers (non‑LLM use cases)."]
[]
["When to use"]
[]
["Large volumes of data"]
["Unstructured inputs (images, audio, text, complex sequences)"]
["Non‑linear relationships difficult to encode manually"]
[]
["Strengths"]
[]
["Automatic feature learning"]
["Strong performance on perception and sequence tasks"]
["Scales well with data volume"]
[]
["Limitations"]
[]
["Data‑hungry"]
["Harder to interpret and explain"]
["Higher computational cost"]
["More fragile under distribution shifts"]
[]
["Best practice"]
[]
["Use deep learning only when data scale and problem structure demand it—not as a general replacement for classical ML."]
[]
[]
[]
["3. Reinforcement Learning (RL)"]
[]
["Typical methods"]
["Q‑learning, policy gradients, actor‑critic methods."]
[]
["When to use"]
[]
["Sequential decision‑making problems"]
["Actions influence future states"]
["Feedback is delayed"]
["Environment can be simulated or safely explored"]
[]
["Strengths"]
[]
["Optimizes policies, not just predictions"]
["Naturally handles trade‑offs over time"]
["Well suited for control and optimization problems"]
[]
["Limitations"]
[]
["Complex to design and evaluate"]
["Requires careful reward design"]
["Risky in real‑world experimentation"]
["Hard to debug and explain"]
[]
["Best practice"]
[]
["Apply RL only when the problem is inherently sequential and exploratory control is feasible. Avoid RL when a predictive model plus rules suffice."]
[]
[]
[]
["4. Large Language Models (LLMs)"]
[]
["Typical uses"]
["Text understanding, generation, classification, summarization, reasoning support."]
[]
["When to use"]
[]
["Natural language is core to the problem"]
["Tasks require flexible understanding or generation"]
["Human‑in‑the‑loop workflows"]
["Low tolerance for rigid rule‑based systems"]
[]
["Strengths"]
[]
["Strong generalization across language tasks"]
["Minimal feature engineering"]
["Rapid time‑to‑value for text‑heavy problems"]
[]
["Limitations"]
[]
["Probabilistic and non‑deterministic outputs"]
["Limited grounding in factual correctness"]
["Governance, privacy, and cost concerns"]
["Difficult to validate traditionally"]
[]
["Best practice"]
[]
["Treat LLMs as assistive reasoning or interface layers, not as ground‑truth decision engines for high‑stakes outcomes."]
[]
[]
[]
["5. Cross‑Cutting Model Selection Principles"]
[]
["Regardless of model class, best practice includes:"]
[]
["Start simple: establish a strong baseline before increasing complexity"]
["Align with decisions: outputs must map directly to actions"]
["Respect constraints: interpretability, latency, governance often dominate accuracy"]
["Prefer robustness over marginal gains: stability beats peak performance"]
["Validate realistically: out‑of‑sample, out‑of‑time, and stress testing"]
["Document assumptions: model intent must remain clear over time"]
[]
[]
[]
["Guiding Principle"]
[]
["The best model is not the most advanced—it is the simplest one that solves the decision problem reliably."]
[]
["Successful model selection balances data, decisions, and deployment, ensuring that analytical insight translates into durable real‑world impact."]

{"sheet":"7Workflow","index":12,"n_rows":114,"n_cols":1,"rows_kept":114,"cut":false,"hidden":false,"merged":[]}
["Data Science Workflow: A Structured, Production‑Ready Approach"]
[]
["4-point summary of Data Science Workflow:"]
[]
["1. Structured Pipelines"]
["Organize the workflow into clear, modular stages (data ingestion → preprocessing → modeling → evaluation), ensuring each step is reproducible, consistent, and aligned with real production data flow."]
[]
["2. Meaningful Testing"]
["Evaluate models using relevant, decision-focused tests (out-of-sample, out-of-time, stress tests, calibration), focusing on trustworthiness and robustness, not just accuracy."]
[]
["3. Iterative Improvement"]
["Treat the workflow as a recursive process, where insights from testing, EDA, and stakeholders continuously refine features, models, and outputs through controlled, hypothesis-driven iterations."]
[]
["4. Actionable Recommendations"]
["The end goal is decision-ready outputs (rankings, risk tiers, thresholds) that are interpretable, stable, and directly linked to real-world actions—ensuring models create practical value."]
[]
["A strong data science workflow ensures that analytical solutions are reliable, scalable, and decision‑driven. Rather than a linear process, effective workflows are modular, testable, and iterative, enabling continuous improvement and controlled complexity."]
[]
["1. Pipelining: Structuring the End‑to‑End Flow"]
[]
["Pipelining refers to organizing the data science process into clear, sequential, and reusable stages. A well‑designed pipeline creates consistency across experimentation, validation, and production."]
[]
["Typical pipeline stages include:"]
[]
["data ingestion and validation"]
["preprocessing and feature engineering"]
["model training and inference"]
["evaluation and output generation"]
[]
["Best practices:"]
[]
["each pipeline step should have a single, well‑defined responsibility"]
["transformations should be deterministic and reproducible"]
["pipelines should reflect the real production data flow, not just notebooks"]
[]
["Pipelines reduce human error, improve repeatability, and allow teams to scale models from prototypes to deployable systems without rewriting logic."]
[]
[]
[]
["2. Test Selection: Measuring What Actually Matters"]
[]
["Testing is not only about model accuracy—it is about decision quality and robustness. Selecting the right tests ensures models generalize beyond historical data and remain reliable under real‑world conditions."]
[]
["Key dimensions of test selection:"]
[]
["temporal validation (out‑of‑time testing for future realism)"]
["out‑of‑sample validation (generalization to unseen data)"]
["stress and sensitivity tests (performance under noise or missing data)"]
["calibration and ranking tests (especially for risk or prioritization models)"]
[]
["Best practices:"]
[]
["match test metrics to the intended use of predictions"]
["avoid selecting tests purely for technical elegance"]
["prefer fewer, meaningful tests over many loosely interpreted metrics"]
[]
["Testing should answer one question: Can this model be trusted when it informs real decisions?"]
[]
[]
[]
["3. Recursive and Iterative Improvement"]
[]
["Modern data science workflows are inherently recursive. Insights from later stages should feed back into earlier ones."]
[]
["Examples of healthy recursion include:"]
[]
["EDA insights refining feature engineering"]
["test failures triggering pipeline adjustments"]
["stakeholder feedback reshaping output format"]
[]
["This recursive loop enables:"]
[]
["gradual refinement rather than over‑engineering"]
["early detection of weaknesses"]
["continuous learning without destabilizing systems"]
[]
["Best practice:"]
[]
["Treat iteration as controlled learning cycles, not trial‑and‑error experimentation."]
[]
["Each iteration should have a clear hypothesis, measurable impact, and documented outcome."]
[]
[]
[]
["4. Recommendations: From Models to Decisions"]
[]
["The final—and most critical—stage of the workflow is recommendation design. Models create value only when their outputs translate directly into action."]
[]
["Effective recommendations:"]
[]
["are aligned with how decisions are made in practice"]
["reflect uncertainty clearly (e.g., confidence, risk bands)"]
["are interpretable by non‑technical stakeholders"]
[]
["Typical recommendation formats:"]
[]
["ranked lists"]
["risk tiers"]
["thresholds triggering intervention"]
["scenario‑based guidance"]
[]
["Best practices:"]
[]
["design outputs before finalizing models"]
["prefer robust, interpretable recommendations over opaque optimization"]
["ensure recommendations remain stable and predictable"]
[]
[]
[]
["Guiding Principle"]
[]
["A data science workflow succeeds when structure, testing, iteration, and recommendations reinforce each other."]
[]
["Well‑designed workflows turn data science from ad‑hoc analysis into a repeatable, decision‑centric capability—capable of delivering sustained impact at scale."]

{"sheet":"8Production","index":13,"n_rows":107,"n_cols":1,"rows_kept":107,"cut":false,"hidden":false,"merged":[]}
["Data Science Model Maintenance: Ensuring Sustained Impact"]
[]
["4-point summary of Data Science Model Maintenance:"]
[]
["1. Continuous Evaluation"]
["Regularly assess whether the model still meets its objectives using out-of-time testing, stability checks, and decision-relevant metrics, ensuring it continues to deliver business value."]
[]
["2. Ongoing Monitoring"]
["Track data, predictions, and system performance in real time to detect drift or anomalies early, distinguishing between normal variation and meaningful structural changes."]
[]
["3. Root-Cause Diagnosis"]
["When performance declines, analyze data shifts, feature issues, or behavioral changes to understand why, using cohort analysis and full pipeline tracing."]
[]
["4. Controlled Retraining"]
["Update models through careful, evidence-based retraining, using validated data and full re-evaluation to maintain consistency, reliability, and long-term impact."]
[]
["Building a model is not the end of a data science project—maintaining model performance over time is what determines long‑term value. Effective model maintenance ensures that analytical systems remain accurate, reliable, and trusted as data, behavior, and environments evolve."]
[]
["1. Evaluation: Regularly Measuring Performance"]
[]
["Evaluation assesses whether a model continues to perform as intended relative to its original objectives."]
[]
["Key aspects of evaluation include:"]
[]
["predictive performance (accuracy, calibration, ranking quality),"]
["stability across segments and time,"]
["alignment with business outcomes and decisions."]
[]
["Best practices:"]
[]
["evaluate models out‑of‑time, not just on recent data,"]
["compare against meaningful baselines (e.g. simple rules or prior models),"]
["focus on metrics that reflect decision impact, not technical optimization."]
[]
["Evaluation answers the question:"]
["Is the model still delivering the value it was designed to provide?"]
[]
[]
[]
["2. Monitoring: Detecting Change in Real Time"]
[]
["Monitoring is the continuous tracking of model behavior and data characteristics once a model is deployed."]
[]
["Effective monitoring typically covers:"]
[]
["input data distributions,"]
["prediction distributions and volumes,"]
["outcome rates and feedback signals,"]
["latency, availability, and system health."]
[]
["Best practices:"]
[]
["monitor both data drift (changes in inputs) and prediction drift,"]
["define alert thresholds that are meaningful, not overly sensitive,"]
["distinguish between noise and structural change."]
[]
["Monitoring allows teams to detect issues early—before performance degradation translates into poor decisions."]
[]
[]
[]
["3. Diagnosis: Understanding Why Performance Changes"]
[]
["When evaluation or monitoring reveals degradation, diagnosis identifies the underlying causes."]
[]
["Common diagnostic questions:"]
[]
["Has the data generating process changed?"]
["Has user behavior or policy shifted?"]
["Are key features missing, delayed, or corrupted?"]
["Is the model over‑sensitive to certain segments?"]
[]
["Best practices:"]
[]
["analyze performance by cohort and time slice,"]
["trace issues through the full pipeline (data → features → model),"]
["revisit assumptions made during EDA and feature engineering."]
[]
["Diagnosis transforms signals into understanding, enabling targeted corrective action rather than reactive fixes."]
[]
[]
[]
["4. Retraining: Updating Models Safely and Deliberately"]
[]
["Retraining updates model parameters or structure in response to diagnosed changes."]
[]
["Retraining strategies range from:"]
[]
["scheduled periodic retraining,"]
["event‑triggered retraining (after confirmed drift),"]
["full model redesign when assumptions no longer hold."]
[]
["Best practices:"]
[]
["retrain only with validated, high‑quality data,"]
["preserve comparability with previous model versions,"]
["re‑run full evaluation and testing before redeployment,"]
["document changes and rationale carefully."]
[]
["Retraining should be controlled and evidence‑based, not automatic or purely time‑driven."]
[]
[]
[]
["Guiding Principle"]
[]
["Model maintenance is not about constant change—it is about controlled adaptation."]
[]
["A well‑maintained data science system combines disciplined evaluation, continuous monitoring, rigorous diagnosis, and deliberate retraining to ensure sustained performance, stakeholder trust, and real‑world impact."]