Part B of the ModelBuilder sequence. Part A got a working model on the canvas; today we make it readable, make it reusable, and document it, and then we spend the last third of class on Lab 1: what the rubric rewards, what a complete submission looks like, how to know whether your answer is right, and how peer review works. The window on the right is where we end up: the Cities Near Rivers model with four P markers, and the tool dialog those four parameters produce, side by side in ArcGIS Pro 3.7.

stamp:begin

stamp:end

Set expectations: nothing new gets added to the analysis today. Everything on this list is about turning a canvas that only you can run into a tool that anyone can run, and then about finishing Lab 1 well. The strip is where the model will be by the middle of class: readable names and three P markers.

Hand out the cookies first, then put this up. Ten minutes. Blue ovals for ingredients, yellow boxes for what you do to them, green ovals for what comes out: that is the only rule. Walk the room and look for two things, someone who drew one box called "make cookies" and someone who is still drawing the wheat field; both go on the document camera for the next slide. The picture goes to Learning Suite by 9:30 am, fifteen minutes after class.

Put this up once everyone has drawn, and have them exchange papers before you show it. Peer grading is the point: they have to read somebody else's diagram, which is the first time most of them find out that a model is a communication device. Watch what happens when engineers see an equation. The room sits up — and then, a beat later, works out that it is a silly one. Give them a moment with it; it is the best moment in the hour. It is also, deliberately, a WRONG equation, and the next two slides are where that comes out. N rewards piling on nodes, so the eleven-tool cookie beats the one-tool cookie every time — and the very next slide asks whether a bigger model is actually better. Do not resolve the contradiction for them. Ask who got the highest score, then ask whose model they would rather be handed if they had to bake the cookie. The answers are usually different people, and the conversation after that is the lesson.

Rule 1 is about consistency, not about ovals. Ovals and rectangles are what Bolstad draws and what older ArcGIS used; ArcGIS Pro today rounds the data elements and squares off the tools. Both are on the figure. A student who invents their own pair and holds to it has followed the rule, and saying so out loud is worth more than the convention itself — the reader has to be able to tell the two apart at a glance, and that is the whole requirement. The nouns-and-verbs test is what does the work. If someone cannot say their tool shape out loud as an action verb, it is not a tool, it is a stage of data wearing the wrong box. Rule 5 catches everybody, and it is not arbitrary. A tool's output IS data, so if two tools touch, a dataset has gone missing and nobody can see where the intermediate went. Same for two data shapes: something happened in between and it was not written down. That is exactly what makes a real ModelBuilder canvas unreadable.

Three sketches of the same cookie. The one-tool version is a legitimate model: it says what goes in and what comes out and hides everything else, which is exactly what you want when the recipe is not the question. The middle one is what most of the room drew. The long one starts from a baby chicken and a wheat seed and names every intermediate product; it is not wrong either, and it is the one you want when a step might change (a different flour), when someone has to check your work, or when you need to reuse a piece (the flour chain is a model of its own). Ask which one they would hand to a stranger, and which one they would hand to an auditor. The answer we are steering toward: a model is a communication device as much as an automation device, the right size depends on who has to read it, and every extra node is something else that can break.

Figures: the one-tool and eleven-tool sketches are drawn by tools/week02_cookie_sketches.py in the style of the student sketch in the middle (green marker, ovals and boxes, handwriting font, rendered to PNG).

This is the middle sketch redrawn in ModelBuilder's own element style, the same style as Part A's pie recipe: rounded rectangles with an icon panel for data, square boxes with a hammer for tools, a connector for every ingredient, and a value variable with a P marker for the oven setting. Build it live if there is time: create five empty tables in the project geodatabase, drag them onto a new model, add Merge and rename it Mix, add Copy Rows and rename it Bake, rename the outputs dough and cookies, and run it. The tools are stand-ins; the vocabulary is the point: data, tool, derived data, connector, parameter. Figure drawn by tools/week02_cookie_model.py.

Discussion slide, not a lookup. Three canvases for one question, all drawn in ArcGIS Pro's element style. Buffer + Intersect creates real intermediate data you can inspect, which is good for teaching and bad for disk space. Select Layer By Location is one tool instead of four but leaves you with a selection rather than a feature class, so Copy Features follows it. Near writes NEAR_FID and NEAR_DIST onto the input, which is a side effect on your data, and then a Select on NEAR_FID does the classifying. The counts differ by one because Option 1 measured 10 miles on a projected plane and Option 2 measured it geodesically; one city sits right at the edge. "Correct" is not the same as "smallest", and neither is the same as "easiest to explain". The three diagrams come from tools/week02_three_ways.py; the map is Option 2's selection in Pro 3.7.1.

This is the single most common "my model did nothing" complaint. The model ran fine; the output just went to the geodatabase without being added to the map. The menu on the right is the Cities_Near_Rivers output element in ArcGIS Pro 3.7.1, with Add To Display already checked from Part A; show the check mark going on and off.

Colored means ready: blue inputs, yellow tools, green outputs. Gray means "not ready", and it propagates downstream, so always fix the leftmost gray element first. The strip is the Part A model with the Buffer distance deleted: everything upstream of Buffer is still colored and everything from Buffer on is gray. Hovering gives you the whole parameter list without opening the tool; "Distance [value or field]:" with nothing after it is the answer.

Build and debug incrementally. A five tool model that you only ever run end to end takes five times as long to debug. Point out Messages: that is where the real error text lives, not in the canvas. The menu is the Intersect tool's right-click menu in ArcGIS Pro 3.7.1.

Compare the two strips. "Project (2)" tells you which tool ran, twice. "Project to Equidistant" tells you why. "us_rivers" is a file name; "Input Rivers" is what the data means, and it is also the label that shows up on the tool dialog when the model is run as a tool. Renaming an element does not rename the data on disk, and it does not rename the model itself; the model's Name lives in Properties, General. Both strips are the same model in ArcGIS Pro 3.7.1, before and after ten renames.

This is the hinge of the whole lecture, and it is what Part A's model looks like as a tool: nothing to fill in. Without parameters, a model is a recording of one specific analysis. With parameters, it is a tool.

This is Lab 1 Step 10 and Lab 2 Step 5. Sometimes the thing you want the user to control is not a dataset but a setting inside a tool; Create Variable pulls it out onto the canvas, and the submenu is exactly the Buffer tool's own parameter list, so what you can expose depends on the tool. ArcGIS Pro drops the new variable on top of the tool's input, so drag it clear. Toggle the P on and off so they see the marker appear. Both captures are ArcGIS Pro 3.7.1 on the Part A model.

Double-click runs the model as a tool; right-click and Edit opens the canvas. Students mix these two up constantly. The dialog is the model with exactly one parameter, the distance we just created: a Linear Unit box with its own units list. This is the payoff of the previous slide, and it is what Lab 1's tool dialog looks like once the two buffer distances are exposed.

Left to right on the canvas: Input Rivers is a P because the user may choose which rivers; Distance is a P because they will certainly change it; Cities Near Rivers is a P because the user chooses where the answer gets written. The dialog lists the three in that order, the distance as a Linear Unit with its units dropdown. The warning triangle on the output just means that feature class already exists and will be overwritten. Now the same model answers "cities within 5 km" and "cities within 25 km" without anyone opening the canvas.

The right-hand capture is from the Lab 1 run: identical move, identical menu, and the dialog it produces if you stop at Step 10 without renaming anything. The rubric's "tool-dialog capture with the two distances exposed" is worth more when the two boxes say which distance is which.

Un-documented models are write-only. Six months later you will not remember which of the three buffers mattered. Make the case that metadata is part of the deliverable, not an extra. The menu on the right is Pro 3.7.1's: Edit Metadata is the exact label, with View Metadata just above it.

This is the Item Description metadata style, which is the default and is plenty for a class model. The four entries under Syntax are exactly the parameters we created, Input_Rivers, Cities_Near_Rivers, Distance__value_or_field_, Input_Cities, so the parameter names you chose become the documentation headings. In the capture the Summary and Usage are written and the four parameter explanations are still empty; the next slide shows what that looks like from the reader's side.

Compare this against the help page of any built-in ArcGIS Pro tool: same layout, same sections. That is the standard your model is being held to. The Description and Usage came from the editor on the previous slide; every gray "There is no ..." line in this capture is a gap the author left, and the four parameter explanations are the ones that matter most to whoever runs the tool.

Every number here is copied from the rubric at the bottom of the Lab 1 page. Two things to point at. First, the model is worth as much as either map, and half of its points are "the counts match the check values": the lab gives you numbers to check against, so use them. Second, the self-assessment is not optional; the grader compares your scores with theirs.

The map on the left is the example baseline layout from the Lab 1 page, built from the same run the check values come from. Walk the list: it is the Deliverables section of the lab, in order. The thing students most often leave out is the model description; the thing they most often get wrong is a screenshot of the canvas at 40 percent zoom instead of an export.

Point at each element on the example as you go: the title with the threshold in it; the legend that says "Irrigated cropland", not "NDVI_reclass"; the inset at Elberta with its red extent box; the text box that admits how much of the county the class covers. The rubric's map rows are exactly this list.

The Learning Suite entry for today promised "how accurate are the results, how can we validate the model." The honest answer has three parts. Against the check values, which catch mechanical errors. Against your own criteria, which asks whether each one earned its place. And against the scenarios, which is the only real test of whether the recommendation is robust. The two maps are the lab's example pair: same model, one number changed.

The lab requires this: a named reviewer and a sentence on what changed. Pair people up now if there is time. Reviewing against the rubric is the point; "looks good" is not a review. A report nobody else has read is a draft.

TODO(instructor): a one-slide look at an anonymized prior-year report page was planned here ("the analysis is the same, the deliverables are different"). No prior-year PDF is on this machine; supply an anonymized page and it can be added as a slide with a one-line caption. Fall 2026: the two named prior-year PDFs attached to the Learning Suite Thursday entry are shown live instead.

The habit to leave them with: whenever you catch yourself doing the same five clicks twice, build the model, expose the two or three things that actually change, and write the metadata while you still remember it. Both dialogs are ArcGIS Pro 3.7.1. The Lab 1 one is exactly what a student gets after Step 10 if they stop there: it works, and the labels are unreadable. The rubric's "tool-dialog capture with the two distances exposed" is worth more when the two boxes say which distance is which.

Five minutes, in pairs, while people pack up. The item that splits the room is the tool-feeding-a-tool sketch: half the class calls it fine because the missing dataset is "obvious", which is the whole argument from the cookie rules - a tool's output IS data, so two touching tools mean an intermediate nobody wrote down. The 256 versus 257 item is the other one worth a show of hands; if nobody says "projected versus geodesic", say it. No signal in the room: put the URL on the board and read the items aloud, they work fine spoken.

Revision notes (2026-09-09, evening): the parameter sequence now follows the distance. Slide 13 creates the Distance variable from Buffer and marks it (new bubble with a P); slide 14 opens the model with the distance as its only parameter (new capture, mbb-tool-dialog-distance-parameter.png, ArcGIS Pro 3.7.1); slide 15 adds the input and output for three parameters; the old "create a variable" and "then make that variable a parameter" slides fold into these, and the Lab 1 tie-in slide keeps the Lab 1 menu beside the Lab 1 dialog. The one-parameter (Input Rivers) and two-parameter dialog captures are no longer used. Revision notes (2026-09-09, later): the quiz question mark is gone from the cookie review and how-many-ways slides; how-many-ways now shows three ModelBuilder canvases (tools/week02_three_ways.py) with the map small at the side; the four save-you-an-hour slides and the two parameter slides carry an orange "You try it" fragment (theme class .tryit) so the class stops and does each move on their own Cities Near Rivers model; the section lead tells them to open or rebuild it. Revision notes (2026-09-09): a "Model a cookie" activity slide (the instructor's wording) now precedes the cookie review; the review slide shows three sketches of the same cookie (one tool, the student sketch with two tools, and an eleven-tool version back to a baby chicken and a wheat seed; the two new ones are drawn by tools/week02_cookie_sketches.py in the student sketch's green-marker style and rendered to PNG); and the tidy cookie model is now an SVG in the ArcGIS Pro 3.7 element style (tools/week02_cookie_model.py), matching Part A's pie recipe, with the oven setting shown as a value variable with a P marker. Revision notes (2026-09-08): every ArcGIS Pro capture in Part B replaced with ArcGIS Pro 3.7.1 captures taken the same way as Part A's (Sept 8, 175 % display scaling, project C:\Ames\Week02\CitiesRivers.aprx, model Cities Near Rivers). The Sept 3 "RiversDemo" captures were from an older ArcGIS Pro (oval elements) and are gone. New this session: - Canvas strips: default and renamed element names, gray-element strip, first P marker, two and three parameters, the Distance variable wired into Buffer; all screen grabs of the canvas at 105 % zoom. - Right-click menus: Rename, Add To Display (checked), Run/Messages on a tool, Create Variable > From Parameter > Distance, and the hover tooltip on a gray Buffer. - Catalog tree with the model; Geoprocessing pane with one, two, three and four parameters; the whole ArcGIS Pro window (model plus its four-parameter dialog) on the title slide. - Metadata editor (Item Description, Tags/Summary/Usage filled, parameter explanations empty) and the View Metadata page, each stitched from three or four scrolled captures. - The Lab 1 model's own tool dialog from C:\Ames\Lab01\Lab01.aprx replaces the ArcMap-era watershed dialog on the "Going forward" slide, and the slide now says why the labels there need renaming. - The model in CitiesRivers.atbx now carries the renames, four parameters and the metadata; the Part A state of the toolbox and project is archived in C:\Ames\Week02\Backup_partA. Revision notes (2026-09-07): Part B revised against slides/week-02/LECTURE_PLAN.md. 20 slides -> 30. - Kept every RiversDemo capture from the Sept 3 conversion; they remain the quality bar. - New ArcGIS Pro 3.7.1 captures (Sept 7, 175 % scaling, C:\Ames\Week02\CitiesRivers.aprx): the Catalog right-click menu showing Edit Metadata (closes the wording TODO), the model opened as a tool with No Parameters, and Select Layer By Location with its map (257 geodesic vs 256 projected, the "how many ways" discussion). - New slides: the tidy cookie model (HTML diagram in ModelBuilder colors; a real-canvas version was attempted and abandoned, the speaker notes say how to build it live), "Without parameters, a model is a recording", and the five-slide Lab 1 clinic: rubric strip (values copied from the lab page), complete submission, publication-quality map, is the answer right, peer review. - Reused from Lab 1 (copied with mbb- prefixes): the two example maps, the Create Variable menu. - Infographic: mbb-peer-review.png (OpenAI gpt-image-1, medium). A generated rubric strip was rejected because it invented scores; the rubric is HTML with the real point values. - Still open: reading chapter, quiz date, Lab 1 due date, and the anonymized prior-year page.

Remind them that the lab deliverable includes the model description and the self-assessed rubric, not just the maps.