by Phil Swainson | 22 December, 2025
In the first two parts of this series, I looked at automation from a very practical standpoint. First, how removing noise and unnecessary manual effort can make a measurable difference. Then, how inconsistent data quietly undermines even the best tooling.
This third part is about what happens once those basics are in place — when automation stops being something you bolt on, and starts becoming something you rely on.
Where Automation Usually Starts to Strain
What I’ve found is that the real shift happens when you stop asking “What action should this trigger?” and start asking “What do we actually know about this situation?”
That sounds like a small change, but it fundamentally alters how automation behaves.
Instead of encoding actions directly into scripts, you describe the conditions under which something should or shouldn’t happen. Decisions are evaluated based on context, not assumed based on a single signal.
That’s the thinking behind the rules-driven model we’ve been using with TOTUUS.
Changing the Way You Frame the Problem
The turning point comes when the focus changes.
Instead of asking “What action should we take?” the better question becomes “Why is this happening, and what do we know about it?”
That shift — from action to reasoning — is where next-generation automation begins.
Rather than hard-coding behaviour, we define intent. Rather than embedding logic inside scripts, we describe conditions under which behaviour should occur. Decisions are evaluated, not assumed.
This is the principle behind the TOTUUS rules model.
Context Is What Makes Automation Useful
On its own, an event doesn’t mean very much. What matters is what sits around it.
- Is this device critical or peripheral?
- Is this a repeat event or the first occurrence?
- Is the service already degraded elsewhere?
- Is this expected behaviour given the lifecycle state?
By bringing that context into the decision-making process, automation becomes more predictable, not less. Given the same conditions, it will behave in the same way every time — and that consistency is what builds trust.
There’s nothing clever or opaque going on here. It’s deliberately deterministic.
What Changes for the People Using It
One of the most noticeable outcomes of this approach isn’t technical — it’s behavioural.
Engineers stop second-guessing alerts.
They stop cross-checking three systems before acting.
They start responding earlier, because they understand why something has happened.
That’s when automation stops feeling like a liability and starts feeling like support.
From Automation to Insight
Once decisions are expressed as rules rather than scripts, you also gain visibility into why actions were taken. You can see which conditions were met, what context mattered, and how often certain patterns occur.
Over time, that turns automation into something more than a response mechanism. It becomes a source of operational insight — grounded in real behaviour rather than assumptions.
A Natural Evolution, Not a Leap
None of this requires ripping out existing tools or rewriting everything from scratch. Rule-driven automation builds on what’s already there. It simply introduces structure and intent where complexity would otherwise accumulate.
It’s a way of letting automation grow without becoming fragile.
Next-generation automation isn’t about being smarter than engineers.
It’s about giving engineers systems they can trust — systems that behave consistently, explain themselves, and evolve without surprises.
That’s the direction we’re taking with TOTUUS.
A Real Example, Without the Internals
In one recent engagement, this rules-driven approach was applied to large-scale alarm automation within a live network operations environment.
Rather than hard-coding responses into individual scripts, alarm behaviour was driven entirely by externally defined rules. Each incoming event was evaluated against its current state, historical context, and operational attributes before any action was taken.
The result wasn’t just fewer tickets or cleaner dashboards — it was predictable behaviour. Engineers could see why an alarm was suppressed, escalated, enriched, or cleared, and — just as importantly — could trust that the same conditions would always lead to the same outcome.
- Nothing “clever” happened behind the scenes.
- No guesswork. No black boxes.
- Just consistent decisions, made transparently, at scale.
- That consistency proved far more valuable than any single automation action.
