Illustrative example · Anonymized real engagement · Screenshots & IDs redacted

Example Test-Stage Proof — End-to-end provisioning verified in customer's cloud organization

EXAMPLE-001 · test stage · date redacted

Created a new project on the test environment under the customer's tenant. The platform ran the full provisioning pipeline to completion. The two paired cloud accounts now exist inside the customer's own cloud organizations, in the correct workload organizational units.

Proof 1 — the new project, no failure banner

Logged in as the customer's admin role. Created a new test project under their organization. No "Account Activation Failed" banner. Clean state.

New project detail page (blurred for anonymity)
blurred · layout preserved

Proof 2 — cloud-provider CLI verifies the accounts exist in the right place

Run with the customer's provisioning credentials directly against the cloud-provider APIs. The provider confirms both paired accounts are alive, inside the customer's organizations, in the correct workload OUs.

Cloud CLI describe-account output (blurred for anonymity)
blurred · layout preserved

What the cloud provider returned, in a nutshell

Each row below is a real value the cloud-provider API returned. Specific IDs are redacted; the shapes show what was verified — for each paired account: the account ID, the parent organization, the placed-OU ID, and ACTIVE status.

Commercial account ID
1•••redacted•••2
(12-digit cloud account ID)
Lives in
customer's commercial organization
root r-••• · mgmt account •••2024•••
Placed in OU
ou-•••-••••••••
(workloads OU — correct destination per spec)
Status
ACTIVE ✓
Restricted-region account ID (paired)
7•••redacted•••5
(paired account in the restricted region)
Lives in
customer's restricted-region organization
root r-••• · mgmt account •••3344•••
Placed in OU
ou-•••-••••••••
(restricted-region workloads OU — correct destination per spec)
Status
ACTIVE ✓

Why this matters — the proof pattern

This is the test-stage counterpart to the dev-stage proof for the same fix. The dev-stage proof showed the failure banner now displays the real error; this proof shows the underlying provisioning actually lands in the correct destination. The agent assembles both reports from the same fix commit, but each proof has its own verification mechanism: dev validates the banner template renders correctly, test validates the cloud-provider API returns ACTIVE accounts in the correct organizational unit. The pattern generalizes well beyond cloud provisioning — any AI-driven workflow producing results that need verification before delivery (medical record matching, compliance approvals, document classification) benefits from a card that can't be assembled until every cross-check resolves.