Reading Your Readiness Reports
What each of the six AI readiness reports tells you, who it is for, and what to do with it.
The full AI Assessment produces six scored PDF reports. This page covers what to do with them.
The Outcome
Each report has an owner and a decision attached to it. You leave this stage knowing what is blocking you and who has to unblock it.
Before You Start
You need to have run the full assessment - the Yes route at the Initiate Assessment dialog. The fast route does not generate these reports.
Reports land on your Jamming Board alongside your use cases, roughly 3-4 minutes after the Q&A completes.
Start Here
Open the Gap Mitigation Plan first, before the others.
Every other report describes a state. This one describes work. If the gaps it lists are severe, they change how you read the optimism in the ROI and feasibility reports.
The Six Reports
| Report | Who it is for | The decision it supports |
|---|---|---|
| Revised Priority Use Cases | Whoever picks what gets built | Which use case goes first |
| Platform Decision | Architect, technical lead | AgentCore or Amazon Q for this workload |
| Gap Mitigation Plan | Programme owner | What has to be fixed before or during the build |
| AWS Fit Feasibility Report | Architect | Whether the shape of this workload actually fits |
| ROI Modeling Report | Finance, sponsor | Whether the business case holds |
| Well-Architected Review | Architect, security | Where the design is weak across the six pillars |
How to Read Them Together
Start with gaps, then discount everything else accordingly. The ROI model assumes the build goes to plan. If the Gap Mitigation Plan surfaces serious data readiness problems, the ROI timeline is optimistic and should be read as a ceiling rather than a forecast.
Cross-check priority against feasibility. Revised Priority Use Cases ranks by value. AWS Fit Feasibility ranks by how buildable something is. When the top-ranked use case is not the most feasible one, that tension is the actual decision in front of you - and it is usually worth taking the second-ranked use case first to bank a win.
Treat the Platform Decision as a recommendation, not a verdict. It is generated from the requirements you described. If your requirements were vaguely stated, revisit them before accepting the recommendation.
The Well-Architected Review is for later, but read it now. Most of its findings apply to the deployed system, not the design. Reading it early tells you which constraints to design around rather than retrofit.
What Good Looks Like
You can name, in one sentence each: which use case is going first, what has to be true before it ships, who owns that work, and what the business case depends on. If any of those four is still vague, the reports have not been read properly yet.
Where This Leads
Take your ranked use cases to the Jamming Board and get your team's view on them, then use Choosing Your First Use Case to make the final call.
If the Gap Mitigation Plan surfaced blockers in data or compliance, address those in Align before building - see Data and Governance & Guardrails.