Metrics and saved views

Ask two assistants for “revenue last month” and, left to themselves, they may count it two ways: one leaves out cancelled orders and one doesn’t. A metric settles it: a number you define once, a person approves, and every assistant then gets back the same way. A saved view is a question you ask again and again, such as monthly revenue by region, kept under a name so any assistant can answer it.

Metrics

A metric is counted from one dataset. It has:

• A short name and a label: revenue, “Revenue”.
• A description in your own words. It’s shown with the metric and never used to work the number out.
• What it counts: the number of rows, the number of different values in a column, or the total, average, smallest or largest of a column. Or one of those divided by another, such as the share of orders that shipped, where each side can have its own filters. When the bottom of a division is zero, the answer is blank rather than an error.
• Its own filters, always applied: “where status isn’t cancelled”.
• The periods it can be asked by, from a date column: day, week (starting Monday), month, quarter or year, plus one number for the whole period. One of them can be the default.
• What it can be split or filtered by when it’s asked: region, customer, and so on. A number column can be split into ranges, such as under 2, 2 to 4, 4 and over. Rows with no value get a label of their own (“no temperature” for a temperature column, or a label you choose) and are listed after the ranges, so they’re never quietly mixed in.
• Columns of a dataset it points at, through a declared relationship: revenue split by the customer’s city, say.

There are no formulas to write. A metric is put together from these parts, so it’s always something Ontyx can read back and check.

Proposing and approving

Your assistant proposes a metric, and Ontyx writes back one sentence that says exactly what it counts:

Revenue: the total amount in “orders”, where status isn’t “cancelled”, by month, quarter or year of ordered_on, split by region or customer.

The sentence comes from Ontyx, not from your assistant, so what you approve is what gets counted. Before you see it, the proposal is checked against the dataset’s structure: a misspelled column comes back with a suggestion. It’s also checked against the data loaded now: a filter that matches no row (often a difference in capitals, “issued” instead of “Issued”) is flagged, but can still be approved, because the data changes.

An owner or admin approves the metric in the conversation or on the dashboard’s Approvals page. Saying no can come with a reason, which is kept so the next proposal can address it. Approval checks the metric again first: if the dataset’s structure changed in between and the metric would now count something different from the sentence you were shown, approval is refused and the proposal stays waiting.

Versions

Proposing a metric under a name that already exists proposes its next version. One version can wait for approval at a time, and every version is kept, approved or not. Answers always say which version they used, and an earlier approved version can still be asked by number. What each approved version reads (the dataset, its columns, the structure version) is recorded when it’s approved.

Retiring a metric

An approved number must never quietly stop working. A change to a dataset that would stop an approved metric from working (removing a column it counts, say, or a relationship it uses) is refused, naming each metric and why. So is marking the dataset for deletion. If you agree to lose those metrics, the change goes ahead with them named, and they’re retired in the same step.

An owner or admin can also retire a metric by hand on the dashboard, with a reason. A retired metric can’t be asked any more, and it stays listed among the retired ones with every version. Approving a new version brings it back.

The same number from every assistant

Asking a metric the same way, over the same data, gives the same answer, character for character, whichever assistant asks. Rows come back in a fixed order (by period, then by each split), and averages, divisions and totals of measurement columns are rounded to 12 significant digits so their last digits can’t wobble between runs. Exact amounts are never rounded.

Every answer carries the metric’s name and version, every filter that was applied (the metric’s own, the ones in the question and the period), and the date the data is as of. See Asking questions.

Saved views

A saved view is a named question over approved metrics, such as “revenue and order count for one month, by region”. It holds:

• The metrics it asks, up to 10, each with how it’s split and any fixed filters.
• One period for all of them: by day, week, month, quarter or year, or one number each, and optionally a fixed date range.
• Parameters, filled in each time it’s asked: a period at the view’s grain (“which month?”), or a value a column must equal (“which region?”). Every parameter needs a value, so the same question always asks the same thing.

Ontyx reads the view back in a sentence when it’s saved:

The view “monthly_revenue” asks 1 metric by month, for the month given as “month”: Revenue (metric “revenue”), split by region.

Any assistant, in any conversation, asks it by name: “run monthly revenue for September 2026”. Readers can ask views too.

Saving and changing a view

A view combines metrics that a person has already approved, so it has no approval of its own. An owner or admin saves it, and Ontyx checks it against the metrics in force first: each metric must be approved and not retired, and each split, filter and parameter must be one that metric can take. Saving a view again under the same name replaces it.

On the dashboard, an owner or admin can rename or delete a view. What a view asks is changed by asking your assistant to save it again. Deleting a view leaves its metrics and their data alone.

What a view is, and what it isn’t

• A view is a question, not a copy of the numbers. It’s answered fresh each time, from the data in force and each metric’s version in force, so the answer moves when new data arrives.
• A view answers each metric exactly as asking that metric directly would, with the same rows, filters, versions and as-of dates.
• A view doesn’t hold its own definition of a number. It can only ask approved metrics. To count something new, propose a metric first.
• A view doesn’t pin a metric’s version. When a metric has a newer approved version, the view uses it and the answer says the view was saved with the older one.
• A view isn’t a chart or a layout. It returns numbers, which your assistant presents.

If a metric a view asks is retired, the view still answers with the others and names the one it left out. If a metric’s new version can no longer be asked the way the view asks it (a split it dropped, say), the whole view is refused with the reason, so nothing is ever quietly missing; saving the view again fixes it.