Rule Maker

Rule Maker is an automation rule builder within the VIRTEST Observability platform. It enables telecom test engineers to create event-driven rules, when a specific condition is met during a test run, trigger a specific action on a piece of equipment, no scripting required.

A rule consists of three parts: an Event (the trigger), a Condition (the logic that determines whether the action fires), and an Action (what happens to which equipment). Rules can be scoped to a workspace, a specific campaign, or individual test cases, and published to a shared library for reuse across teams.

The challenge was designing a system complex enough to handle real operational requirements, nested logic, multi-parameter actions, version-controlled publishing, while remaining approachable to engineers who aren't developers.

Telecom testing environments are dynamic. A test that passes under one set of network conditions may fail under another, and engineers needed a way to respond to those conditions automatically, without human intervention during a test run.

The existing approach was scripting (engineers wrote code to handle conditional equipment actions). This created bottlenecks: only engineers comfortable with scripting could create automation, rules were hard to share and reuse, and debugging a failed rule required reading code rather than inspecting logic.

The design brief was to build a decision-making environment ,a structured editor where the logical structure of a rule is always visible, always editable, and never requires guessing what the rule actually does.

The editor restructures rule creation into a sequential four-step process. Each step is conceptually discrete, users can't jump ahead without completing the current step, which prevents configuration errors and ensures logical coherence.

Rule Maker expanded automation access beyond the engineering subset who could write scripts, any team member familiar with the test environment could build and publish rules without developer involvement. This directly increased rule adoption and the size of the shared library.

Fewer configuration errors reached the test execution stage. The constrained input model: scoped variable selection, sequential steps, Publish-as-validation caught most mistakes at the point of creation rather than at runtime. Engineers reported higher confidence that a rule would behave as expected before running it.

The shared library model improved team reuse. Rules created once could be published and applied across multiple campaigns and test cases, reducing redundant setup work and ensuring consistent automation behavior across the organization.

Designing for operational risk requires stronger guardrails than typical enterprise UX. When a rule fires incorrectly during a live test, the consequences are real, equipment starts or stops at the wrong time, test data becomes invalid, schedules slip. The design had to earn trust by making the rule's behavior predictable and auditable at every step.

The query builder pattern proved its value. Rather than inventing a new interaction paradigm for the condition builder, we referenced a well-understood pattern (query builders used in BI tools and analytics platforms). This let engineers onboard faster because the mental model was already familiar, even in an unfamiliar domain.

Separating logic from metadata reduces mental overload. The Settings tab deliberately handles only rule metadata, version, catalog, scope. Putting versioning and publishing alongside condition logic would have created a context-switching problem. Keeping them separate meant engineers could complete the logic first and handle publishing as a distinct, intentional step.