Skip to main content
Assets in Sift represent physical or virtual entities that generate time-series data through their Channels. They can represent a wide range of systems, from tangible objects such as vehicles and hardware testbeds to intangible systems like simulators or continuous integration (CI) pipelines. In essence, Assets are the sources of telemetry data, meaning any entities that produce structured measurements over time.

​
Asset modeling

Asset modeling in Sift is about deciding which physical or virtual systems should be represented as Assets, and how to structure them to reflect your test setup, telemetry flow, or workflow. Good modeling helps ensure that telemetry is organized clearly, supports analysis features like Rules and Runs, and enables long-term reuse and discoverability.

​
Workflows

Asset modeling in Sift can vary depending on the kind of workflow you’re supporting whether it’s a physical test setup or an automated pipeline (for example, an automated simulation pipeline). Some workflows benefit from creating multiple distinct Assets to represent different components, while others work best by reusing a single Asset and using Runs to track variations. This approach ensures traceability, avoids unnecessary Asset proliferation, and makes it easy to manage and review test data. The table below summarizes the two most common Asset modeling strategies in Sift:

​
Rule evaluation

Rules in Sift are evaluated within the scope of a single Asset (in particular, its Channels). This means any telemetry you want to analyze together using Rules must be grouped under the same Asset. For example, if your hardware-in-the-loop (HITL) setup includes Electrical Ground Support Equipment (EGSE), a simulator, and vehicle hardware, you should model this as a single Asset that includes telemetry from all of these components. It is acceptable for multiple clients or data sources to stream to the same Asset simultaneously, as long as they represent parts of the same system or workflow.

​
Naming conventions

When naming an Asset in Sift, aim to make the name clear enough that anyone can understand three key things about the Asset just by looking at it: its type, a unique identifier, and a modifier that describes its environment or context. A common and recommended convention is to separate these parts with underscores for readability, for example: 
type_identifier_modifier
Notes
  • Do not include special characters in Asset names.
  • Use hyphens to separate words or fill spaces within token names.
  • Use lowercase letters in Asset names. This is not required, since Asset names are case insensitive, but it improves consistency and readability.

​
Metadata and tags

While a clear Asset name is the primary way to organize telemetry in Sift, metadata and tags offer a flexible way to extend that context without changing the name itself. These tools can help mitigate some of the tradeoffs involved in naming Assets especially when you want to encode details that may change or expand over time. Tags are simple, descriptive labels such as simulation, flight, or regression. They’re useful for filtering and grouping Assets by type or purpose. Metadata consists of key-value pairs such as testbed: avi-qual-chamber-3 or build: 4721. These allow for more structured, queryable details that go beyond what fits in a name. Unlike Asset names, which are fixed once created, metadata and tags can be updated at any time. This makes them especially helpful for evolving projects or workflows. That said, they are meant to complement a clear and consistent naming convention (not replace it). Most interactions in Sift still begin with an Asset name, so clarity at the naming level remains essential.