What's Ushasvi Building? — Causal Couture, Phase 3
Phase 3 of Causal Couture adds a decision layer that scores a small business's health and recommends inventory actions in plain English, built on the shop's own data.
Small business owners generate plenty of their own data: sales records, inventory counts, social posts, web analytics. What they usually don't have is a system that reads all of it together and tells them, in plain language, what's actually working. Causal Couture is a Humanitarians AI Fellow project built to be exactly that system, and Phase 3 is where it starts making real recommendations rather than just organizing data.
Building in order: why phase matters
Ushasvi Rachel Peeka built Causal Couture in a specific sequence, and that order is part of what makes Phase 3 credible. Phase one was the skeleton: a back-end API, a front-end interface, and CSV upload with schema validation, checking required columns, date formats, and SKU IDs before a single row of data gets accepted into the system. Phase two was the pipeline: cleaning and standardizing uploaded files, computing rolling sales averages and spike detection, and combining everything into one unified date-by-SKU view of the whole business. Only with that foundation in place does Phase three become possible.
Phase 3: the decision layer
Phase three is described as the part that thinks. A starter analysis engine reads the unified dataset and generates four categories of signals: demand, inventory, engagement, and conversion. Those signals roll up into a single overall business health score, along with an initial inventory recommendation, giving the shop owner one scorecard for the whole business rather than four disconnected metrics to interpret separately.
Ushasvi is explicit about where this sits on the road to a fully causal system, labeling the current scoring as heuristic starter scores, ahead of full causal effect modeling. That's a meaningful distinction: the system organizes and weighs signals now, but it isn't yet proving that one thing causes another, and the project's own documentation says so directly rather than overstating what Phase 3 delivers.
Why plain English matters here
A health score without an explanation is just a number, so the system also generates a plain-English interpretation of its own results, translating analytical output into business-friendly language instead of returning raw figures. That's a deliberate design choice aimed at who this tool is actually for: shop owners, not data analysts. The interface itself went through a redesign this phase too, integrating the complete workflow from file upload through scorecard generation to the written explanation into one polished front end.
The unedited report
The fellow's own five-minute report walks through a live demo of the working prototype: uploading each data file (sales, inventory, social, and web), building the unified dataset, selecting it, naming it, and running the starter analysis to generate both the scorecard and its plain-English explanation. Running the same dataset twice in the demo doesn't show much variation, since it's the same underlying values, but the workflow itself, upload to unified dataset to scorecard to explanation, runs end-to-end locally, with all of the implementation pushed to GitHub.
Feedback: the score has to show its work
The project review that follows the report is direct about what's working and what isn't yet. Three phases in, this is a genuine end-to-end prototype, and the discipline of validating schemas before ingestion is called out specifically as the unglamorous choice that prevents problems later. Date-by-SKU is affirmed as the right level of granularity for this kind of analysis, and the plain-English layer is credited as evidence the system knows who its actual audience is.
The pushback is equally direct: today, causal is a promise, not yet a property. The engine currently produces heuristic signals folded into a composite score, and while the interface is honest on-screen about that limitation, a health score still has to show its work. Which signals moved the score, weighted how, based on what. The suggested test for the next demo is bringing two genuinely contrasting datasets, since running the same file twice can't demonstrate that the explanation layer is actually earning its keep.
What's next
Three concrete next steps come out of the review. First, pick a single, narrow causal question, such as whether a social media spike actually causes an increase in add-to-cart activity, or merely tends to happen alongside it, and answer that one question properly before generalizing the approach to the rest of the system. Second, start scenario simulation with one specific decision: the reorder quantity for the shop's top-selling SKU. Third, define a validation story by back-testing recommendations against the six months of data already collected, so the system's output can be measured against outcomes rather than just judged by feel.
Key takeaways
- Causal Couture reads a small business's own sales, inventory, social, and web data to generate a single business health score.
- The system was built in a deliberate order: schema-validated ingestion first, a unified date-by-SKU dataset second, and the decision layer (scoring and recommendations) third.
- Current scoring is explicitly heuristic, not yet based on full causal effect modeling, and the interface says so on screen.
- A plain-English interpretation layer translates analytical output into business language instead of raw numbers.
- Next steps include testing one narrow causal question properly, simulating a single reorder-quantity scenario, and back-testing recommendations against six months of historical data.
Try it yourself
The video closes with a prompt you can run on your own numbers: gather six months of your shop's sales, inventory, social, and web data as CSVs, build one unified daily view per product, score the business's health, then ask which signals merely correlate with sales versus which plausibly cause them, and what you'd need to check before trusting any recommendation. That question, correlation versus causation, is the whole reason Causal Couture exists, and it's a useful exercise for any small business owner working with Humanitarians AI Fellows on similar data problems.
Chapters
- 0:00Fellows — Ushasvi Rachel Peeka
- 0:22The foundation: schema-validated ingestion, one date-by-SKU view
- 0:45The decision layer: signals, health score, recommendation
- 1:07Plain English, and what's next
- 1:30Ushasvi's Phase 3 report (unedited)
- 6:46Professor Bear's notes: feedback
- 7:26Professor Bear's notes: next steps
- 7:53Your turn — run the causal question on your own data
- 8:21Humanitarians AI
Full transcript(auto-generated, with timestamps)
Fellows — Ushasvi Rachel Peeka
[0:00]This is Liam for Humanitarians AI, and this is Fellows, the series where our fellows show their work. I wondered what fellow Ushasvi Rachel Pika has been building lately. The answer is Causal Couture, a system that reads a small shop's own data, sales, inventory, social, web, and works out what is actually driving the business. This week it grew its decision layer. Here is the shape of it, and then the report in her own words. First, the foundation,
The foundation: schema-validated ingestion, one date-by-SKU view
[0:23]Because she built this in order. Phase one was the skeleton, a back-end API, a front-end and CSV upload with schema validation, required columns, date formats, SKU ID, all checked before a single row gets in. Phase two was the pipeline, files cleaned and standardized, rolling sales averages, spike detection, and everything combined into one unified date by SKU view of the whole business.
The decision layer: signals, health score, recommendation
[0:45]Phase three is the part that thinks. A starter analysis engine reads that unified data set and generates demand, inventory, engagement, and conversion signals, then rolls them into an overall business health score and an initial inventory recommendation. One scorecard for the whole shop. And notice [clears throat] her own label on it, heuristic starter scores before full causal effect modeling. She knows exactly where this is on the road. And
Plain English, and what's next
[1:07]Because a score without a sentence is just a number, she added a plain English interpretation. The system explains its results in business language, not analyst language. Next on her list, replace the causal heuristics with real causal modeling, add scenario simulations for inventory decisions, and head toward the conversational interface that is the end goal. Here is Ushasvi's phase three report, about five minutes unedited. >> A weekly progress update for Causal
Ushasvi's Phase 3 report (unedited)
[1:31]Couture. Um this week I focused on primarily building the first version of the phase three, which is the decision layer, um which is very much the core analytical part of the project. Um I started by adding a or implementing a starter analysis engine that generates demand, um inventory, um right here. Uh, engine that demands inventory, engagement, and conversion signals from the process business data. And it sort of >> [snorts] >> creates a unified data set from all of those, um, that combines, uh, all of these signals into an overall business health score, um, and provides a really good initial inventory recommendation. Um, this is the scorecard. Um, I also added a plain English interpretation right here, uh, which would help the system translate the analytical results into a very business-friendly insight, instead of just returning the numbers, which it does over here. Um, and just to have a little of a background of what the project was like since the beginning, um, reminiscing the phase one and phase two. Uh,
For phase one, I built the local project foundation, including the back-end API, the front-end interface, the data schemes, the CSV upload with schema validation, uh, which helped the system, um, validate required columns, date formats, SKUIDs, and the different numeric fields, uh, before proceeding to any upload data. Uh, for phase two, I implemented the ingestion and pre-processing pipeline, uploaded files that I cleaned, standardized, and set and transformed into processing data sets. Um, I also added basic feature engineering features, uh, including rolling sales averages, sales spike detection, etc., uh, to make the data set much easier. And then I finally built a unified, um, data by SKU data set that combines, uh, all the different features, uh, like combined sales, um, inventory, social media, and web analytics into a single analytical view for a downstream reasoning. I also spent quite a bit of time improving the user experience. Um the palette or the theme is just something that I was tweaking around with, which I'm definitely going to um change. Uh but yeah,
Uh coming back to the user experience, I spent time by redesigning the front end into a very polished interface and then integrating the complete workflow from the file upload to the score card generation right here um and the business explanation. The current prototype is now working pretty well um into end locally and I've pushed all the implementation to my GitHub on the repo. Um next week I will be focusing on strengthening the causal reasoning layer by replacing some of the causal heuristic >> [snorts] >> um logic with a much more robust causal modeling, uh which will definitely improve the feature engineering adding different scenario visualizations uh for future inventory decisions and moving closer to the conversational chat experience, which is quite uh the end goal of what Causal Discovery is. I'm going to run through with the demo for just a second so you would understand what this works like. So you're just going to go ahead and play upload different um files. For example, I'm going to upload the sales
File and it's going to process the data set and then I'm going to go ahead and upload every single one of these files. >> Now that all our files have been um uploaded, your it's just going to create you can go ahead and uh select the specific file that you want um to create a uniform file. But, these are all the files that I have used before. And then you're just going to go ahead and build the unified data set, which is going to give you the unified data set. And then you're just going to select the unified data set, um put the file name, and run the starter analysis. And then it's just going to give you a scorecard, and then it's going to run the explanation. Um since it's the same data set, it's not giving me much of a difference, but it is the same value and results overall. Um and yeah, this concludes my work for the week, and I will update back next week. Thank you.
Professor Bear's notes: feedback
[6:46]>> Professor Bear's notes the feedback first. Three phases in this is a real end-to-end prototype. Upload to unified data set to scorecard to explanation, and the discipline shows. Validating schemas before ingestion is the unglamorous choice that saves you later, and date by SKU is the right grain for this problem. The plain English layer says you know who this is for. Now the push. Today, causal is a promise, not yet a property. The engine is heuristic signals in a composite score, and to your credit, the interface says so on screen. But, a health score has to show its work. Which signals moved it? Weighted how? Based on what? In next demo, bring two contrasting data sets. Running the same file twice can't show the explanation layer earning its keep.
Professor Bear's notes: next steps
[7:26]The next steps. One, pick a single narrow causal question. Does a social spike cause add to carts, or just travel with them? And answer it properly before generalizing the layer. Two, start scenario simulation with one decision, the reorder quantity on your top SKU. Three, define the validation story. Back test recommendations against the 6 months of data you already have. So, it works as a measurement, not a feeling. Ashasvi Rachel Pika, Humanitarians AI Fellow. The code is on her GitHub. Your turn. Paste this into Claude. Here
Your turn — run the causal question on your own data
[7:54]Are 6 months of my shop sales, inventory, social, and web numbers as CSVs. Build one unified daily view per product, score the health of the business, then tell me which signals merely correlate with sales and which plausibly cause them, and what you would check before trusting any recommendation. That last clause is the whole game. Causal Couture exists because correlation is cheap and decisions are not. Run it on your own numbers and watch where the explanation gets uncomfortable. That's where the real causal work starts.
Humanitarians AI
[8:21]What's Ashasvi building? Causal Couture. This has been Fellows from Humanitarians AI, Liam for Humanitarians AI.
