Materiel
A working model of a hardware company, from purchase order to a unit in the field, and four questions it can answer.
Every company that builds physical things asks the same few questions, usually in a meeting and usually without a good answer. If this supplier stopped shipping tomorrow, what couldn't we build? Which part will stop the line next? How many of the units we've delivered work right now? And when we changed something, did it help?
The facts needed to answer them exist. They are split across a purchasing system, a production system, field service records and a quality database, each with its own names for the same things. Most of the work is joining them: deciding what a part, a supplier, a build and a fielded unit are, how they relate, and writing that down as code that can be tested.
This project does that for a fictional manufacturer of three defense products, and builds the answers on top. Everything below is computed from the model and is interactive.
The company and its data are synthetic, generated with realistic mechanics: late parts stall builds, bad lots fail inspection, fielded units break and wait on spares. The pipeline is real and runs end to end in CI. Synthetic data has one advantage, which section four uses: I know the true answer, so you can check whether the method finds it.
1. If a supplier stopped shipping tomorrow
Each supplier on the left connects to the parts it makes, and each part to the products that use it. Select a supplier to trace what depends on it. Its sole-source parts are the ones that matter: if nobody else makes a part, the line stops until a new source is qualified, which takes at least one lead time.
The view's real lesson is concentration. of 60 suppliers are the only source of at least one flight-critical part, and those parts sit in every product. Second sources for those parts would be cheap insurance, and the readout above shows which ones.
2. Which parts will stop the line
Risk here is likelihood times impact. Likelihood blends a forecast (how late the part's suppliers have run, spread across however many there are) with history (the share of builds the part has already blocked). Impact is whether the part is flight-critical, how many products use it, and how long it takes to replace.
The top of the list is what you'd expect once you see it and would struggle to name without it. Below the top handful, risk falls off quickly; most parts are dual-sourced, short lead time, or both.
3. Is the fleet ready
Fielded units fail at rates set by their design, but how long they stay down is mostly a question of how fast spares arrive, which makes it a supplier question again.
4. Did the supplier program work?
In July 2025 the company enrolled its twenty worst-quality suppliers in a development program: on-site engineers, process audits, tighter first-article inspection. A year later, someone asks whether it worked. There are three common ways to answer, and two of them are wrong.
The obvious comparison, enrolled suppliers against everyone else after launch, says enrolled suppliers reject parts as everyone else. That is true and beside the point: they were enrolled because they were the worst. Comparing enrolled suppliers before and after does better, but it credits the program with everything else that changed over the same months, and something did. As production ramped, every supplier's defect rate crept up.
Difference-in-differences handles both problems. It compares the change for enrolled suppliers with the change for everyone else: supplier fixed effects absorb each supplier's baseline, and month fixed effects absorb whatever hit all of them at once. Rejections are counts out of parts inspected, so the model is a Poisson regression with inspected units as the exposure, and standard errors are clustered by supplier.
The event study on the right is the check that matters. Before enrollment, the enrolled suppliers move with everyone else and the estimates sit on zero. After, the gap opens over about three months and holds. A placebo that pretends the program began in January 2025 finds nothing.
I planted a 35% reduction at full strength. The estimate is , with a 95% interval of ; the average sits a little below 35% because the effect takes three months to arrive. The naive comparison gets the sign wrong, and the before-and-after comparison misses about a third of the effect.
How it's built
The pipeline is small enough to read in an afternoon, and laid out the way it would be with real systems behind it.
- Storage. Apache Iceberg tables. Each load is a new snapshot, so last week's extract stays queryable when a number moves and someone asks why.
- Modeling. SQLMesh, 22 models in three layers. The middle layer is the part that matters: one definition of each thing the company talks about, with its relationships and derived facts (is this order late, is this unit down). Everything above reads from it.
- Checks. 33 audits run on every build, from uniqueness of keys to "a receipt can't precede its order." Unit tests pin the logic that is easiest to get wrong: lateness on orders that haven't arrived, and repair intervals clipped to month boundaries.
- Analysis. statsmodels. The estimator has its own tests, which fail if it stops recovering the planted effect or starts finding one in the placebo.
- Orchestration. One Flyte workflow, run in CI every week so drift in a dependency shows up before a reader finds it.
The supplier exposure model shows the style. The business rule is in the code, in a form someone in operations can check:
/* Builds that cannot start within one replacement lead time if this supply stops.
Sole-source parts stop the line outright; split parts lose this supplier's share. */
pr.planned_monthly_rate * s.nominal_lead_time_days / 30.0
* CASE WHEN s.is_sole_source THEN 1.0 ELSE s.allocation_share END AS builds_at_riskWhat's simplified
- The data is synthetic. The generator is in the repository, with every mechanism it simulates written out.
- Exposure counts lead time but not inventory. With on-hand stock and safety stock, "builds at risk" becomes days of cover, which is the number a planner actually wants.
- The risk weights are judgment. With real history I would fit them against which parts actually blocked builds the following quarter, and check that a score of 60 means what it says.
- The program launched on one date for everyone. A staggered rollout would need an estimator built for staggered timing, such as Callaway and Sant'Anna's, because the two-way fixed effects model above can be badly biased in that setting.
If you work on problems like this, I'd like to hear from you: zainhameed99@gmail.com.