Your Trust page is the most valuable hypothesis source you have

Most cloud compliance tools audit your config. CME audits your config AND your published claims. The reason is simple: your Trust page, security FAQ, and DPA already encode the controls you said you have. They're a hypothesis-rich starting point that's free for the asking — the customer wrote them.

What the agent extracts

From a typical Trust page (~6,000 words), the agent extracts 12–18 verifiable commitments. Examples:

"All data at rest is encrypted with AWS KMS customer-managed keys"
"MFA is required for all production access"
"Audit logs are retained for 90 days minimum"
"We use AWS Config to detect drift in IAM policies"

Each becomes a hypothesis the agent verifies against your live environment. When AWS state contradicts a public commitment, that's a BROKEN_COMMITMENT finding — distinct from a framework gap, and usually higher-impact because the customer made the claim publicly.

The order matters: We verify your published claims BEFORE running framework controls. If your Trust page says 'all data encrypted with KMS' and your prod RDS isn't, that finding fires before any SOC 2 control is checked.

What this catches that nothing else does

Trust pages drift. The team that wrote 'we encrypt all data with KMS' three years ago isn't the team adding new RDS instances today. Drift is invisible until either (a) an external auditor asks for evidence or (b) the customer who read your Trust page submits a vendor questionnaire that doesn't match reality. We find it before either happens.