Hardware development is accelerating. New configurations, software updates, and data models appear constantly. Each change requires updated validation, and tests that once passed may fail simply because the logic behind them is outdated. 

Imagine a robotics team updating its motor controller firmware to support higher precision sensors. The new firmware changes how sensor feedback is processed, but the validation logic still checks against the old signal’s calibrations. Overnight, dozens of tests start failing not because the robot is malfunctioning but because the validation rules no longer match the system’s new behavior. As development speeds up, testing often lags behind.

The potential consequences of iterating in production are far from trivial. If mission-critical operations like flights or launches get scrubbed because engineering calibrations can’t detect issues ahead of time, the cost could be hundreds of thousands of dollars. To take a space launch as an example, costs include helium and fuel, personnel, recovery assets, and rescheduling the flight with the FAA. NASA has previously estimated that a postponed launch can cost more than $1 million a pop. 

Building hardware like software: leveraging CI/CD best practices in hardware pipelines

Continuous Integration and Deployment (CI/CD) transformed software by automating testing and integration, catching issues early, and keeping teams in sync. Now, “software for hardware” tools like Sift bring these same principles to hardware workflows. Sift enables engineers to embed testing and data review directly into design, shortening iteration cycles and improving both speed and confidence.

Make validation seamless

In software, every commit runs automated tests linked to specific results. Hardware can adopt the same CI/CD model by shifting validation earlier and making it traceable to builds, tests, or configurations. With Sift, this becomes possible through Ad Hoc Rules, snippets of source code engineers define to ensure that validation logic evolves alongside configuration changes. What makes Ad Hoc Rules unique is that they are maintained external to Sift, alongside the code or systems under test similar to how unit tests in CI live alongside the code they are testing. This means the same logic automatically runs on the correct dataset and configuration every time, keeping validation consistent, versioned, and traceable across simulations, hardware tests, and telemetry.

For example, let’s say the team needs to test that the temperature sensor reads within expected bounds. The team might want to create a single check for temperature that uses thresholds based on the robot configuration, which would be especially valuable if the team has a different version or type of sensors per configuration:

# Step 1: Get the temperature sensors bounds dynamically based on the robot configuration
# robot_configuration can be any user defined metadata (e.g., configuration file from the repo, command line argument, etc.)
min_temp, max_temp = get_temp_sensor_thresholds(robot_configuration)

# Step 2: Create a rule to verify sensor bounds
RuleCreate(
	name="check_temp_sensor_bounds",
	description=f"Flag if the robot's temperature sensor exceeds expected thresholds",
	expression=f"$1 < {min_temp} || $1 > {max_temp}',
	asset_names=["NostromoLV426"],
	channel_references=[
		{
			"channel_reference": "$1",
			"channel_identifier": "robot.temp_sensor_channel",
		}
	],
	is_external=True,
)

‍

Returning to the team updating its motor controller firmware, engineers can modify the Ad Hoc Rules in their source code to reflect the new signal behavior. As the updated robot runs, Ad Hoc Rules can verify system behavior using the correct version of the configuration and rule as defined in the source code. Instead of dozens of tests failing because the logic is outdated, validation stays aligned with the system’s latest design, making testing continuous and providing immediate feedback engineers can trust.

Sift helps teams build better

Sift turns continuous validation into an operational reality. By unifying data and automating feedback, it gives hardware teams the same speed and reliability as modern software development. Each build runs validated, versioned checks automatically, standardizing testing across simulations, prototypes, and production.

The result: faster iteration, higher reliability, and hardware development that finally moves at the speed of software. Interested in learning more? We'd love to hear from you.