Part 3 of 3 — Engineering Intent Series -- Inside the Machine: The ISL Build Pipeline

In Part 1 we identified the problem. In Part 2 we dissected the spec format. Now we go inside the engine that transforms intent into production code — automatically, verifiably, and repeatably. This is the ISL Tooling Engine . It has two distinct phases: Build and Generate . Phase 1: The Builder Real software is never a single file. A LoginForm depends on UserAuthService , which depends on User domain model, which depends on AuthStatus enum. Each of those has its own .isl.md spec file. The ISL Builder scans your entire specification folder, identifies all @Reference tags, and builds a Directed Acyclic Graph (DAG) of your system: AuthStatus (enum) └── User (domain model) └── UserAuthService (business logic) └── LoginForm (presentation) This graph is not documentation. It's the build order. Topological Sort The Builder performs a topological sort on this graph — the same technique used by real compilers, package managers (npm, cargo, gradle), and build systems like Make. The rule is simp