The Trust Ladder: An Automation Framework from an Old Network Hand

I started out in networking, and for a long stretch I was the automation: a console cable into the first switch, working the config line by line until the whole stack was built. State lived in my head and a text file, and the only validation was whether I had fat-fingered a VLAN ID before I hit enter. On larger networks the work climbed a rung — changes staged in a lab, signed off by a change board, pushed across dozens of sites overnight, nobody to the pub until every site was green. None of it carried the names we use now: pilot sites were canary releases, the change discipline was ITIL, batching and documenting changes was branches and commits.

From there the path led off the network gear and into the platforms around it — virtualisation, then cloud, and eventually VMware Cloud Foundation and the automation that wraps it. The job kept changing shape, but the thread never did: take something I used to do by hand, and work out how much of it a machine can safely carry.

Why it matters now

The pressure to automate is not really about technology — it is about what organisations are now expected to deliver: change in minutes rather than weeks, the same result every time rather than a different one per engineer, and expensive specialists solving new problems rather than retyping the same change across a hundred boxes. Automation is how you get speed, consistency and scale at once — and how you stop losing good people to toil.

The good news is that none of it has to be invented. Software development has spent years perfecting the toolkit — CI/CD, version control, automated testing, code review, progressive delivery — and the practices map straight across to infrastructure. Version control is the documented “what”. Code review is the sign-off, inline and fast. Canary and blue-green deploys are the pilot site, with rollback as a command rather than a panic. Same rigour as the old change board, at machine speed.

The ladder

This did not start as a framework — it started as me trying to explain to a customer where a process actually sat, and what the next honest step would be. It pulls together established practice (Google SRE, the DORA research, CNCF progressive delivery, platform engineering’s paved roads), stacked into the order a process earns trust.

It identifies where a process sits today and describes the next level of automation if it were to change — a “you are here”, and a “to get there, these things need to occur”. It does not make the decision for you.

flowchart BT
  R1["A human does it<br/>fully manual"]
  R2["A human approves it<br/>machine proposes, a person says go"]
  R3["A human is notified<br/>machine acts on its own, reports every action"]
  R4["A human is on call<br/>machine acts silently, escalates on trouble"]
  R5["Fully unattended<br/>machine runs, no one watching each operation"]
  R1 --> R2 --> R3 --> R4 --> R5

A process can move up several rungs in one change — how far depends on the complexity and criticality of what is being changed. The second rung carries most of the weight: approval usually means choosing from a constrained set of options, and it runs both ways — you can drop back to it when a process has earned less trust than you gave it.

What lets a process climb: observability (you can see what it did), a clean rollback (it is reversible), automated testing, version control and infrastructure-as-code, guardrails enforced as policy, and small, progressive change that keeps the blast radius low.

What keeps it on a lower rung: blast radius too high to risk unattended, no clean rollback, too rare to bother, a compliance signature required, plain human nature, a process too complex or with no tooling to do it well, or simply no real pressure to improve it.

A key part of this is breaking a process down to its atomic steps. A process is rarely one thing — it is a chain of smaller actions, and they do not all sit on the same rung. Split it apart and you can take the safe, repeatable steps all the way to unattended while holding the risky one at approval, rather than judging the whole process by its most dangerous moment.

And it is rarely one human, either. Those steps usually cross several disciplines — network, security, storage, application — each with its own requirements, its own tools and its own systems of record. Breaking the process down exposes those handoffs, and it is the handoffs, not the individual steps, that are usually the hard part to automate. This is where the “we still need plumbers” truth bites: automation and integration connect the pieces, but policy and communication are the real glue.

Take a single “deploy a new environment” request. Broken into its atomic steps, it looks less like one task and more like a web of dependencies across teams:

graph LR
  A1(("Intake"))
  T1(("Storage"))
  N1(("IP /<br/>subnet"))
  S2(("Identity<br/>& secrets"))
  N2(("DNS"))
  S1(("Firewall<br/>policy"))
  C1(("Compute"))
  N3(("Load<br/>balancer"))
  P1(("Deploy<br/>app"))
  O1(("Monitoring"))
  P2(("Validation"))
  A2(("Handover"))
  A1 --> N1
  A1 --> S2
  N1 --> N2
  N1 --> S1
  N1 --> C1
  S2 --> C1
  S2 --> P1
  T1 --> C1
  C1 --> N3
  C1 --> P1
  N3 --> P1
  S1 --> P2
  N2 --> P2
  P1 --> O1
  P1 --> P2
  O1 --> A2
  P2 --> A2
  classDef svc fill:#5b6b8c,stroke:#3f4a63,color:#fff,stroke-width:2px;
  classDef net fill:#2f7dd1,stroke:#1c5fa6,color:#fff,stroke-width:2px;
  classDef sec fill:#c2497a,stroke:#963a60,color:#fff,stroke-width:2px;
  classDef sto fill:#c77d1a,stroke:#9c6213,color:#fff,stroke-width:2px;
  classDef cmp fill:#2f9268,stroke:#216b4d,color:#fff,stroke-width:2px;
  classDef app fill:#7d54bf,stroke:#5e3f93,color:#fff,stroke-width:2px;
  classDef obs fill:#1f8b9c,stroke:#166675,color:#fff,stroke-width:2px;
  class A1,A2 svc;
  class N1,N2,N3 net;
  class S2,S1 sec;
  class T1 sto;
  class C1 cmp;
  class P1,P2 app;
  class O1 obs;

You do not have to take the whole thing to the same rung: the safe, high-volume steps (IP, DNS, monitoring, validation) can run unattended while the sensitive ones (firewall, identity) stay at approval. The breakdown shows exactly where those lines fall.

Building it into the stack

A ladder is no use unless it lives somewhere real. A typical stack has five pieces: a source of truth (the authoritative state you automate against), version control and a pipeline (change described, tested and delivered automatically), an orchestration engine (the thing that performs the action), guardrails and observability (control over what may happen, and sight of what did), and a contract — the stable, documented promise consumers call.

The contract is the piece that matters most. External systems do not want to know which vendor API changed this quarter or how authentication is handled — they want a promise that behaves the same way every time: give me an address, give me a network. Keeping that stable is what lets everything above it move quickly and safely.

In the diagram, the contract is the link between the nodes — clearly defining it is the key to the whole process.

This is the framework and stack I have been pulling together from research, customers, experience and a dash of AI. It is not definitive, and not my company’s official line — but the act of writing it down helps me articulate what I am seeing, and it is the guide I will be using as I work through my lab. The first worked example is IPAM with NetBox, a process I have taken all the way to unattended.

Pete