← All Insights
Recommendation Systems · Decision Systems · System Design · Tier B

Hard Constraints Belong in the Architecture, Not Preferences

In recommendation systems, hard constraints should not be treated like preferences. Some signals define whether an option should be considered at all.

Feasible Set Two-Stage Ranking Eligibility Delivery Radius
View on LinkedIn →
Hard constraints belong in the architecture - a two-stage recommendation flow that first defines the feasible set of eligible vendors inside the service boundary, then ranks eligible options by past behaviour, local popularity, and relevant offer

TL;DR: In restaurant recommendation, delivery distance was a physical boundary, not a preference: a restaurant outside the delivery area was unavailable, not less preferred. The system first defines the feasible set of eligible vendors, then ranks options inside that set — constraints belong in the architecture, preferences belong in the ranking model.

The Problem

In a restaurant recommendation project, delivery distance was not simply one feature among many. It was a physical boundary.

A restaurant outside the delivery area was not "less preferred". It was unavailable. That changed the architecture.

A common approach would build a global recommendation model and include distance as one input feature. But that allows the model to treat distance as a trade-off: "This restaurant is far, but perhaps the customer will still like it." For a hard delivery-radius constraint, that is the wrong question. The recommendation problem does not exist outside the eligible area.

The Approach

So the system was structured in two stages.

1. Define the feasible set first

Which vendors can realistically serve this customer? Outside the service area is not eligible.

2. Rank options inside that set

Which eligible vendors are most relevant based on behavioural and operational signals?

The ranking layer could then use previous ordering patterns, customer segment, vendor popularity within a local zone, delivery proximity, and service availability. But geography was not merely another preference signal — it defined the candidate set.

Outcome

This distinction applies far beyond food delivery: products not available in a customer's country, offers a customer is not eligible for, financial products outside risk-policy limits, inventory unavailable in a fulfilment region, and appointments outside a provider's service area.

Some signals are preferences. Others are conditions that define whether an option should be considered at all.

Key Takeaway

Design insight: Constraints belong in the architecture; preferences belong in the ranking model. Delivery radius, eligibility rules, and risk-policy limits are not trade-off features a recommender should learn to negotiate — they define the feasible set. Filter what is possible first, then rank what is preferable, because no ranking model should be asked to learn a non-negotiable rule.

Related

A Reranker Cannot Rank What It Never Receives →Not Every Analytics Question Is About What Drives the Outcome →A Predictive Model Is Not a Decision System →Route Structurally Inactive Series Before Forecasting →Should This Be a Rule, a Model, or an LLM? →When the Label Does Not Exist →

← PreviousAll Insights Next →Preprocessing Is Vocabulary Design for Noisy NLP Text

FAQ

Why should hard constraints not be treated like preferences in a recommendation system?

A hard constraint such as delivery distance is a physical boundary, not a trade-off: a restaurant outside the delivery area is unavailable, not less preferred. If it is fed to a ranking model as one feature, the model can wrongly trade it against preference, so the constraint must be applied in the architecture before ranking.

What is a two-stage recommendation architecture?

First define the feasible set - which vendors can realistically serve this customer - then rank options inside that set by behavioural and operational signals such as past ordering, customer segment, local popularity, delivery proximity, and service availability.

Comments

Machine Learning Feature Engineering MLForecast Time Series Decomposition Forecasting LightGBM XGBoost Catboost Clustering Segmentation NLP LLMs Web App R Markdown SQL Oracle DB SAS-Guide SAS E-Miner Dataiku BigQuery GCP Python R CRISP-DM Hypothesis Testing ANOVA Data Analytics Dimensionality Reduction Recommendation System Network Analysis Geospace Analysis Spatial Data Embedding Sampling Techniques Decision Rules Data Storytelling CVM Churn Fraud Detection Sentiment Analysis Topic Modeling IBM Watson PowerBI Looker Studio VBA Statistical Learning Ensemble Modeling Stacking Cross-Validation Profiling ABT Construction Plumber Tidyverse Shiny Prophet Deep Learning Scikit-Learn JSON SAS Programming Git VS Code CSS Styling Automated Reporting Outlier Detection Temporal Clustering Startup Survival Pre-Valuation Modeling K-Means Decision Trees Data Science Predictive Modeling SVM LDA Text Classification Weight Prediction Pattern Recognition Real-Time Detection Community Detection Pipeline Automation Data Quality Checks Data Reliability Specification Mapping Business Strategy Marketing Campaigns Try & Buy Frameworks KPI Dashboards Network Quality Sales Analytics Mentoring Statistics Lecturer Remote Work Hybrid Work Consulting Contract Full-Time Freelance Sofrecom Orange Group Tunisia Telecom Kiota Intelligence VC Analytics Series A Prediction Pre-Valuation Modeling Production ML Applied AI Prompt Engineering Business Forecasting Decision Systems Graph Analytics Household Detection Multi-SIM Detection FTTH Forecasting Audit Extraction Infrastructure Classification Pydantic GPT-4 OpenAI API Base64 Classification Zindi Codementor LAAS-CNRS ESSAI MIT xPRO Tunisia ML Competition Cell Tower Analysis Uber Logistics Uber Cape Town Necessary Condition Analysis Behavioral Signals Spike Smoothing Observation Unit Design Dendrogram Ward Clustering VIF Target Encoding Machine Learning Feature Engineering MLForecast Time Series Decomposition Forecasting LightGBM XGBoost Catboost Clustering Segmentation NLP LLMs Web App R Markdown SQL Oracle DB SAS-Guide SAS E-Miner Dataiku BigQuery GCP Python R CRISP-DM Hypothesis Testing ANOVA Data Analytics Dimensionality Reduction Recommendation System Network Analysis Geospace Analysis Spatial Data Embedding Sampling Techniques Decision Rules Data Storytelling CVM Churn Fraud Detection Sentiment Analysis Topic Modeling IBM Watson PowerBI Looker Studio VBA Statistical Learning Ensemble Modeling Stacking Cross-Validation Profiling ABT Construction Plumber Tidyverse Shiny Prophet Deep Learning Scikit-Learn JSON SAS Programming Git VS Code CSS Styling Automated Reporting Outlier Detection Temporal Clustering Startup Survival Pre-Valuation Modeling K-Means Decision Trees Data Science Predictive Modeling SVM LDA Text Classification Weight Prediction Pattern Recognition Real-Time Detection Community Detection Pipeline Automation Data Quality Checks Data Reliability Specification Mapping Business Strategy Marketing Campaigns Try & Buy Frameworks KPI Dashboards Network Quality Sales Analytics Mentoring Statistics Lecturer Remote Work Hybrid Work Consulting Contract Full-Time Freelance Sofrecom Orange Group Tunisia Telecom Kiota Intelligence VC Analytics Series A Prediction Pre-Valuation Modeling Production ML Applied AI Prompt Engineering Business Forecasting Decision Systems Graph Analytics Household Detection Multi-SIM Detection FTTH Forecasting Audit Extraction Infrastructure Classification Pydantic GPT-4 OpenAI API Base64 Classification Zindi Codementor LAAS-CNRS ESSAI MIT xPRO Tunisia ML Competition Cell Tower Analysis Uber Logistics Uber Cape Town Necessary Condition Analysis Behavioral Signals Spike Smoothing Observation Unit Design Dendrogram Ward Clustering VIF Target Encoding