The brilliant-v1 frame and grid

What you'll do

Read the brilliant-v1 placement grid and check a synthetic Executive Overview against its bounds. You will calculate the KPI widths and distinguish a design frame from hand-authored coordinates. Keep your output as a review worksheet; the layout engine owns emitted PBIR positions.

Name the selected frame

The spine's default schematic uses the named brilliant-v1 policy frame. It is 1280 x 720 canvas pixels, with a 72px header, 24px outer content margins, 16px gutters and a 136px KPI band. Those dimensions are product policy, not universal usability thresholds.

Do not silently redefine the older default frame or replace a harvested client frame. The earlier default documentation uses different header and gutter values. A reference frame carries its own evidence; an incompatible preset should refuse rather than silently move the client's geometry.

The origin is the upper-left. Each rectangle includes native title and padding space. These are reference dimensions for understanding the schematic, not instructions to enter positions into a page specification.

Reconstruct the grid

The content width is 1280 minus two 24px margins: 1232. Four KPI tiles leave three 16px gaps. Their common width is therefore 296. Starting at x=24 gives subsequent starts at 336, 648 and 960.

KPI width = (1232 - 3 x 16) / 4 = 296
Analysis height = 600 - 136 - 16 = 448
Support row height = (448 - 16) / 2 = 216
Content right edge = 24 + 1232 = 1256
Content bottom edge = 96 + 600 = 696

Below the KPI band, a 2:1 weighted split divides 1216 usable pixels into 811 and 405. The engine uses flush slicing, 1px snap and cumulative rounding so the final sibling reaches the frame edge. Independently rounding every panel can introduce drift.

Reserve the header deliberately

The background draws the white header, a decorative divider and a 4 x 28 accent rail at (24,22). Native title text starts at x=36. Reserve nonoverlapping regions for the title, Page navigator and right-side slicers. A long label should be made concise rather than squeezed into smaller type.

The title, period, filter context and controls stay native and live. The decorative image cannot replace them. Unused slicer space can carry context; it does not need a new visual simply because a rectangle is empty.

Review actual placements

Use a hypothetical failure: the lower support panel starts at y=479 instead of 480, or extends below y=696. Record the mismatch against the selected frame. Do not fix it by moving unrelated visuals until the screenshot looks balanced. Correct the owning layout intent and regenerate through the approved engine.

Compare actual PBIR positions, including group offsets, with the final placement manifest. A pair of matching desired arrays does not prove that the emitted page follows either one. The same final placement map should govern background surfaces and native visuals.

Your expected output is an annotated grid with bounds, gutters and reading order checked. Keep a separate pending list for text clipping, keyboard operation and numeric rendering. Geometry establishes spatial constraints; it does not establish that a title fits its font, a slicer works or a displayed currency is correct.

Check your understanding

1. How do four 296px tiles and three gutters fit the content width?
2. Why must brilliant-v1 remain distinct from a harvested frame?
3. Which evidence is still missing after the placement manifest matches PBIR?