Kumu / Micro/Macro Econ / Perfect Competition / Stage 2

Stage 2 — Spec, Build, Audit

Delivered so far: the engagement brief, with your planting hypothesis on the record. Now you specify the model that can prove it wrong — and check that the one you get back is the one you asked for.

Objective

Produce a working model of the farm's decision, in the order a working consultant produces one. You write the specification first — every input named, the calculation logic, and the rules the finished model must pass. An AI builds the workbook from it. Then you audit what came back against the rules you wrote.

There is no starter workbook to fill in. Your spec is the template.

Learn — why the specification comes first

Building a spreadsheet from scratch used to be the scarce skill. It is not any more. What is scarce is stating a requirement precisely enough that a capable system produces the right artifact — and then determining whether it did.

The spec is the prompt. A precise specification tells the model exactly what to build and exactly what each result must equal, so the first build comes back close and your review is verification rather than archaeology. A vague one does the reverse: the model confidently builds the wrong thing, and you discover your own requirements one frustrating correction at a time.

There is a second effect, and it is the one that teaches you the economics. When you build by hand, every assumption you never stated gets quietly resolved as you type, and nobody — including you — finds out which assumptions were missing. Hand a half-formed spec to a model and the gaps come back as defects you can point at. The failure becomes diagnostic instead of invisible.

This is not AI doing your work. The standard is higher, not lower: someone who cannot specify the model cannot produce a correct one by any route, and someone who cannot audit it cannot tell that they have not.

Learn — what your spec has to get right

The engine of the whole model is one formula, and your specification has to state it unambiguously. Hours of labor needed for q beds of a crop:

hours(q) = q × hrs-per-week-per-bed × 36 weeks × (1 + dim%)^q

Strip out the exponential term and you get a straight line: every bed costs the same as the last, marginal cost is flat, and the model has nothing to say. The (1 + dim%)^q factor is what makes each additional bed raise the labor requirement of every bed — pest pressure spreads, harvest windows collide, you walk further. That is diminishing returns expressed as something a spreadsheet can compute, and it is why marginal cost slopes up and why "plant the whole farm in tomatoes" is an expensive mistake rather than an obvious win. A spec that describes labor as linear specifies a different model than the one the case describes.

Two conventions decide whether the cost numbers come out right, and specifying only one of them is the most common structural defect in this model:

One more thing to specify carefully: marginal cost is not guaranteed to rise monotonically here. It falls somewhere in the middle before climbing again. Do not write "marginal cost increases with quantity" into your spec — state the mechanism you expect rather than the shape you expect, and let the model produce the shape.

Write logic, not cell addresses

LABOR_HRS(q) = q × HRS_PER_BED × WEEKS × (1 + DIM_PCT)^q is specifiable — someone could build it without seeing your file. "Column D times column E" is not: it describes a spreadsheet that does not exist yet. You choose the names; the requirement is that they exist and are used consistently.

Do — specify

Write capabilities/marginal-analysis/spec.md before opening Excel. Half a page to a page, covering five things.

Start from the spec template

You do not have to invent the shape of this document. The spec template in Reference has the headings, an annotated example, and the named-range notation — copy it into spec.md and fill it in. It lives on this site rather than in the course repository because a spec is method, not this engagement: the same structure carries to the next one.

  1. Inputs, as a named contract. Every input with a name, its value, its unit, and its source in the case scenario.
  2. Structure. Every sheet or region and what it is for — inputs, cost structure, the marginal-cost schedules, the optimization, the checks.
  3. Calculation logic in named-range notation, never cell addresses.
  4. Validation rules. The check figures below, written in as acceptance criteria, plus the q = 1 hand calculation, plus "no error cells" and "every calculated cell contains a formula."
  5. Outputs. Name each result the model has to report.

Write it for an AI reader, because that is the reader. "A reasonable labor rate" is not a specification. The real test is whether somebody who has never seen this case could build the workbook from your document alone — read it once with that person in mind before you commit.

Commit the spec before you generate anything. The commit order is part of the deliverable.

Ask AI to find your gaps — not to fill them

A specification is hard to check by reading it, because you know what you meant. A model does not, which makes it a good instrument for finding the places where you assumed instead of said. Interrogating the spec is in bounds. Writing it is not — the judgment in this document is what the stage is grading, so every answer to every question below is yours.

Here is my model specification. Do not rewrite it, and do not fill in
anything that is missing.

1. List every place a builder would have to guess, and say what they
   would probably guess.
2. Name each term I use without defining it.
3. Ask me the questions whose answers are missing from this document.

Then stop. I will make the changes.

Then answer the questions in the spec and commit. If a model's guess would have been right, the spec still needed the sentence — a builder who guesses correctly and a builder who knows are only the same until the guess is wrong.

Do — generate

Hand the spec to an AI tool as-is. The three routes — a chat surface, a CLI agent pointed at your repository, or Claude for Excel if you have access — are on the AI Tools Lab, along with what each can and cannot do. A manual build directly from your spec is also permitted; the contract is graded, not the tool.

Re-explaining the model is a defect report

If you find yourself explaining the model in the chat window, that explanation belongs in the spec. Stop, add it to spec.md, commit the change, and regenerate. Every clarification you give verbally is a gap that would have reached a colleague, an auditor, or next year's you.

Then run the optimization. Objective: maximize profit. Changing cells: the three bed counts. Method: GRG Nonlinear with integer decisions. Constraints as the scenario states them — bed caps, 64 beds total, temporary workers ≤ 4. Every constraint-check cell green.

Never opened Solver? Ten minutes, once

Excel Solver in Reference covers installing it on Windows and Mac, the three inputs, and integer constraints. Two things there are worth knowing before you start rather than after: Excel for the web has no Solver — you need the desktop app, which your university almost certainly licenses to you for free — and what GRG Nonlinear is doing. It walks uphill from wherever the changing cells happen to sit and stops at the first summit it reaches, which is exactly why the audit below asks you to run it twice from different starting points. That check is not a formality.

Do — audit

AI output is a draft, not a deliverable. Run your validation rules against what came back and record the findings in a short section at the end of spec.md: what you checked, what you found, what you did. At minimum, run these five.

CheckWhat it catches
q = 1 by hand — one bed of tomatoes should need 1 × 2.5 × 36 × 1.10 hoursA dropped exponent, which is the single most common structural defect and invisible downstream
Cross-check against the Farm Profit Lab — take at least one intermediate marginal cost and compareAnything wrong in the middle of the model. The lab is a separate implementation of this same model, so agreement is real evidence
Two Solver starting points — 0/0/0 and 20/0/0A local optimum masquerading as the answer. If they disagree, that is a finding, not a nuisance
The check figuresEverything else, in aggregate
Formulas, not pasted values — spot-check that calculated cells reference your named inputsA number that is right today and wrong the moment an input changes

Your acceptance criteria

The answers are published on purpose. They are not the thing you are graded on — they are the test suite, and they belong in your spec before the build, which is what makes them acceptance criteria rather than an answer key.

CheckValue
Optimal mixTomatoes 10 · Carrots 20 · Mesclun 30 (60 beds)
Season profit$42,762
Standalone P ≈ MC pointsTomatoes ~10 · Carrots ~10 · Mesclun ~6 beds

A model that reproduces these with broken formulas fails inspection just as surely as one that misses them. And when a check fails, fix the spec and regenerate rather than patching the workbook by hand — a workbook that no longer matches its spec is a model nobody can rebuild.

Note the tomato marginal-cost dip at around 6 beds without explaining it. That is Stage 3's work, and it is the most interesting thing in the engagement.

AI boundary for this stage: the workbook is a means, so AI generating it from your spec is the assignment rather than a shortcut. The spec is not — it is where your judgment is read, so AI may critique it and find the ambiguity in it, but you write it. The audit is yours as well: a model can help you run a check, and it cannot tell you its own output is correct.

Deliverable

WhatWhere it goes
The specification, written first, with the audit findings added at the endcapabilities/marginal-analysis/spec.md
The workbook that satisfies itcapabilities/marginal-analysis/model.xlsx
What the capability is, and where it was exercisedcapabilities/marginal-analysis/README.md

Check yourself