On the one hand it kinda might be nice to break them out into a separate table to make it clear they're from a separate compose process. OTOH, we already lie about IoT in the same way, so maybe it's fine.

Agreed (on both counts). I'm not sure the current form is the best way to represent the information as it's neither human- nor machine-readable in any useful way. But that's a bikeshed to paint later.

the data LGTM

We do test aarch64 on AWS and OpenStack too. We also test qemu for all architectures we ship (currently x86_64, aarch64 and s390x.

This LGTM (understanding the first column is kind of a lie).

It would be nice to have aarch64 in there, if FCOS folks and ARM folks can commit to the development side and we can buy the QA story. But remember, the key point for "release blocking" is not "do we test it?" but "are we willing to stand behind delaying the release for a week if it fails any of the criteria?" That's a somewhat higher bar...

Let's just start with this and work on the other pieces later if that is OK

LGTM