[Audit] Document non-additive measures in fact_uptime and fact_interval_data

[daria-sukhareva]

Context

Two measures in the mart layer are non-additive but are not documented as such. A consumer who SUMs either of these across rows will produce a meaningless or incorrect number, and nothing in the current schema warns them.

• fact_uptime.uptime — a ratio (0–1). Summing uptime fractions across ports or dates produces a number with no business meaning. The correct aggregation is a weighted average (weighted by commissioned time).
• fact_interval_data.avg_value — an average. Averages cannot be re-aggregated by SUM; re-averaging averages without weighting by observation count also produces incorrect results.

In a semantic layer context this matters doubly: if these measures are defined as SUM in MetricFlow, every metric that touches them will silently return wrong numbers.

Acceptance criteria

• fact_uptime.uptime column description explicitly states it is a ratio (0–1), is non-additive, and documents the correct aggregation method (weighted average, weighted by commissioned minutes or equivalent)
• fact_interval_data.avg_value column description explicitly states it is a pre-aggregated average, is non-additive, and documents what the correct downstream aggregation is
• The semantic layer metric definitions for any metric derived from these measures use the correct aggregation type (not SUM) — or a note is added to this issue if no semantic model currently references them
• A dbt_utils.accepted_range test (or equivalent) is added to fact_uptime.uptime asserting values are between 0 and 1 inclusive, as an additional guard against bad data producing out-of-range ratios
• No SQL changes to the mart models are required — documentation and semantic layer config only (unless the semantic layer definitions need correction)