Semantic model
Define a metric once. Tables, joins, dimensions and measures form a model that the whole platform shares after release.
A sentence you have heard
Why doesn't this number match Finance's?
Why it happens
Metrics live in every report's SQL: one copy in Finance, one in Sales, one in Operations. Change one and forget the other two. A newcomer takes over and can only copy.
How Shuzi does it
Define it once.
On a canvas, arrange tables, joins, dimensions and measures into a semantic model, validate it, and release it. Reports, the AI assistant and open APIs all read the same definition, so no one computes their own.
measures:
- name: revenue
type: sum
sql: amount
filters:
- sql: "{CUBE}.status = 'confirmed'" ref(revenue)
- Reports
- AI assistant
- API
- PG port
- MCP
revenue = SUM(amount) WHERE status = 'confirmed'
- 01
Visual modeling
Tables, joins, dimensions and measures are built on a canvas, with the native definition available when you need it.
- 02
Draft to release
Validate first, then release the whole thing as a new revision. Historical definitions are never rewritten.
- 03
Consistent calculations
Reports, the AI assistant and open APIs calculate from the same semantic models, with results you can verify.
In detail
Join graph
Tables are organized into a model by their relationships, and the semantic layer handles fan-out and double counting.
Views
Expose only the fields the business needs, under business names rather than column names.
Overlay definitions
Metrics and dimensions added inside a report are compiled into members by the backend. Arbitrary SQL is not let through.
Fixed time zone
The truncation time zone is part of the released definition, so history does not change with whoever is looking.
Take your datafrom tangled to clear.
Try it on sample data first, then bring your own.