PMI-CPMAI Model Quality and Configuration Control

Quality and configuration control keep iterative AI development from turning into an untraceable sequence of isolated runs. PMI-CPMAI usually favors the project that defines how quality will be checked, how versions will be tracked, and how the team will preserve repeatability across data, models, parameters, and environments.

QA And QC Are Related But Not Identical

Quality assurance focuses on the process used to create dependable outcomes. Quality control focuses on checking the resulting artifacts or outputs. In AI work, both matter. The project should ask:

• are the development and review practices strong enough
• are the produced artifacts meeting quality expectations
• can the team detect when either the process or the output has drifted

Confusing QA and QC leads to gaps. A team may inspect final results carefully but still lack disciplined development practices. Or it may have process rules but weak review of actual model artifacts.

Version Everything That Affects Meaningful Results

Configuration control in AI projects should cover more than code. It often includes:

• data versions
• model versions
• parameters and settings
• feature or transformation logic
• environments and dependencies

Without that control, later comparisons become unreliable. The project may think it is measuring model improvement when it is actually comparing runs built on different hidden conditions.

    flowchart LR
	    A["Data, code, parameters, environment"] --> B["Version and control"]
	    B --> C["Repeatable QA and QC review"]
	    C --> D["Credible go or no-go evidence"]

Configuration discipline is what makes later quality conclusions believable.

Quality Checks Should Match The Stage Of Work

Early iterations may use lighter checks focused on basic stability and problem fit. Later iterations, especially those approaching selection or deployment, should use more formal controls. The important point is that the project should know what level of review is expected at each stage and why.

Useful questions include:

• what must be reviewed before a run is accepted as decision-relevant
• what criteria make a build or model candidate promotable to the next stage
• what defects or inconsistencies require rework

QA And QC Support Incident Investigation Later

Configuration and quality records are not only for the present. They become essential if later issues appear. When stakeholders ask why a system behaved a certain way or why one model was selected over another, the project needs a controlled history. That history should show what was tested, how it was configured, what evidence supported the decision, and what quality checks were passed or failed.

Control Discipline Protects Deployment Safety

Loose development control can create hidden deployment risk. A model may appear ready, but if the team cannot reproduce the exact data, configuration, and environment used during validation, deployment confidence is weaker. The strongest response is to treat configuration and QA/QC as one operating system that supports safety, repeatability, and governance.

Example

A project team compares two candidate models and finds one slightly better on evaluation results. Before treating that outcome as a valid selection signal, the team should confirm that both were tested under controlled versions of the same data, parameter logic, and environment assumptions. If those conditions differ, the comparison itself may be weak.

Common Pitfalls

• Treating QA as output inspection only.
• Versioning code while ignoring data or parameter differences.
• Applying the same review rigor to every iteration regardless of stage.
• Accepting results that cannot be reproduced clearly.
• Viewing configuration control as overhead instead of as decision protection.

Check Your Understanding

Sample Exam Question

Scenario: A project team has two strong model candidates with similar results. During the selection review, the governance lead discovers that the runs used slightly different prepared datasets and environment settings, and the exact configuration history was not captured consistently.

Question: What should the project manager do to make the comparison credible?

• A. Select the numerically better model because the performance difference is already visible
• B. Move the decision to production monitoring because configuration questions are mostly technical details
• C. Require stronger configuration and QA/QC evidence before treating the comparison as a valid model-selection result
• D. Discard both candidates and restart the entire project

Best answer: C

Explanation: C is best because valid comparison and later deployment confidence depend on controlled, reproducible evidence. If the tested conditions are unclear, the selection decision is weak.

Why the other options are weaker:

• A: A small performance edge is not persuasive if the comparison conditions are inconsistent.
• B: Configuration control is central to governance, not an incidental technical detail.
• D: Full restart is usually unnecessary if the project can restore proper control and revalidate.