Anti-patterns and how the validator catches them

What you'll do

Review a deliberately flawed synthetic page and divide findings among structural validation, query evidence and native-host review. Produce a failure report that says what was checked and what remains unknown. The goal is a defensible release decision, not a page that merely looks tidy.

Distinguish check families

Layout validation checks geometry and ordering under the selected frame. The documented report.design.valid family addresses presentation constraints separately from the frozen eight layout rules. The design contract describes the intended checks; it does not establish that every installed release implements them.

The v2 archetype/background/theme integration is Preview. Read the installed contract before claiming a particular automatic refusal. When a required check is unavailable, record it as unverified and use the owning review procedure rather than displaying a passing status.

Find the bounded refusals

The schematic allows at most six logical KPI cards, eight logical data slots, twelve rendered data visuals and three header slicers. Companion sparklines count when separately rendered as data visuals. Static headers and navigation are chrome, not extra data slots. Four KPI slots remain the default, not a requirement to duplicate measures.

Under brilliant-v1, the intended geometry checks include 16px gutters, whole-pixel placement and actual bounds. Do not reapply the older research's superseded 10px grid. Check the selected frame rather than mixing convenient values from different versions.

Synthetic review findings:
7 logical KPIs -> exceeds the policy ceiling
Cost +5%, green, no polarity -> unsupported sentiment
Baseline zero, relative +100% -> unsupported calculation
Background from prior placement map -> stale compatibility
Reset target exists, no click test -> interaction unverified

A validator can inspect declared metadata and actual resources. It cannot infer a valid business target from a measure's name, know that a screenshot is legible in every host or establish causality from a ranked breakdown.

Catch semantic traps separately

Review percentage points versus relative percentages, partial versus complete periods, mixed currencies and snapshot sums. Averaging displayed percentages can produce a plausible but wrong total. Top-N Other and waterfall bridges need retained reconciliation evidence. Where that evidence is absent, do not claim the validator independently proved the arithmetic.

Text below 10pt, missing alt text or an illogical declared order can be checked structurally. Actual glyph clipping, high-contrast behaviour, keyboard focus and essential hover-only information need rendered and interaction evidence. A theme's contrast table cannot prove every native override meets it.

Build a release evidence matrix

First retain schema, resource, assignment and layout results for the exact report definitions. Next extract queries from the actual emitted or read-back PBIR and compare named states with independent expectations. Then bind native exports and any declared numeric-label checks to the report, model, refresh and filter state.

OCR checks are bounded preview capabilities. Missing, clipped or contradictory numeric evidence must not pass, and an export needs independent calibration. A 2x background does not establish the service export's dimensions or offsets. Keep keyboard journeys and human visual acceptance separate from numeric-label checks.

Your expected output lists passed checks, refusals, unverified requirements and the next owner action. Say implemented and verified only for checks actually run. A well-documented limitation is more useful than expanding a narrow green result into a report-wide certification.

Check your understanding

1. Why can layout pass while a displayed revenue label remains unqualified?
2. Which anti-patterns require retained semantic or reconciliation evidence?
3. How should you report a required design check missing from the installed release?