Essay · 2026-08-08
A Better Starting Point for a Human Decision
How our team built a machine-learning shortlist to give leadership a better starting point when assigning Project Coordinators.
6 minute read
- machine-learning
- mentorship
- applied-ai
- leadership
Cotton Holdings brings together several businesses that support complex projects and work environments. Potential work starts as a lead. It may become an opportunity and, eventually, a project.
As the work moves forward, leadership assigns a Project Coordinator to help organize the job. The decision may depend on the type of work, the customer, the location, the team's capacity, and each coordinator's experience. Systems hold some of that information. The rest comes from leadership's experience and knowledge of the team.
This summer, my colleague Nidhi Kundalia saw an opportunity to improve that process with technology. I shaped the technical approach with our two AI and machine-learning interns, Moses Fanadzhyan and Vaibav Subramanian, and mentored their day-to-day work.
The proof of concept brings the available information together, ranks eligible coordinators, and explains why each person appears on the list. It gives leadership a place to start without making the assignment for them.
The data only made sense with business context
Moses and Vaibav first had to understand how new work moves from a lead to an opportunity or project, and when leadership assigns a Project Coordinator. Every business handles that process differently. Those details changed how we read the data.
A field that looks obvious in a table may mean something else in practice. A project date may not be the date someone made the assignment. Current workload does not tell us what someone's workload was when an older project was assigned. Location may matter for one coordinator and barely matter for another who works nationally.
My job was to connect data from the warehouse and enterprise resource planning (ERP) system to the real business process. I explained the fields and kept asking a simple question: would we have known this when the original decision was made?
Moses and Vaibav asked why each field mattered, how the team used it, and what the model might learn from it. Their questions changed some of our assumptions.
A past assignment only tells us who was chosen
The historical data told us who leadership chose. It could not tell us who else might have been a good fit or capture every conversation behind the decision. The model could learn from the recorded choice, but we could not treat it as the only correct answer.
That led us to build a ranking model. Instead of naming one person as the answer, it returned a short list of eligible coordinators for leadership to consider.
More data did not mean a better model
We tested model inputs based on location, market, workload, tenure, and assignment history. I also expected factors like margin and cost to help because they made sense to me from a business perspective.
The results did not always agree with our assumptions. Some inputs helped, some did very little, and others made the ranking worse. We evaluated each version on later assignments the model had not seen and removed what did not help, even when the business reasoning sounded good.
We also had to remove information that would not have existed when leadership made the assignment. An input can look predictive in a historical test simply because it contains future information. It would not work on a new lead.
I enjoyed this part of the project. The experiments made all three of us question what we thought we knew and go back to the data.
What Moses and Vaibav built
Moses focused on modeling and evaluation. He expanded the input experiments and added SHAP analysis so we could see what influenced the results. He also tested later data and new leads, and tried a nearest-neighbor approach for coordinators with limited assignment history.
Vaibav focused on the data and recommendation workflow. He reworked the SQL and data preparation, added an input for new hires, and connected model explanations to the output. His work helped turn raw rankings into something a person could use.
They worked through tests, pull-request feedback, changing assumptions, and experiments that we eventually removed.
The technical approach
The stack was Python, Databricks, XGBoost, Prefect, MLflow, and Pydantic. The tools were straightforward. The modeling decisions were harder.
| Decision | Why we made it |
|---|---|
| Rank candidates instead of choosing one person | The useful output was a shortlist, not an automatic assignment. |
| Use XGBoost instead of an LLM | This was a structured-data problem. XGBoost produced ranking scores, and plain-language reasons explained the recommendations. |
| Build model inputs as of the assignment date | The model should only see information that would have been available when the decision was made. |
| Train separate models for restoration and construction | The two types of work had different assignment patterns and performed better with different model configurations. |
| Use Prefect and MLflow for the model lifecycle | Prefect orchestrated training. MLflow stored the models, evaluation metrics, and approved versions. |
Pydantic defined and validated the structure of the lead data, candidate inputs, training metadata, and recommendation output. The model scores were ranking signals, not probabilities.
At a high level, the workflow looked like this:
Training
Historical assignments
-> reconstruct who was eligible at the time
-> build inputs using only information known then
-> train a separate ranker for each type of work
-> evaluate them against later months
-> approve both models for use only when the pair passes review
Recommendation
New lead + current eligible coordinators
-> build the same candidate inputs
-> load the approved model for that type of work
-> rank the top three options
-> add plain-language reasons and current workload context
-> return the shortlist for a person to review
How we worked together
I like to give people room to work. I set the direction, explained the business and data context, reviewed the code, and stayed available when they needed me.
Moses and Vaibav took that direction and ran with it. They figured out what information was missing, met with people who understood the process, and worked through the problem together. They were independent and persistent, and they knew when to ask for more context.
Leading the project expanded my machine-learning experience. I spent more time on ranking models, testing them with only the information available at the time, and checking whether the right person was in the candidate pool. I also learned more about recommending coordinators with limited assignment history and explaining the results clearly.
I later used those lessons to turn the proof of concept into a workflow designed for production. It runs internally, but it has not been released to business users.
I am proud of what Moses and Vaibav built and how well they worked together. They wanted to understand the problem and build something useful. I helped them make sense of the business and the data, and they pushed me to question my assumptions and learn more about the modeling. That back-and-forth was my favorite part of the summer.