Where did this number come from?

A screenshot of a revenue chart lands in a planning meeting, with one large number for the quarter. Nobody in the room can say whether that number came from production, from a sample someone pulled last week, or from the mock data used to lay out the dashboard. They also cannot say what "revenue" means in it: gross or net, with or without refunds, booked or shipped. The chart looks the same in every case.

Emolysis answers both questions on the chart itself. Every chart says where its rows come from, and every measure names the definition it shows. This post explains the three provenances, how a chart moves between them, and the checks that keep a mock number from being published.

Three provenances

A chart's dataset carries one of three provenances:

• Illustrative. Rows generated from the chart's definitions, never real data. This is what a new dashboard shows first, so you can see the layout and the question's shape at once.
• Sample. Rows read from the project's local lakehouse: a sample of your platform's tables, a copy, or a local file you loaded.
• Live. The complete rows of the deployed gold table, read after a successful pipeline run. A read that was cut short by a limit is a sample, never live.

A sample or live dataset also records when its rows were read. In a chart spec it looks like this:

{
  "dataset": {
    "source": "revenue_by_region",
    "fields": [
      { "name": "region", "type": "nominal" },
      { "name": "revenue", "type": "quantitative" }
    ],
    "provenance": "live",
    "as_of": "2026-10-19T08:40:07Z"
  }
}

The spec is checked before anything draws it: as_of is required for sample and live rows and not allowed for illustrative ones, because a generated row has no read time. The viewer turns it into a line under the chart's title: "Live, as of Oct 19, 2026, 08:40 UTC". A sample says "Sample, as of" with its date, and an illustrative chart says "Illustrative".

Illustrative rows that never reach git

Illustrative rows deserve a closer look, because mock data has a habit of turning into real data. Emolysis never stores them. A dashboard file names each dataset and its provenance, and the illustrative rows are generated again every time the dashboard is read, from a seed taken from the dashboard's and the dataset's names. The same dashboard always draws the same illustrative numbers, and none of them is written to the file you commit.

Where the project's lakehouse already holds a sample of the source table, the illustrative rows use its real dimension values, such as the actual region names, so the layout looks like the answer. Only the measures are generated. Because the dimension values come from the sample at read time, they never end up in git either.

Definitions a person confirms

The provenance says where the rows came from. It does not say what the number means. For that, each measure in a chart names a metric definition and its version, and the viewer lists them under the chart: "Revenue", "revenue, version 2".

A definition is a file in the project. It holds the expression, the filter, the source table and the grain. Here is one metric, written as the query it stands for:

-- revenue: completed orders, net of refunds, by order date
SELECT SUM(amount - refunded_amount)
FROM sales.orders
WHERE status = 'complete'

A new definition starts as a draft. A person confirms it, and Emolysis shows the expression, the filter, the source and the grain in that question, because a confirmation with the definition hidden is not a confirmation. The confirmation records who confirmed it and when, for that version only.

Any change that can change a number, such as the expression, the filter or the source, makes a new version and a new draft. Editing the description does not. Here is how one metric's history might read:

A chart that still names version 2 after version 3 exists is stale, and the dashboard says so, also when someone edits the file by hand. It leaves that state only when it is bound to the data again.

What a publish refuses

Publishing a dashboard turns its charts into a link other people open. Before it does, Emolysis refuses a dashboard that has an illustrative chart or a stale chart, and names the charts. The person who publishes reviews the dashboard first. The viewer adds its own check: on a published dashboard, a chart that says it is illustrative is not drawn, and its tile says "Illustrative numbers are not published" while the other charts draw as usual.

So the screenshot from the meeting carries its answer. A published chart is a sample or live, with the time of the read, and it names the version of the definition it shows.

What provenance does not prove

Provenance is a record, not a guarantee. "Live" means every row of the gold table was counted, as of the time shown; it says nothing about the hours since. "Sample" means real rows, but not all of them, so a sample's totals are a sample's totals. A confirmed definition means a person read it and agreed; it does not make the definition right for every question, and golden tests on the pipeline check its logic against fixtures, not the business meaning of a metric. And a chart spec written without a provenance shows no badge at all; the sample dashboard on this site is one, because its data is synthetic.

What the badge does give you is a question you can answer before the meeting starts. The dashboards docs and the sharing docs describe the rest of the workflow.

Emolysis is in private development. Nothing described here is released yet.