Capstone: Source of Truth to Safe Network Change

The complete pipeline, real and verified

NetBox-shaped source of truthLesson 1
Dynamic, multi-vendor Nornir inventoryLesson 1
NAPALM state collection + compliance detectionLesson 1
Remediation generated only for affected devicesLesson 2
Recorded as approved evidence in Git, read back from the commitLesson 3
Canary selected from the detected subsetLesson 4
Staged, gated rollout -- expand on PASS, rollback on FAILLesson 4
One structured, auditable report

Quick checkConcept check

What does this capstone combine that no single prior lesson -- in this module or anywhere else in the curriculum -- demonstrated alone?

A new automation framework not covered anywhere elseThe complete causal chain: a NetBox-sourced fleet, a real detected compliance gap, remediation generated from that gap, Git evidence read back and actually applied, and a staged rollout with a real gate deciding expand or rollback -- each piece already verified separately, now connected end to end for the first timeA faster version of Production Automation's own capstoneReal device testing against production infrastructure

The complete script

capstone_lib.py — run_capstone()

def run_capstone(netbox_url, fixtures_dir, repo_path, threshold=1.0):
  nr = load_fleet_from_netbox(netbox_url, fixtures_dir)
  detection = detect_noncompliance(nr)

  remediation = generate_remediation(detection)
  repo = init_change_repo(repo_path)
  commit = record_approved_change(repo, remediation)
  _, approved_config = read_approved_change(repo)

  affected_hostnames = list(remediation.keys())
  canary_nr, rest_nr = select_canary(nr, affected_hostnames)

  canary_result = run_stage(canary_nr, approved_config)
  decision = evaluate_gate(canary_result, threshold=threshold)

  report = {
      "detection": detection,
      "change_commit": commit.hexsha[:8],
      "change_message": commit.message.strip(),
      "canary": canary_result,
      "decision": decision,
      "expanded": {},
      "rolled_back": False,
  }

  if decision == "PASS":
      report["expanded"] = run_stage(rest_nr, approved_config)
  else:
      rollback_agg = rollback_stage(canary_nr)
      report["rolled_back"] = not rollback_agg.failed

  return report

The complete, real, verified orchestrator. Every function it calls was built and independently executed in Lessons 1-4 -- run_capstone() introduces no new mechanic, only the sequencing that connects them.

Quick checkIdentify the correct code

run_capstone() calls read_approved_change() and then passes approved_config into run_stage() for both the canary and the expansion. What does this prove about the rollout?

Nothing in particular -- it's just a variable nameBoth the canary application and the fleet-wide expansion apply the exact same configuration that was read back from the Git commit -- not a hardcoded string, and not two independently-typed values that could silently differThe canary and the expansion use different configurationsapproved_config is unused in this function

Scenario A — real, verified: canary passes, rollout expands

terminal output — real, verified run

{
"detection": {
  "compliant": [
    {"host": "SW-JUNOS1", "vendor": "junos"}
  ],
  "non_compliant": [
    {"host": "RTR1", "vendor": "cisco_ios"},
    {"host": "RTR2", "vendor": "cisco_ios"},
    {"host": "SW-EOS1", "vendor": "arista_eos"}
  ]
},
"change_commit": "f3b2bab4",
"change_message": "Approve NTP migration remediation for: RTR1, RTR2, SW-EOS1",
"canary": {
  "RTR1": {"applied": true, "validated": true}
},
"decision": "PASS",
"expanded": {
  "RTR2": {"applied": true, "validated": true},
  "SW-EOS1": {"applied": true, "validated": true}
},
"rolled_back": false
}

Real, verified, complete end-to-end output. One NetBox-sourced detection, one Git commit, one canary stage, one expansion -- all in a single run, every field traceable to a real execution step.

Quick checkPredict output

In this report, could a reviewer verify that "change_commit": "f3b2bab4" genuinely corresponds to the remediation that was applied, without trusting the report itself?

No -- the report's claims must simply be trustedYes -- git log against the same repository shows that exact commit hash and message (Lesson 3), and the commit's own tree contains the exact configuration line that appears in every "applied": true result hereNo -- Git commit hashes are not independently verifiableOnly NetBox can verify this, and it wasn't used

Scenario B — real, verified: canary fails, aborts, rolls back

Both outcomes, not just the success path

Every capstone in this curriculum since Production Automation has genuinely executed both a passing and a failing scenario. This capstone is no exception -- a separate, independently fixtured run represents the canary's configuration committing successfully but its post-change validation finding the required line still missing.

terminal output — real, verified run

{
"detection": {
  "compliant": [
    {"host": "SW-JUNOS1", "vendor": "junos"}
  ],
  "non_compliant": [
    {"host": "RTR1", "vendor": "cisco_ios"},
    {"host": "RTR2", "vendor": "cisco_ios"},
    {"host": "SW-EOS1", "vendor": "arista_eos"}
  ]
},
"change_commit": "29376077",
"change_message": "Approve NTP migration remediation for: RTR1, RTR2, SW-EOS1",
"canary": {
  "RTR1": {"applied": true, "validated": false}
},
"decision": "FAIL",
"expanded": {},
"rolled_back": true
}

Real, verified, complete end-to-end output. Detection is identical to Scenario A (same fleet, same starting state) -- the divergence happens only at the canary validation step, exactly where a real rollout's risk actually lives.

Quick checkScenario

Both scenarios show identical "detection" results. Why doesn't this cast doubt on the FAIL scenario's honesty?

It should -- identical detection results suggest the failure was fakedDetection depends only on the fleet's starting state, which is deliberately the same in both scenarios -- the two scenarios are designed to diverge exactly once, at the canary's post-change validation, isolating precisely what a real staged rollout is meant to catchThe detection step doesn't actually run in Scenario BThis is a coincidence, not a deliberate design choice

What this capstone never claims

Never claimed here

This ran against a freshly-built, stdlib-only NetBox-shaped mock, NAPALM's real mock driver, and a real local Git repository -- never real NetBox, never a real device, never a real Git remote. The integration logic -- detection driving remediation, remediation becoming evidence, evidence driving a gated rollout -- is genuinely verified end to end. No claim is made about any real production fleet's actual NTP configuration.

Quick checkScenario

How should a learner honestly describe what this capstone proves?

"This is a production-ready NTP migration tool, tested against our network.""A complete, real pipeline -- source of truth, detection, evidenced remediation, and gated rollout -- was genuinely verified end to end, on both a passing and a failing outcome, entirely against local mocks and a real local Git repository. No real NetBox, device, or Git remote was involved.""NetBox and Git were both fully tested in production.""Only the successful rollout was verified; the failure path is theoretical."

The curriculum is complete

Twenty modules, one continuous progression

This is the final lesson of the original 20-module curriculum -- from What is Network Automation? through Netmiko, Nornir, NAPALM, NetBox, Git, Production Automation, Real-world Projects, and this Capstone. Every mechanism in this lesson's script was taught, verified, and reused from somewhere earlier in that progression; nothing here was invented without a prior lesson to trace it back to.

You can revisit the complete path any time from the Learn page or see the full structure on the Roadmap.

Key takeaways

This capstone combines every stage of the module: NetBox-sourced detection, generated remediation, Git evidence read back from a commit, and a staged, gated rollout -- all verified together in one real, runnable script.
Real, verified run, Scenario A: detection finds 3 non-compliant devices; the canary passes; the same Git-evidenced configuration expands to the rest of the affected fleet.
Real, verified run, Scenario B: identical starting detection; the canary's change commits but fails validation; the gate aborts; rollback genuinely succeeds; the rest of the fleet is provably untouched.
Every field in the final report is independently auditable against a real artifact -- the Git commit, the fixture-driven NAPALM state -- not merely asserted.
No real NetBox, device, or Git remote was used anywhere in this module -- mock and local execution only, never overstated.
This is the final lesson of the original 20-module curriculum roadmap.

What you'll learn