Custom metrics and the Expression lab
Writing, previewing, and publishing your own metrics.
The Expression lab
The Expression lab is where metrics come from. It is a notebook: you write an expression against your own data, run it, look at the result, choose how it should be displayed, and publish it to the catalog so rules, targets, dashboards, and reports can use it.
It has two tabs.
Catalog lists what is already published, filterable by All, Metrics, or Functions, with badges showing the role of each entry (Analytics, Target, Rule, trade, Rule, day, Rule, execution, Function). From a row you can open an entry in the editor, view its Metadata, copy it as a new entry, or delete it. Refresh reloads the catalog and New starts a blank expression.
Expression is the editor. It gives you the expression text, a Run button, a Return shape readout so you know whether you produced a scalar, a record, or an array, and a Preview frame showing the result rendered as the component you chose, with width and height controls. Apply sub-filter runs the expression against the current filter selection rather than everything.
This is an advanced feature and it is available on higher plans. You do not need it to use the product. You need it when the question you want to ask about your own trading is not on any card.

Writing an expression
Expressions start from a data root and chain operations onto it. The most common root is your executions, and the simplest useful expression counts the trades built from them.
The editor helps you in three ways:
- Complete offers completions, also available with Control and Space.
- Enter runs the expression, and Shift with Enter inserts a newline.
- Syntax reference opens the Kernel expression language reference, which lists the entry points, the chain methods available, the filter operators, and the properties you can use in rule expressions.
The reference is generated from the engine itself, so it is accurate for the build you are running. Read it rather than guessing.
One important restriction. Rule metrics must be a single property path: trade, day, or execution properties, without filter or grouping chains. Analytics metrics have no such restriction. This is because a rule is evaluated once per unit and needs a direct value, while an analytics metric summarizes a set.
When you write a rule metric, choose the Kind as Rule metric and set the Scope to Trade, Calendar day, or Execution, then use the preview samples to confirm it returns what you expect.
Publishing to the catalog
Publish to catalog turns a working expression into something the rest of the product can use. The dialog asks for:
| Field | Meaning |
|---|---|
| Catalog entry type | Metric or Function. Functions are building blocks other expressions call |
| Id (stable key) | The permanent identifier. Changing it later breaks anything pointing at it |
| Parent namespace and Namespace segment | Where it sits in the catalog tree |
| Display name | What people see in pickers |
| Description | What it measures, and any caveats |
| Tags | Comma separated, for finding it later |
| Publication payload | The components you configured, with their display formats |
Display format matters more than it sounds. The same number formatted as a plain number, currency, a percentage, a ratio, or an R multiple reads completely differently on a card, and the format travels with the metric everywhere it is used.
Choose ids carefully and write real descriptions. In six months the catalog will contain metrics you no longer remember creating, and the description is the only thing that will tell you whether you can trust one.