Design-driven automation treats the design of a network — its topology, roles, relationships, and constraints — as an explicit model that exists independently of any device's running configuration. That model becomes the thing you reason about: the source of intent that configuration, validation, and change all refer back to.

This talk looks at what that means once you're operating a real network, not sketching one. We'll walk through the lifecycle: expressing intent as a design, turning it into configuration, and (the hard part) keeping the two in agreement as the network drifts, as tickets land, and as people make changes out-of-band. We'll dig into how drift is detected and interpreted, why reconciliation is harder than pushing config, and how a design model changes the way operators handle refactoring and unplanned change.

The same property that makes this work for humans, an explicit statement of intent to check reality against, is also what keeps the next wave of automation honest, whether that's a script or something smarter. We'll touch on that, but the focus stays on the mechanics operators live with today.

Throughout, we'll ground the concepts in real declarative provisioning systems, including open-source NetBox, using them as concrete examples of the patterns and trade-offs: where design-driven approaches pay off, and where they still struggle in production.

You'll leave with a clear mental model of design-driven automation, a realistic view of the reconciliation problem, and a sharper sense of where these approaches earn their place in day-to-day operations.