Automation Building Blocks

The same shape, formalized

"Start Here" showed you this shape informally, one lesson at a time: know what you're checking, know which devices, connect, run the command, look at what came back, and report on it. This module starts by giving that shape a name and taking each piece seriously on its own, because the rest of this module — inventory, state, idempotency, safe failure handling — is really just each of these pieces explained in depth.

Every network automation task, no matter how simple or how large, is built from the same seven pieces:

Input → Inventory → Connection → Execution → Output → Validation → Reporting

What each piece is actually for

Input is the goal, stated plainly, before anything else happens: "confirm every access switch in Building 3 has NTP synced." Nothing downstream makes sense without this — you can't validate a result against an expectation nobody wrote down.

Inventory is the answer to "which devices?" — a defined list, not "all of them, probably." Get this wrong and everything after it runs perfectly against the wrong set of switches. The next lesson is entirely about doing this properly.

Connection is opening a session to a device — almost always SSH for a Cisco switch or router — so a command can actually be sent to it. Conceptually, this is the same login you'd do by hand; automation just does the typing.

Execution is running the actual command: show ntp status, show running-config, or pushing a configuration change. This is the part most people picture when they hear "automation," but it's only one of seven pieces — and on its own, it doesn't tell you anything.

Output is the raw data that comes back from execution — the literal text of show ntp status's response. Output is not yet an answer to anything. It's just what the device said.

Validation is where output becomes meaningful: comparing it against what you expected. "The switch responded" and "the switch is actually synced" are different claims, and validation is the piece that checks the second one, not just the first.

Reporting turns the validated result into something a person can act on — "38 synced, 2 out of sync: SW-14, SW-27" — instead of 40 raw command transcripts nobody has time to read one by one.

One process, not seven separate tasks

It's tempting to think of these as seven independent tasks you could mix and match. They're not — they're one pipeline, and each piece depends on the one before it. Execution without a defined inventory has nothing to run against. Validation without output has nothing to check. Reporting without validation is just forwarding raw data and hoping someone reads all of it.

This matters because it's the same pipeline whether you're checking one switch or coordinating a change across five hundred. The pieces don't change — only the size of the inventory does. That's exactly why this shape is worth learning properly now, before this module gets into what's genuinely different at scale (idempotency, safe failure handling) in the lessons ahead.

Output and validation are not the same thing

This is the distinction that trips people up most, so it's worth stating plainly: output is what a device says. Validation is whether what it said is correct.

If show ntp status returns cleanly with no error, that's output — the command worked. Whether the switch is actually synced is a separate question, answered by reading that output and comparing it against what "correct" looks like. A script that only checks "did the command run without error?" and stops there hasn't validated anything — it's confused output with validation.

Why the shape doesn't change with scale

Checking one switch by hand and checking five hundred with a script both follow the exact same seven pieces — the same input, the same kind of inventory (just longer), the same connection method, the same command, the same need to validate and report. Nothing about the shape gets more complicated as the inventory grows. What gets harder is doing it reliably without automation, which is exactly the argument "Start Here" made.