The grain of a table is what one row represents, such as one order line, one customer per day, or one region per month. Declaring the grain first prevents the most common aggregation mistakes: double counting through one-to-many joins, and mixing detail and totals in one table.
For example, an orders table at the grain "one row per order line" has one row for each product on each order. A second table at the grain "one row per order" has one row per order with its total. Joining the two on the order id gives one row per order line, each carrying the order's total, so summing that total column counts each order once per line: an order with three lines is counted three times. Stating each table's grain makes the mistake visible before the join is written.
A useful habit is to write the grain as a sentence at the top of a model, such as "one row per store per day", and to test it: the columns that define the grain should be unique together, and the row count should match what the sentence implies, such as the number of stores times the number of days. If a table cannot be described in one such sentence, it probably mixes grains and should be split.
Grain also decides what a table can answer. A table at one row per region per month cannot show a single store's weekly sales, however it is queried, while a finer grain can always be summed up to a coarser one. See also dimension, deduplication and the Aggregation / gold shape.
Many reporting errors trace back to a join that changed the grain without anyone noticing, which is why grain checks belong in a table's tests from the start. See also fact table and gold layer.
Emolysis's Aggregation / gold template takes the grain as a slot and tests totals against known values at that grain. The agent asks you to confirm the grain in the semantic model before it builds a table. See fact table.