# From failed feature test to cross-team fix in minutes Category: Case Study Published: October 2026 Read time: 12 min read URL: /resources/thermal-case-study-cross-team-fix A cabin-comfort promise that had already passed quietly broke after a later fan calibration. Vinci re-checked the new version, found the cause, and reached every owner in about ten minutes. --- Case Study # From failed feature test to cross-team fix in minutes A cabin-comfort promise that had already passed quietly broke after a later calibration change. Vinci re-checked the new version, found the cause, and reached every owner in about minutes, while still in development stage. **Disclaimer.** This case study is a composite scenario, indirectly derived from our team's experience on automotive development programmes. It does not describe any specific company, vehicle or project. Names, requirements, figures and timelines are illustrative. ## Summary Cars are built by many specialist teams. A feature's requirements are signed off and tested once, on an early software version, and marked as passed. After that they are rarely checked again. Later versions keep changing underneath them, so a feature that passed can quietly stop working, and nobody finds out until integration, months later. In this case study, the cabin-comfort requirements had already been signed off and passed on an earlier version. A later change by another team broke them. Vinci re-checked them against the new version, found the cause and reached every responsible engineer in about ten minutes, by one person, while still in development. The usual path is a failure at integration months later, followed by days of meetings across four teams. ## The system in plain terms An electric car's thermal system has one job that the driver notices in cabin and the second that they don't in the powertrain. It keeps the cabin comfortable, and it keeps the battery and motor at safe temperatures. Several engineering teams build it together, and each team owns one part. ### Three subsystems behind one feature - **Cabin Climate** is the air handler behind the dashboard: blower, vents and flaps. Its software decides how cold the air leaving the cooling coil should be. - **Refrigerant** is the air-conditioning loop: the compressor and the cooling coil that actually makes the air cold. Its software runs the compressor and stops the coil from icing up. - **PT Cooling** (powertrain cooling) is the radiator and coolant loop that keep the battery and motor cool. - **Thermal Feature** isn't hardware. It is the promise to the driver, such as "the cabin stays within 1.5 °C of the temperature you set", and it is only kept if all three subsystems work together. ## Where the subsystems touch The teams work separately, but their parts are physically connected: - **The cooling coil** sits between Cabin and Refrigerant. Cabin asks for an air temperature; Refrigerant runs the compressor to deliver it. - **The radiator fan** at the front of the car is shared by Refrigerant and PT Cooling. It runs at whichever team's request is higher. A change that looks local to one team can therefore change how another team's part behaves. Each team builds and tests its own box. The driver experiences the whole, and the two shared parts are where one team's change reaches another. One driver promise rests on three teams’ parts — with two shared interfaces between them. ## How requirements are layered Each promise to the driver is broken down, level by level, into instructions precise enough for one team to build. A change at the bottom can break a promise at the top. Level | In plain words | Example from this case Business goal | Why the product exists | Comfortable in any climate Feature promise | What the driver gets | Cabin stays within 1.5 °C of the setting Team requirement | What each team must deliver | The AC coil must never ice up Software and tuning | The exact numbers in the code | AC coil target never below 3 °C ## Who owns what In Vinci the four projects are linked as one workspace, with 90 links running from the feature requirements down into the subsystems. Project | Owner | Holds Thermal Feature | Kartikeya Gupta | L1–L3 requirements and the feature tests Cabin Climate | Neha Kulkarni | Cabin requirements, software and calibration (L4–L6) Refrigerant | Aaryansh Bansal | Refrigerant requirements, software and calibration (L4–L6) PT Cooling | Ishaan Jain | PT Cooling requirements, software and calibration (L4–L6) ## What went wrong The cabin-comfort feature had already passed its tests on an earlier version, so it was considered done. Then, in a later version, the PT Cooling team made a minor calibration change: they turned down the radiator fan to save energy and noise. Their own tests passed. But the same fan also cools the air conditioning, so the change reached the Refrigerant team and then the Cabin team, and on hot days the driver ends up in a cabin that won't stay cool. Four steps from a small fan-map change to a cabin that will not stay cool. Each team's own checks still passed, and the feature's earlier pass was still on record, so no one could see the problem. ## Why this goes unnoticed today The biggest issue is not the change itself. It is that requirements and their tests are not re-verified as the product evolves. This is one of the biggest flaws of the V-Cycle: requirements once tested are signed off instead of being monitored continuously. The software industry solved "breaking what already works" with CI/CD pipelines. Hardware companies still do not have that luxury. Continuous monitoring is expected of systems engineers who are already working on the next programme's feature set. Robust active coverage has become close to impossible under the sheer complexity of both the systems and the market. A requirement that passed on Thermal Feature version 1 keeps its "passed" status while the downstream systems keep evolving from v1 to v10 until integration begins. The failure stays hidden until the whole car is assembled and tested at integration, often months later. By then the change that caused it is long forgotten. Checked once, failing months later — the verification gap between sign-off and integration. Source: germanautopreneur.com — The CARIAD Insider Report (and What We Can Learn from It). This is the state of the industry: everyone moves from product validation straight to fighting integration fires. VinciStack closes this gap: every new version is checked against the signed-off requirements, so a broken promise shows up the day it breaks. ## Workflow without Vinci The feature is checked once, and the problem surfaces months later. - **The feature passes** its tests on an early version and is signed off. Its "passed" status never expires. - **Downstream evolved versions change** the parts underneath it, including PT Cooling's fan calibration. Nobody re-runs the feature tests. - **Months later, at integration,** the assembled car fails: the cabin won't hold its temperature. - **Four teams** each check their own part, and each part looks fine. Days of meetings follow until someone remembers PT Cooling's calibration change. - **The fix lands at integration,** the second most expensive point to change anything. This is where delays are introduced. The issue first lands with the product owners, then pulls in system engineers from every subsystem, then software and finally calibration engineers. Each new person must align with everyone already involved, so the conversations grow much faster than the headcount. Just agreeing on the cause can take weeks, and the fix itself then needs the same people to re-align on a new calibration. Every new group of engineers multiplies the conversations. ## Workflow with Vinci Requirements are re-checked with every new version, so the problem surfaces the same day. - **The new version is checked** against the signed-off feature requirements. The comfort test now fails, while the product is still in development. - **The engineer asks "why?"** Vinci follows the links between the teams' requirements and points to PT Cooling's calibration change, who made it and when. - **Vinci lists everything affected** in all four teams, and what each owner needs to do. - **The owners are brought in** as reviewers, with a Slack thread that already holds the full analysis. The same problem, two paths — months later across four teams, or the same day with one engineer. ## Outcome The root cause and the owner of every follow-up were known within minutes of the failing test, and the fix moved from integration into development. The "without Vinci" column describes the typical path for this kind of problem, not a measured baseline. | Without Vinci | With Vinci When the problem is found | At integration, months after the change | In development, on the next version Time to find the cause | Days | About ten minutes People involved before the cause is known | Engineers from all four teams | One engineer Linking it to the original change | Someone has to remember it | Found automatically, with who made it and when Knowing what else must change | Discovered meeting by meeting | Listed up front, per team Getting the right people involved | Emails and meeting invites | Reviewers added and a ready-made Slack thread ## Appendix for engineers: impact by owner The chain: PT Cooling lowers its front-end fan map (CAL-PTC-002). The shared fan runs at max(Refrigerant, PT Cooling) request (SW-PTC-006), so it now spins slower whenever PT Cooling was the higher request. Less condenser airflow raises AC discharge pressure. Refrigerant's high-pressure protection (SW-REF-006) freezes, ramps down or stops the compressor, so the evaporator can't reach its target. Cabin can't deliver cold vent air (TSR-CAB-002), and the cabin drifts above setpoint (FSR-001). Based on the EV Thermal AC/HP requirement set and simulated hot-weather test data. Owner | Fails | At risk | Review | Key items Ishaan Jain (PT Cooling) | 0 | 1 | 1 | Source of the change: CAL-PTC-002 fan map lowered. Re-check against Refrigerant's condenser airflow needs at high ambient, or restore the previous map. SW-PTC-006 fan arbitration to review. Aaryansh Bansal (Refrigerant) | 1 | 2 | 0 | SW-REF-006 high-pressure protection now trips in hot conditions. TSR-REF-003 condenser heat rejection and CAL-REF-005 (condenser fan request map) at risk. Neha Kulkarni (Cabin Climate) | 1 | 0 | 1 | TSR-CAB-002 cold-air delivery (vent ≤ 8 °C) not met while the compressor is held back. TCS-CAB-009 to review. Kartikeya Gupta (Thermal Feature) | 1 | 1 | 0 | FSR-001 fails on hot days (cabin above setpoint); FSR-002 pull-down at risk. Decide: restore the fan map, or restate the feature at high ambient. > A requirement that passed once should not stay "passed" forever while the systems underneath it keep changing. Re-check every version, and the failure shows up the day it breaks.