I sat through a quality review last month where we spent forty-five minutes debating a surface finish specification on a machined bracket. 0.4 Ra versus 0.8 Ra. Real dimensions, real tolerances, real disagreement. Meanwhile, the vehicle outside the meeting room had received three over-the-air updates that week — none of which touched a single document on the table.

That gap is where Polestar's problems live. Their software chief is departing amid mounting quality complaints, and the coverage reads like executive musical chairs. It isn't. The quality system is showing cracks because the product it was designed to certify no longer exists in the form the standards assumed.

Your PPAP has no field for a software commit

I've implemented IATF 16949, AS9100, VDA 6.3 across automotive and aerospace plants for twenty years. Built PPAP packages from scratch — the level 3 submissions, the dimensional results, the material certs, the MSA studies, the capability data. The framework is rigorous. It was built on an assumption: the part you validated in March is the part shipping in October.

It isn't anymore.

When a vehicle's behaviour changes nightly through OTA updates, the "part" in your PPAP is a snapshot of firmware that may be obsolete before the submission letter is signed. Your control plan references process parameters for a component whose logic changes without a manufacturing engineering change request. Your PFMEA — if it addresses software at all — treats it as a black box with a failure mode called "software malfunction" and a detection rating that's essentially a guess.

At Airbus, we cut internal lead time by 97% through routing verification KPIs. The mechanism was simple: we made the verification system match the actual process flow rather than an idealised version of it. When verification lags reality, you don't have a speed problem. You have a blind spot. And right now, every automotive OEM running IATF 16949 has a blind spot the size of their entire software stack.

The defect is in the architecture, not the assembly

Polestar's customer complaints aren't paint runs or misaligned panels. They're infotainment freezes, charging logic errors, drive mode inconsistencies — defects that never passed through a single manufacturing-quality gate because those gates don't examine code.

My ethical hacking background is why I read this differently. A modern vehicle architecture is a distributed system: code running at different privilege levels, APIs exposed to external input, update mechanisms that modify runtime behaviour without re-validation. The quality professional who only knows IATF sees a car. I see a computing platform on wheels that happens to have seats.

The defect isn't that Polestar hired the wrong software executive. The defect is that the quality system — the one their auditors certified, the one their customers audit against — has no mechanism to govern software as a production characteristic. You can field the strongest engineering team in the industry and still ship defects if your QMS stops at the factory door.

A quality system that doesn't follow the product into the codebase is auditing a ghost.

Software is supplier quality — treat it that way

Software in your vehicle comes from tier-twos, tier-threes, open-source libraries, third-party SDKs, and integration layers you didn't write and can't inspect. It's a supply chain as complex as your physical one. When I ran quality at SNOP and Witte Automotive, supplier quality was non-negotiable. We audited sub-suppliers, traced material origins, demanded PPAP from every vendor whose component touched our product. A defect upstream becomes your defect downstream, and the customer doesn't care whose name is on the purchase order.

Software deserves the same treatment. Every library, every dependency, every commit from an external contributor is a supplier deliverable. If you wouldn't accept an unaudited bracket from an unknown vendor, you shouldn't accept an unaudited package in your charging logic.

APQP gives you the framework. Phase-gate reviews, design FMEA, validation planning — these tools work for software if you adapt them honestly. But adaptation requires quality leaders who can read a changelog, interpret a regression test report, and challenge a software architect the way they'd challenge a tooling engineer about dimensional drift. That dual fluency is rare in our industry. Its absence is what produces headlines like Polestar's.

Key takeaways

  • Extend your PFMEA to treat software commits as process characteristics — each OTA update is a process change requiring validation, not just deployment approval.
  • Apply supplier quality discipline to your software supply chain: audit repositories and dependencies the way you audit tier-twos, and demand documentation for every library that touches safety-critical functions.
  • Train quality engineers to read changelogs and interpret test coverage reports — if your QMS team can't see the defect mechanism, they're certifying blind.
  • Update your control plan to include software version as a traceable characteristic alongside part number and lot code, because the firmware defines the product as much as the casting does.

The quality director who signs off on a PPAP for a vehicle running software they've never reviewed is accountable for defects they cannot see and cannot prevent. That's not a training gap or a hiring problem — it's a blind spot built into the standards. IATF 16949 was written for a world where the part on Monday was the part on Friday. The plants that survive the transition to software-defined vehicles won't be the ones with the cleanest welds or the tightest paint specifications. They'll be the ones whose quality system follows the product where it actually lives — into the code.