Takeaway

Can’t read the entire technical blog? Here’s what you need to know: External Rules bring the power of Sift’s Rule system to CI/CD workflows. By defining checks in code and evaluating them after each Run, teams can automate telemetry validation and review without adding overhead to the Sift UI. This technical blog explains how External Rules work and why they enable faster, cleaner, and more scalable testing.

Overview: What you’ll learn about External Rules in CI/CD  

This technical blog introduces External Rules, a feature in Sift’s data model that allows teams to automate telemetry evaluation in CI/CD workflows using logic defined outside the Sift platform. External Rules extend Sift’s Rules framework by allowing engineers to define evaluation logic inline at runtime, using either the REST or gRPC API.

The blog begins by reviewing how Rules work in Sift and how they are used to express logical conditions over telemetry data. It then introduces External Rules and explains how they differ from traditional Rules in terms of lifecycle, visibility, and intended usage. Next, the blog presents a common use case: software/hardware teams running simulation flights in CI/CD pipelines where each test requires custom, version-specific logic. Finally, it concludes by showing how External Rules help these teams automate telemetry validation and review, reduce Rule management overhead, and keep the Sift UI clean and focused.

‍

Rules

To understand how External Rules extend Sift’s capabilities, it helps to first understand what Rules are. In Sift, Rules define logical conditions used to evaluate telemetry data, either in real time during ingestion or after a test has completed. Rules can be created through the Sift web application or programmatically using the Sift APIs. They use the Common Expression Language (CEL) to define logic such as threshold checks, state comparisons, or relationships between telemetry Channels.

Each Rule operates on one or more Channels tied to an Asset. When the condition evaluates to true, the Rule enters a violated state. When it no longer holds, the Rule transitions to a resolved state. These transitions can trigger notes (Annotations), which mark important events in the data. Rules are visible in the Sift UI. You can view and manage them in the Rules tab, and Rule logic can be visible in the Annotations and Reports associated with the Rule, providing context for what was evaluated and why it triggered.

External Rules

External Rules in Sift allow teams to evaluate custom logic for post-test telemetry analysis. They are defined through Sift’s REST or gRPC API and are designed for dynamic, ad hoc workflows such as CI/CD pipelines, simulations, or hardware-in-the-loop tests. This makes them well suited for automated test infrastructure where evaluation logic changes between tests.

Unlike standard Rules that are created and managed in the Sift UI for persistent monitoring, External Rules are single use. They do not appear in the Rules tab, cannot be edited after creation, and are not stored in the platform’s canonical Rule set. This makes them ideal for logic that is specific to a test configuration or software version. Although External Rules are not listed in the UI, their logic is visible through the Annotations and Reports they generate.

In the REST API, External Rules are created using the BatchUpdateRules endpoint with the isExternal flag set to true. In the gRPC API, you can create an External Rule by setting the top-level is_external field to true in an UpdateRuleRequest. This allows teams to submit evaluation logic programmatically as part of their test automation, directly tied to the test (Run) under analysis.

Use case: Using External Rules to automate version-specific checks in simulations

A software/hardware team is running automated simulation flights as part of their CI/CD pipeline. Each simulation tests a different software build or configuration, producing a full test (Run) of telemetry. To validate expected system behaviors, the team needs to apply checks that are specific to the version being tested, and that evolve alongside the code.

With External Rules, the team can define these checks directly in the pipeline. The logic is stored with the simulation code or embedded in the test harness, and submitted via the Sift API after each Run completes. This ensures that every simulation is evaluated using logic that is accurate for that exact test, without requiring prior setup or coordination outside the test system. The evaluation results appear in Sift as Annotations and Reports, giving the team visibility into what passed or failed and why. This keeps test-specific logic tightly scoped to each Run while preserving context across versions and environments. It enables fast, reproducible validation in CI/CD pipelines, especially when simulations span multiple branches, builds, or hardware variants.

Conclusion 

External Rules enhance Sift’s evaluation engine by enabling version-specific telemetry checks that run automatically after each test. They allow teams to define validation logic directly in code, apply it programmatically to each Run, and surface results through Annotations and Reports. This makes them ideal for CI/CD workflows, where fast, repeatable, and context-aware telemetry review is essential. By keeping test-specific logic scoped to the code and the Run, External Rules support automation at scale while preserving clarity, traceability, and speed.