Sprint 4 Standup: The Last Mile Before an End-to-End Pipeline

Six days into Sprint 4, we pulled everyone into a standup to check the one thing that actually matters this sprint: can a CSV go in one end and a diagnostic report come out the other? Short answer — almost. Every layer has real, working code now; what’s missing is the wiring between them. This post walks through who did what, and exactly which three connectors stand between us and a genuine end-to-end demo.

Quick Poll Before You Read On

If you had to bet on where the pipeline breaks first when we wire it up live, where would you put your money?

• Data → Model, because production_features.csv still has no automatic handoff into the Model Layer
• Model → Dashboard, because run_model_batch(csv_path) doesn’t exist yet
• Report → Dashboard, because it all depends on a local Ollama instance being up

Keep your guess in mind — the gap table below has the honest answer, and it’s not a single point of failure.

Data Layer — Lei Pei, Qiuting Fu

The big news: scripts 00–41 of the feature engineering pipeline are complete, and the first full production run has been validated. Lei implemented the entire chain — input contract validation, atomic features, engine-start context, window features, calibrated features, and the production feature assembler that emits the versioned 46-column contract — then ran it across the full dataset (81 trips, 118 segments, ~250k samples) and confirmed an exact match against feature_schema.v1 before signing off.

production_features.csv has now shipped as the first official Data Layer release for the Model Layer to consume, alongside a manifest for checksum verification.

Qiuting spent the sprint on the harder-to-see-but-just-as-important half of the same problem: formalising why the three proxy failures are diagnostically sound. That meant grounding proxy definitions in SAE standards, the Bosch Automotive Handbook, ISO 26262, and CARB OBD-II requirements, and updating the project README to match the finalised proxy architecture.

Lei has also started building the online proxy-decision engine — rule-state, event-evidence, duration-evidence, and decision builders that will turn frozen calibration + production features into runtime fault verdicts.

Shared blocker: proxy thresholds are currently validated only against healthy data. Neither Lei’s decision engine nor Qiuting’s regulatory grounding can be fully backed by real detection-rate evidence until fault-injection experiments land — that work is next.

Model Layer — Ray Wang, Lucca Zhou

Ray had to absorb a rough dependency shock this sprint: the Data Layer’s upstream restructuring (new calibration registry, new feature manifest, renumbered pipeline scripts) meant the Model Layer’s existing interface broke overnight. Ray rewrote validation, the detector, output validation, and the full fixture/test suite end-to-end to match, and confirmed the pipeline runs clean on fixture data — no small feat mid-sprint.

Alongside that, Ray fine-tuned the forecasting model and ran it against zero-shot on healthy data:

Comparison	Result
Zero-shot vs. fine-tuned MAE	~3.9% improvement
Self-set “clear win” bar	5%
Verdict	Modest evidence, not yet a clear win

Logged honestly rather than oversold — a result worth citing later once retuning closes the gap.

Lucca, meanwhile, made the call to drop the team’s own failure-type research doc and adopt the Data Layer’s proxy_support.md as the single source of truth for proxy-failure definitions — one fewer document to keep in sync, one more reason cross-layer docs need to converge early. Lucca also shipped the remaining synthetic fault-injection scenarios (frozen intake-air-temp, frozen MAP, idle-speed) and built the full risk-score-history pipeline: persistence, validation, a batch-sweep mode, and dashboard-friendly error output, all recorded in the shared interface doc.

flowchart LR
    A["Data Layer restructure<br/>new calibration + manifest"] -->|breaks interface| B["Ray: rewrite<br/>validation + detector + tests"]
    C["Lucca: risk-score-history<br/>+ batch-sweep pipeline"] --> D["Pending-type scoring<br/>(blocked on Ray)"]
    D -.->|unblocks| E["Interface status flip:<br/>Pending → Confirmed"]

Blocked pair: the two remaining anomaly types can’t flip from “Pending” to “Confirmed” in the interface until pending-type scoring lands — which is also what’s holding up precision/recall and threshold calibration.

Report Layer & Dashboard — Charlotte Yu, Jintong He

This was a heavy build sprint. On the Report Layer side, the full generation pipeline is in — RAG context injection, the three-layer Granite prompt chain, retry handling, JSON parse failure recovery, and a graceful fallback path for when Ollama/Granite isn’t reachable.

On the Dashboard, the headline change is structural: what used to be one large single-file app is now split into proper modules — app entry, overview page, detail page, theme, UI components, and data store. That refactor made room for everything else that shipped alongside it:

Shipped:

• CSV upload UI with required-column and minimum-row validation, plus a two-state landing → dashboard flow
• Batch Model Layer output support — parsing {summary, windows} and routing risk_history through to the Report Layer and trend chart
• Alignment with the current 5-anomaly-type INTERFACE.md contract, across both runtime code and tests
• UI polish from demo feedback — upload layout, clearer missing-data states, mock/placeholder notices

Still open:

• Upload-page polish, round two
• Wiring in run_model_batch(csv_path) once it exists upstream
• Making incomplete-data / low-confidence states visually distinct from “low risk” (easy to misread as good news if we don’t get this right)

The Background chapter’s first draft is also done — one report section off the list.

What Each Layer Is Still Missing

This is the table the standup kept coming back to. It’s the honest gap list — not what’s broken, but what simply doesn’t exist yet:

Layer	Missing piece	Severity
Dashboard	run_model_batch() doesn’t exist — upload shows “not available”	Critical
Dashboard	Batch result is a single summary, can’t populate 5 real cards	Major
Data Layer	No callable entrypoint: raw CSV → production_features.csv path	Critical
Data Layer	Feature path isn’t auto-passed into the Model Layer	Major
Data Layer	Proxy failure stages 50–70 have no Python implementation yet	Minor
Model Layer	run_model_batch(csv_path) doesn’t exist	Critical
Model Layer	Batch output covers 1 summary, not all 5 anomaly types	Major
Model Layer	estimated_cycles_to_failure / estimated_failure_probability always null	Minor
Report Layer	Whether risk_history is really wired through needs confirming	TBD
Report Layer	Ollama dependency means empty reports when it’s down (known, has fallback)	Major

So — if you guessed “Data → Model” or “Model → Dashboard” in the poll above, you were half right: both entrypoints (run_model_batch in the Model Layer, and the raw-CSV-in entrypoint in the Data Layer) are the two Critical gaps standing between us and a real demo. Neither is a mystery to solve; they’re just not built yet.

The Sprint 4 Contract

To keep Sprint 4 from becoming “improve everything a little,” we scoped it down hard. Here’s what has to be true by the end of it, and what’s explicitly out of scope until Sprint 5:

flowchart TD
    subgraph S4["Sprint 4 — must work"]
    U["Dashboard CSV upload"] --> DL["Data Layer entrypoint"]
    DL --> ML["Model Layer run_model()"]
    ML --> RL["Report Layer"]
    RL --> DASH["Dashboard: cooling_degradation report"]
    end
    S4 -.-> S5["Sprint 5 — same vehicle type,\nall 6 anomaly types"]
    S5 -.-> S6["Sprint 6+ — cross-vehicle support\n(Future Work in report + viva)"]

Sprint 4 constraints, on purpose:

• Only cooling_degradation needs to work end-to-end
• Local Ollama must be running
• Input CSV must match KIT column naming
• At least 15 minutes of driving data (≥ 700 rows)

Anything about a second vehicle type, all six anomaly types, or cross-model REFERENCE_RANGES recalibration is deliberately Sprint 5 and Sprint 6+ territory — and it needs to be framed that way in the group report and the viva, as future work rather than an oversight.

Report and Viva — Must Land Before Sprint 4 Ends

Group	Report section	Viva file	Owners
Data Layer	2.1 Data Layer background	docs/viva/data_challenge.md	Lei Pei, Qiuting Fu
Model Layer	2.2 Time-Series Anomaly Detection	docs/viva/model_challenge.md	Ray Wang, Lucca Zhou
Report Layer	2.3 LLMs and RAG for Diagnostics	docs/viva/report_challenge.md	Charlotte Yu, Jintong He

Charlotte’s 2.3 draft is already done — a small head start heading into the busier back half of the sprint.

Looking ahead: Sprint 5’s target is the full Design and Implementation chapter. The advice from this standup — start drafting now, even a rough outline counts — is worth taking seriously; it’s exactly what made this sprint’s Background chapter easier to land on time.

What’s Next

The picture across the team is consistent: every layer has real, tested code, but the connective tissue — two callable entrypoints and one auto-passed file path — is what stands between us and watching an actual CSV turn into an actual diagnostic report on the dashboard. That’s the whole of what’s left for the “must complete” list this sprint. Once run_model_batch() exists and the Data Layer hands off its output path automatically, we get to run the demo we’ve been describing in every retro since Sprint 2.