The next releases of Automotive SPICE’s Process Assessment Model (PAM 4.1) and the VDA Guidelines (3rd Edition) are currently in draft as VDA Working Group 13 finalizes feedback from the community. While both documents grow in size, the actual changes are more targeted than the page counts suggest.. Despite both documents growing in page count, PAM 4.1 is an evolutionary update, not a structural one, the same pattern seen moving from PAM 3.0 to 3.1. The more interesting story is in the Guidelines, where two new chapters on AI-assisted development and maintenance mark genuinely new territory for assessments, and point to where the model is headed next.
Why PAM 4.1 Is an Incremental Update
Nothing about how assessments actually work is changing. The number of processes, capability levels, and assessment method are all unchanged, and there’s no major redesign of base practices or generic practices. Most of what grew between versions is presentation, not substance: reworded text, corrected inconsistencies between narrative and diagrams, a cleaner information-item annex, and relocated content, rather than new requirements.
| Document | Previous | New | Page Change | Primary Driver |
|---|---|---|---|---|
| PAM | 4.0 (153 pages) | 4.1 (159 pages) | +6 | Wording clarity, text/diagram consistency fixes |
| VDA Guidelines | v2.0 (264 pages) | v3.0 (312 pages) | +48 | Reformatting, relocated terminology chapters, 2 new chapters |
Process-Level Changes Worth Knowing
Once reformatting and relocated terminology are excluded, the substantive changes are relatively modest: minor updates to a handful of PAM processes and a limited number of guideline revisions: five or six processes in the PAM with minor adjustments, and a short list of section-level edits in the Guidelines.
A handful of processes pick up changes with real assessment impact, summarized below. A few other edits are purely organizational, splitting one outcome into two identical pieces for cleaner traceability mapping, or correcting minor copy errors in reference tables, and don’t change what’s actually being assessed, so they’re left out here.
HWE.2 Hardware Design
| Process | What Changed | Why It Matters |
|---|---|---|
| SYS.1 Requirements Elicitation | New outcome: relevant stakeholders are identified; BP1 reworded; new information item, Stakeholder Groups | Assessors should expect explicit stakeholder-identification evidence, not just implied coverage |
| SPL.2 Product Release | Release content must now be defined and agreed with the intended customer | Customer agreement becomes assessable evidence, not just an internal definition |
| SYS.4 / SWE.5 Integration Verification | “Necessary sequence of verification measures” restored to required aspects | Closes a gap accidentally dropped from PAM 4.0 |
| MLE.2 ML Architecture | Resource-consumption base practice and outcome removed | One fewer requirement for ML architecture assessments |
| MLE.4 ML Model Testing | Pass/fail criteria restored to required test approach elements | Closes another PAM 4.0 gap |
| HWE.2 Hardware Design | Outcome on deriving production-test information removed | Narrows hardware design assessment scope |
Two New Chapters Reshape the Guidelines
The two additions below are where PAM 4.1 and the Guidelines 3rd Edition actually matter for how assessments get planned and run.
| AI Assistance in Development • Doesn’t mandate or restrict specific tools • Requires review of AI-generated output before acceptance • Assessors weigh AI use in SUP.8, SUP.1, and PA 2.2 | Maintenance • Covers pre-SOP maintainability planning • Covers post-SOP development: fixes, enhancements, patches • Judges handover readiness, not future performance |
Automotive SPICE still defines what a process must consider, not how to perform it, so the AI chapter doesn’t recommend or restrict specific tools. Using AI to support process activities or generate work products is treated as legitimate practice, provided outputs are verified before acceptance and the risks AI introduces are handled against clear criteria. Assessors are now expected to factor AI tool usage into interviews and ratings, particularly where it touches configuration management, quality assurance, and work product management.
The Maintenance chapter, one of the largest single additions by page count, is built around one principle: judge how well the current team prepared the product and its documentation for handover, not how a future maintenance organization might perform later. That applies whether the assessment happens before start of production, checking that maintainability was planned for, or during an active maintenance phase covering feature enhancements, defect fixes, or cybersecurity patches.
Rating Rules and Smaller Edits
The Guidelines add a small number of new rules, mostly addressing legacy software and reused components that aren’t reflected in requirements or architecture, and remove roughly seven rules tied to machine learning, hardware requirements, and process improvement that are no longer needed. A handful of smaller section edits round things out, including a rating section reworded for clarity and a couple of narrower sections dropped without much explanation, likely to be revisited before final publication.
The Bigger Picture
None of this is really about the PAM getting bigger. It’s about Automotive SPICE staying deliberately incremental on its core assessment machinery, same processes, same capability levels, same method, while making room for how software is actually built and kept alive today. Vehicle software now routinely outlives a single production run: it gets patched for cybersecurity, updated over the air, and increasingly written with AI assistance rather than by hand. A model that only assessed the path from requirements to release was already missing a growing share of the real engineering lifecycle. Formalizing AI assistance and maintenance as first-class topics is ASPICE catching up to that reality rather than reacting to a passing trend, and it’s a reasonable bet that both areas get more detailed, not less, in the next major revision.
For organizations already operating against PAM 4.0, these updates shouldn’t require major process redesign. Instead, they provide an opportunity to strengthen governance around AI-assisted development and to demonstrate that maintenance activities are managed with the same rigor as initial product development. Teams that prepare now will be well positioned when the final versions are released.
Prepare early. Assess with clarity. Improve with confidence.
