Build golden path template registry — lab audio overview

Host: Welcome back to the AI Developer Platform Engineering podcast. You're in the chapter on Internal Developer Platform Vision — which is about building the shared system your organization's engineers use to ship AI services without reinventing the wheel every time. This discipline matters because as AI teams grow, the difference between "weeks to production" and "hours to production" is almost always the platform underneath them. Today's skill is a core piece of that platform. Expert: Picture a mid-sized company — maybe three hundred engineers, a dozen teams, all suddenly being asked to ship AI-powered features. One team wants to build a document summarizer. Another wants a customer support assistant. A third wants a code review helper. Without a platform, each team starts from a blank page. They each pick their own model provider, wire up their own logging, invent their own way to handle retries, and six months later you have twelve slightly different AI services that nobody can maintain. Now imagine instead that when a team wants to start, they pick from a short menu — "document summarizer starter," "chat assistant starter," "retrieval pipeline starter" — and they get a working, opinionated, production-shaped setup in minutes. Those menu items are called golden paths. They're the paved roads your platform team blesses. And to offer them, you need a place to store them, version them, and check that they're well-formed before anyone uses them. That's what this exercise is about. Host: Got it — so golden paths are the paved roads, and we need a system to manage them. In the previous exercise, you built the structured data shapes that describe a service catalog entry — things like service name, configuration, and dependencies, using a Python library called Pydantic that validates data as it's created. Now you're extending that foundation. So what exactly are we building here? Expert: You're building a template registry. In plain language, that's a small, in-memory library that holds golden path templates and hands them out when asked. Each template describes a workflow — a sequence of steps an AI team would follow to stand up a common kind of service. The registry needs to do four jobs. First, store templates so they can be looked up by name. Second, track versions, because templates evolve — version one of the summarizer template might be different from version two, and teams already using version one shouldn't be disrupted. Third, keep the steps of each template in the right order, because workflows are sequences — step two depends on step one finishing. And fourth, validate the parameters each template declares, so when a team picks a template and fills in blanks like "which model" or "what's the maximum token budget," the registry can catch bad inputs before anything breaks. Here's the key idea — the conceptual shift. A template isn't code that runs. It's a recipe. Think of a cookbook: the cookbook doesn't cook dinner, it describes how dinner gets made. Your registry is the cookbook shelf. It holds recipes, tells you which editions exist, and makes sure each recipe is actually a recipe — ingredients listed, steps numbered, nothing missing. The actual cooking happens later, somewhere else in the platform. Keeping that separation clean — recipe storage versus recipe execution — is what makes platforms maintainable. Host: That's a helpful frame. Before people dive in — what's the part that tends to trip folks up on this one? Expert: The tricky part is versioning. It sounds simple — just attach a version number to each template — but the moment you have two versions of the same template in the registry, you have to decide what happens when someone asks for it by name without specifying a version. Do you give them the latest? The latest stable one? Do you refuse and make them ask explicitly? There's no universally right answer, but you need to pick a rule and apply it consistently. My tip: default to returning the highest version number when no version is specified, but make it easy for a caller to ask for a specific version when they need reproducibility. The second trap is step ordering. It's tempting to store the steps as an unordered collection and sort them later. Don't. Preserve order from the moment the template is registered, because if two steps accidentally swap places, the workflow silently produces the wrong thing — and silent failures in platform infrastructure are the worst kind. Validate order up front, reject anything malformed loudly, and you'll save yourself a lot of debugging. Host: Great warnings to keep in mind. So to wrap up — what will you actually be able to do after this exercise, and what's coming next? Expert: After this, you'll be able to take a collection of golden path templates, store them in a versioned registry, and hand them out to other parts of the platform on demand — with confidence that the steps are ordered correctly and the parameters are well-formed. That's a genuine building block. Your team can use this as the foundation for a self-service developer portal where engineers browse available starters, pick one, and kick off a new AI service from a trusted template. It's the difference between "everyone invents their own" and "everyone starts from a paved road." Next, you'll extend the validation story further. You'll use a standard called JSON Schema — which is an industry-wide way to describe what valid data looks like — to check catalog entries much more rigorously, and to produce clear error messages when something's wrong. Today's exercise gets the templates stored and ordered. The next one makes the gatekeeping serious. Thanks for listening, and good luck with the build.