A semantic layer sits between the raw tables and the reports. Instead of every analyst writing their own SQL for “open RFIs” or “win rate”, the metric is defined once, with a name, a formula, a unit, a direction (higher or lower is better) and the dimensions it can be split by. Dashboards, exports, alerts and questions all reuse that definition.
Why it matters
Without one, two reports disagree because each counted differently: one includes void RFIs, one doesn’t; one divides win rate by all pursuits, one by decided pursuits. A shared catalog makes the number the same everywhere, and makes “where did this come from?” answerable.
Common mistakes
- A catalog that copies data into a warehouse nightly, so numbers lag the records.
- Definitions that live in one analyst’s head or one workbook.
- Ignoring permissions: a well-defined metric is still wrong if it counts rows the viewer shouldn’t see.
How os.construction handles it
Analytics is built on a metric catalog of more than 280 metrics across projects, financials, field, safety, preconstruction and CRM. Every query is compiled from catalog definitions, never free SQL, and runs as the viewer with their permissions. The Glossary tab lists each definition. See the Analytics BI guide.