Generating Remediation from Detected State

Lesson 1's detection resultcompliant / non_compliant, from a real run
generate_remediation()reads non_compliant, produces one line per affected device
A remediation artifactno device touched yet -- this stage is pure data

Quick checkConcept check

What does generate_remediation() take as its input?

A hand-typed list of every device in the fleetLesson 1's actual detect_noncompliance() output -- specifically its non_compliant list -- not a separately maintained or assumed device listThe NetBox mock server's raw device recordsNothing -- it generates the same fixed configuration regardless of any detection

The code

capstone_lib.py (Lesson 2 portion)

def generate_remediation(detection):
  # One derived line per affected device -- nothing hand-typed, and
  # nothing generated for a device detect_noncompliance() didn't flag.
  return {entry["host"]: REQUIRED_NTP_LINE + "\n" for entry in detection["non_compliant"]}

Real, verified code. Deliberately the smallest solution compatible with the existing stack -- no Jinja2, no templating engine. The remediation for this scenario is exactly one line, so a dict comprehension over the detection result is sufficient and honest about the scope.

Quick checkScenario

Why does this lesson not introduce Jinja2 templating (Configuration & Template Automation) to generate the remediation line?

Jinja2 is required by NAPALM and can't be avoidedThe remediation here is one identical line for every affected device -- a templating engine would add a dependency and a rendering step to solve a problem a plain dict comprehension already solves completelyJinja2 doesn't work with Python dictionariesTemplating is never appropriate in network automation

Real, verified output

terminal output — real, verified run

--- Remediation generated from Lesson 1's detection ---
{
'RTR1': 'ntp server 10.10.10.2\n',
'RTR2': 'ntp server 10.10.10.2\n',
'SW-EOS1': 'ntp server 10.10.10.2\n'
}

Real, verified. Exactly the three devices Lesson 1 detected as non-compliant -- RTR1, RTR2, SW-EOS1 -- appear here. SW-JUNOS1, already compliant, is genuinely absent, not filtered out by a separate check.

Quick checkPredict output

If detect_noncompliance() had found zero non-compliant devices, what would generate_remediation() produce?

An error, since remediation always requires at least one deviceAn empty dict -- the dict comprehension iterates detection["non_compliant"], and an empty list produces an empty result, correctly generating no remediation for a fully compliant fleetA remediation line for every device regardlessThe function would hang waiting for input

What this stage does and doesn't do

No device touched yet

This stage is pure data transformation -- no napalm_configure, no connection, no device state changes anywhere in generate_remediation(). The remediation becomes real only once it's recorded as evidence (next lesson) and applied through the staged rollout (Lesson 4).

Quick checkScenario

A learner asks: "Couldn't this stage just apply the remediation directly, right after detecting it?" What's the answer, based on this module's locked workflow?

Yes -- that would be simpler and just as safeNo -- the workflow deliberately requires the remediation to be recorded as approved evidence in Git and read back before any device is touched, which is exactly what the next two lessons buildNAPALM doesn't allow applying configuration immediately after a get_config() callThis stage already does apply the remediation

Key takeaways

generate_remediation() takes Lesson 1's real detection result as input -- it does not assume or independently maintain a device list.
Real, verified run: exactly the three non-compliant devices from Lesson 1 (RTR1, RTR2, SW-EOS1) receive generated remediation; the compliant device does not.
Deliberately the smallest solution for this scenario -- a dict comprehension, not a new templating dependency.
No device is touched at this stage -- this is data generation only, feeding the next lesson's Git evidence.

Generating Remediation from Detected State

What you'll learn

From a detected gap to a generated fix

The code

Real, verified output

What this stage does and doesn't do