![[IBN] Modeling Intent: The Data Models That Don’t Collapse at Scale](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,quality=80,format=auto,width=720,onerror=redirect/uploads/asset/file/0a0106ad-a755-48d3-b155-c5616825a2ae/ibn2.jpeg)
This is the second article in this [IBN] series. Make sure you check out the first and following parts!
If the first article of this series was the “you need a closed loop” argument, this second article is the part everyone asks for next, usually with a skeptical squint:
“Okay. Show me the intent.”
Not a PowerPoint abstraction, a vendor demo, or a set interface xe-0/0/0 unit 0 family inet address… wrapped in a Jinja template.
Show me what intent looks like when:
The network has multiple regions and POPs,
multiple vendors,
multiple teams,
multiple tenants,
multiple services,
a constant stream of change,
and a constant fear that your “model” will become an unmaintainable monster.
That’s what we’re doing here.
We’re going to build an intent model the way you build a software interface at scale: stable contracts, strict types, explicit invariants, and testable expectations.
And we’ll do it while keeping one promise:
Intent should read like a human declaration of outcomes and constraints, but behave like a machine-validated API.