Every semantic layer has to answer the same question correctly: if two dashboards both show "active customers," do they mean the same thing? Get this wrong and you spend the next quarterly review explaining a number gap instead of making a decision.
dbt Labs already built and shipped MetricFlow to solve exactly this: metrics defined once, against semantic models, with dimensions, time grains, and join logic resolved consistently no matter who queries them. Writing our own version of that would have meant re-solving a genuinely hard problem (multi-hop joins between semantic models, correct handling of cumulative and ratio metrics) worse, and out of sync with the semantic layer definitions teams already write in their dbt projects.
What Forewarden adds on top
MetricFlow gives you a query engine. It doesn't give you a place to browse what metrics exist, who owns them, or what dimensions they support, and it doesn't validate your semantic manifest against a live warehouse connection before someone builds a dashboard on a metric that's actually broken.
That's the part we built: a metric explorer listing every metric with its type (simple, ratio, cumulative, derived), its dimensions, and its owner, plus a validate-against-warehouse action that catches a bad join or a renamed column before it becomes a wrong number in front of a VP.
The tradeoff we accepted
Building on MetricFlow means Forewarden's semantic layer is only as good as the semantic models your dbt project defines. We think that's the right tradeoff: it's the same semantic layer whether you query it from Forewarden, from dbt Core directly, or eventually from another MetricFlow-compatible tool, instead of a proprietary metric definition you'd have to maintain twice.