The diagnostic runs a light pre-mortem on the build. If the pilot failed, which constraint killed it? Each dimension is a single question — the one a CISO, a CFO, or a customer will eventually ask out loud.
“Where does your data actually live when the model is training?”
Region, sovereignty, vendor sub-processors, ephemeral copies. The constraint that quietly determines which customers you can even serve.
“What breaks when a vendor changes its API?”
The hidden brittleness in your model supply chain. Every dependency is a future incident waiting for someone else's release notes.
“How fast can your governance keep up with deployment?”
The widening gap between the team that ships and the team that signs off. The fault line that becomes a board conversation only after the incident.
“Who can talk to your model — and can you prove they had reason to?”
Identity, scope, audit, prompt provenance, model-output controls. The dimension whose silence is the most expensive in retrospect.
“What does it cost when the model works?”
Throughput, latency, unit economics under success. The constraint that decides whether your pilot becomes a programme or a quiet shutdown.
Every scenario in Build is derived from the AWS, Azure, and Google Cloud Well-Architected Frameworks — and mapped to ISO/IEC 42001, the NIST AI Risk Management Framework, and the EU AI Act. The diagnostic is not aligned to those standards. It is built from them.
“Most diagnostics are aligned to standards. This one is built from them.”
That distinction is the difference between a credibility claim and an audit trail. It is what allows a CISO to share your output internally without hedging — and what allows a Big 4 partner to bring it into a procurement review without sanding off the edges.