Receiving verification shows the Data Domain head shipped with a DD OS version older than the minimum required by the customer's backup application support matrix. The install is scheduled for today. What does the installation checklist's software-version step call for?

Compatibility matrices between backup applications and DD OS versions exist because integration features—DD Boost libraries, plug-ins and protocol behavior—evolve together, and an unsupported older DD OS build can fail in subtle ways rather than in clean, obvious errors. The installation checklist therefore treats the shipped-versus-required version comparison as a pre-integration verification: record the gap, plan the DD OS upgrade as a documented step, and only then connect the backup application. Integrating first and upgrading if problems appear fails by concept because the symptoms of an unsupported combination—failed operations, degraded deduplication—often surface at restore time, the worst possible discovery point. Halting the engagement fails by proportionality: a version delta is a planned upgrade, not a mis-shipment; escalating a software gap as a hardware replacement wastes the schedule. Declaring the factory build automatically compatible inverts the logic—the factory image can lag the matrix minimum, and the matrix, not the ship date, defines compatibility. Exam caveat: check the current support matrix for the exact supported upgrade path, because some target versions require an intermediate DD OS release. Operational check: record the shipped build from first-boot output, note the matrix minimum for the customer's application version, record both on the checklist and book the upgrade window before any backup traffic flows.