Shaping your tags
Almost every question about Driftmetrics is really a question about which tags a run should carry.
We measure on hardware and in a simulator. One project or two?
One project. The environment is a tag, so the same metric can be trended per environment and compared across them in one query. Add the board when you run on more than one.
Debug and release builds?
A tag as well. Both builds push the same metric names, and a filter picks the one you care about. Without the tag the two runs collide on the same coordinate and overwrite each other.
Our repo builds several libraries. How do I keep them apart?
A component tag, one push per component. Use separate projects only when the artifacts are separate products with their own teams, tokens and metric sets.
How do branches fit in?
The version stays the axis and the branch is a tag, so a pull request gets its own series next to main instead of interleaving with it.
Should a metric ever be a tag?
No. Push every number a build produced in one call — the run holds them all. When the same metric repeats per model or per input set, that repetition is the tag.
Our nightly benchmark has no version. What then?
Put the project in time_series mode, where the timestamp joins the identity, so a nightly run appends a point instead of overwriting one. Keep the commit in meta.
What belongs in meta?
Anything that explains a run without identifying it: commit sha, CI run URL, runner name, toolchain version. Move a value out of meta and into a tag the day you want to compare on it.
A new project or another tag?
A project is an access and history boundary: its own token, its own metric definitions, its own axis. If the numbers belong to one product and you would ever chart them together, use tags.
What happens if I push the same tags twice?
In versioned mode the run is replaced: the new measurements win and a metric you left out is dropped. In time_series mode a second push appends a point.
How are versions ordered?
By series time — the timestamp a push carried, or when it arrived — never by parsing semver. Backfilling old releases? Send a timestamp per release, or make the axis a numeric tag such as the build number, and the order is the one you meant.