Validation requirement Test 2.5 (per-instance state) does not account for tenant-scoped monitoring w

The current Test 2.5 validation requirement states that all items must have independent per-instance state. This requirement is valid for authoring workloads where each item represents a distinct user-created artifact. However, it does not account for a recognised class of workloads that Microsoft itself documents: operational monitoring tools.

For monitoring workloads whose data source is the tenant itself, two items in the same tenant will always surface identical data by architectural necessity. This is the same pattern used by Microsoft's own Fabric Capacity Metrics app and Workspace Monitoring Eventhouse, both of which surface shared tenant-wide data regardless of how many instances or consumers access them.

Applying Test 2.5 uniformly to monitoring workloads produces a requirement that is architecturally impossible to satisfy without misrepresenting the underlying data or fundamentally breaking the product's value proposition.

Request:

Review Test 2.5 applicability for workloads declared under the trackData itemJobTypes category or any workload whose architecture is tenant-scoped by design.

Introduce a formal distinction in the validation framework between authoring workloads and monitoring/operational workloads.

Where a workload demonstrates that shared state is architecturally intentional and documented in the attestation, allow the Not-Supported with attestation path as a valid resolution for Test 2.5 rather than a hard fail.

Impact: This currently blocks certification for a valid and well-architected class of Fabric workloads that Microsoft explicitly encourages partners to build.