One rules engine to run them all

Somewhere around the third product, we noticed we were building the same feature for the third time. MDM needed policy rules: if a device falls out of compliance, quarantine it. Desk needed routing rules: if a ticket mentions VPN, send it to networking. People needed workflow rules: when a start date is ten days out, order hardware. Three rule builders, three schedulers, three audit trails. Same machine, three coats of paint.

So we extracted it. Every OhKube automation is the same primitive: a trigger (an event or a schedule), zero or more conditions evaluated against the shared data model, and a list of actions. The engine doesn't know what a device or a ticket is. It knows entities, fields, events, and actions that products register.

What sharing one engine buys

The obvious win is consistency: learn the rule builder once, automate everywhere. The much bigger win is that rules can cross products, because conditions read the shared data model. "When a device is marked lost, open a Desk incident, notify the owner's manager from People, and suspend the device's AI provider keys" is one rule, not an integration project. On a four-silo stack, that sentence is a quarter's roadmap.

The guardrails matter more than the engine

Automation that can touch everything can also break everything, so the engine is paranoid by design. Every action is idempotent, so retries are safe. Cascades are depth-limited and cycle-detected, so two rules can't ping-pong a field forever. Every execution writes to one audit log with the full trigger-to-action chain, so "why did this happen" is a lookup, not an investigation. And every rule can run in dry-run mode against live data before it's armed.

One engine, many products. It's the least visible thing we've built and the one that makes the suite feel like a platform instead of four apps in a trench coat.