Appendix B — AI Transformation Readiness
Most AI-transformation programs are sold and measured as technology rollouts and fail as human-system problems. The model is bought, the pilot runs, adoption stalls — and the post-mortem blames change management in the abstract. CAMS gives the failure a precise address: AI readiness is not one thing, it is the four conditions evaluated against work that is about to change shape. This appendix maps the conditions onto transformation programs.
The applied product surface for this domain is /ai; this appendix is the reference layer beneath it.
Readiness is a CAMS reading, not a score
"Are we ready for AI?" is the laundry-list question. The diagnostic question is which condition is binding for this team against the specific change:
- Capability — does the team have the skill to do the work in its new, AI-mediated form, and is there a current spec for what the role becomes? Transformation moves the spec faster than anything, so Capability gaps open quietly.
- Alignment — does the team know what the AI initiative is actually for, and how it reranks their priorities? Unaligned transformation produces enthusiastic adoption of tools aimed at the wrong outcome.
- Motivation — does the team have a reason to adopt, or a rational reason to withhold (fear the tool replaces them, or that effort to learn it will not be rewarded)? Adoption friction is usually rational withholding, not Luddism.
- Support — do the tools, data access, and manager coverage exist to make the new way workable, and is it safe to say "this isn't working yet"? Without safety, you get reported adoption and actual workaround.
Why "adoption" is the wrong top-line
Adoption metrics measure logins, not value, and reward the appearance of transformation. A team can adopt a tool fully and produce nothing new (Alignment), or quietly route around it while reporting compliance (Support/safety). The binding-constraint frame asks what is actually blocking the work from changing, which is the thing the program was bought to do.
The most under-diagnosed transformation constraint is the psychological-safety facet of Support: teams hide that the new workflow is worse until the program is too committed to correct. Protected feedback is the instrument for surfacing that early.
Where the evidence will anchor
- Technology adoption — acceptance models (perceived usefulness/ease) and their limits as value proxies
- Change readiness — organizational readiness and the human-system determinants of transformation success
- Skill transition — reskilling under task change and the spec-drift problem
- Job insecurity and motivation — rational withholding under perceived replacement risk
Specific DOIs and effect-size claims will replace these as cams-anchor-registry.json matures (PFX-53).
Status: draft appendix. See /ai for the applied surface. Citations are placeholders until the anchor registry ships (PFX-53).