You have the pieces now. You can make a model call, choose a model that fits, write a prompt that behaves like a spec, get output your code can use, give the model the facts it needs, and customize without overreaching. What is left is to put one model-backed feature into your build as a choice, with each of those decisions made and written down, instead of scattered through your code and your memory.
A Model Spec is a one-screen record of the seven decisions this part walked you through, the job, the model, the prompt, the output, the context, the customization rung, and the failure plan, written so the feature is something you chose rather than something that accreted.
The seven fields, one per decision
Each line of the spec is a decision a chapter in this part already taught you to make.
- The job. The one feature, in one sentence, and which run-time role it plays from Where AI fits in your product. If you cannot say it in a sentence, it is more than one feature.
- The model. Which model and tier you chose in Choose a model you can live with, and the one reason it fits.
- The prompt. Where the prompt lives in your code, and its rules, from Prompting is engineering, not wording.
- The output. The structure your code expects and the value checks behind it, from Get output you can build on.
- The context. Whether the model gets your facts by stuffing or retrieval, or needs none, from Give the model the facts it wasn't trained on.
- The lever. Which rung of the customization ladder you stopped at, and why you did not climb higher.
- The fallback. The spend cap, and what the feature does when the model is slow, down, or clearly wrong.
That is seven short answers on one screen. A field you cannot fill is not a gap in the spec, it is a decision you have not made, and the chapter that makes it is a short reread away.
Wire in the smallest feature first
With the spec filled, you build one feature behind it, the smallest useful version and not five at once, in the same week-one discipline from Write your Build Plan and start the build. The first hour has a structure you already know: open your tool, hand it the Model Spec, and ask for the backend route the spec describes, the call on the server with the key in an environment variable, structured output with the value checks, and the spend cap in place. Then read the diff the way Review what the AI built taught you, and run it once on a real input. At the end of that hour the run-time model is no longer an idea; it is a part of your product that you specified.
It feeds your Build Plan
The Model Spec is not a new document to file away; it is the detail behind one line of the plan you will write next. In the Build Plan you reach in Your Build, the "Where AI fits" field gives a run-time role a yes, and the Model Spec is what that yes will actually mean: the model, the prompt, the structure, the context, and the fallback that make the feature real. So this spec drops straight into that field, and the AI part of your build arrives already thought through.
Try it now
No setup: Download the Model Spec starter and fill all seven fields for a run-time feature you want to build, in plain sentences, no code. Hold yourself to one screen. Any field that refuses to fill points at one decision still open, and you now know exactly which chapter settles it.
With your tools: Hand the filled Model Spec to Claude Code and ask it to add the feature behind it: the server-side call with the key in an environment variable, the prompt in one place, structured output with value checks, and a spend cap. Read the diff, then run it once on a real input. If your tools are not set up yet, The Setup Clinic gets you there in one sitting. In Codex or Cursor the move is the same: hand over the spec and have it build the route exactly as written.
What comes next
This closes The Model Layer. The run-time AI that opened the part, the one you could only watch misbehave, is now a component you can specify, call, shape, and contain. Next is Your Build, where you scope and ship the whole product, with this Model Spec ready to drop into its plan.
Chapter Summary
- With the pieces from this part in hand, the last move is to put one model-backed feature into your build as a deliberate choice and write the decisions down.
- A Model Spec is a one-screen record of seven decisions: the job, the model, the prompt, the output, the context, the customization rung, and the fallback.
- Each field is a decision a chapter in this part already taught, so a field you cannot fill points at a chapter to reread.
- Build the smallest useful version of one feature behind the spec, not five features at once.
- The first hour: hand your tool the spec, get the server-side route with the key in an environment variable, structured output with value checks, and a spend cap, then read the diff and run it.
- Never ship the call without a spend cap and a plan for when the model is slow, down, or wrong.
- The Model Spec is the detail behind the "Where AI fits" line of the Build Plan you write in Your Build, so the AI part of your build arrives already thought through.
- Next up, Your Build scopes and ships the whole product, with your Model Spec ready to drop in.
Sources
- OpenAI, Anthropic, and Google developer documentation, 2026.
- The Builder's Stack Build Plan tool.