Kumu / Micro/Macro Econ / Perfect Competition / Stage 3
Stage 3 — Report the Findings
Objective
Stage 2 produced an answer: 10 / 20 / 30, $42,762. This stage is where the work becomes worth something — explain why that is the answer, in economics, using your own model's evidence, and then compress it into a recommendation somebody can act on.
An optimizer output you can't account for is a coincidence you happen to have committed.
Learn — the four things your model is trying to tell you
Every one of these is visible in your own workbook. None of them can be answered from a textbook, and an answer that reads like a textbook is the tell that the model wasn't consulted.
1. Why tomatoes stop at ~10 beds when they're the money crop
Tomatoes earn $8,800 a bed — four times what carrots do — and the optimizer still plants half the allowed amount. Because revenue per bed is not the decision variable; marginal cost at the margin is. MC hits $8,249 at bed 10 and $9,391 at bed 11, and the price line sits between them. Being the highest-revenue crop earns you nothing at the point where the next unit stops paying for itself. This is P = MC doing the only thing it does.
2. Which constraints bind — and what relaxing one is worth
Carrots and mesclun both stop at their bed caps with marginal cost still below price. That is a different situation entirely: the economics hasn't ended production, a fence has. One more carrot bed would add roughly $352 of profit; one more mesclun bed about $246. Those numbers are shadow prices — what the constraint costs you — and they are directly actionable: they say which ground is worth money to acquire, and how much. Note the slack constraints too: 64 total beds and 4 temp workers never bind, so neither is worth spending a dollar on.
3. The tomato MC dip at ~6 beds
Marginal cost falls, then resumes climbing. Diminishing returns never paused — hours per bed kept rising the whole way. What changed is the price of the marginal hour: the farmer's own 720 field hours ($34.72/hr) run out around there, cheaper temp labor ($17.36/hr) takes over, and for a few beds that wage drop outweighs the extra hours. Then diminishing returns win again and MC climbs through the price line.
The general lesson is worth more than the example: marginal cost reflects input prices as much as physical returns. Any real cost curve with a step change in an input price will do this. An analysis that ignores the dip has ignored the most interesting thing in the model.
4. Why grow crops that lose money on their own
Run any single crop by itself and it loses money at every quantity — the $20,000 of fixed cost swamps it. Yet the optimum plants all 20 carrot beds and all 30 mesclun. The resolution is MC vs AVC: fixed costs are paid whether or not you plant, so they have no business in the planting decision. Price exceeds average variable cost everywhere, so every bed contributes something toward the fixed costs the farm owes anyway. Standalone crops "lose money" only because each is being asked to carry the whole $20,000 alone. This is the short-run shutdown rule wearing farm clothes, and it is the single most transferable idea in the engagement — it is the same reasoning that keeps an airline flying a half-empty route.
Do — write the analysis
One to two pages in analysis/perfect-competition-analysis.md, plus at
least two figures exported or screenshotted from your workbook into
analysis/figures/. MC-vs-price charts are the obvious pair. Every figure has to be
referenced in the text — a chart nobody points at is decoration, and decoration earns nothing.
Cover all four questions above, and cite your cells. "MC rises due to diminishing returns" is a lecture note. "Carrot MC reaches $1,742 at bed 20, still $352 under price — the cap binds" is analysis. The difference is visible from across the room.
Close with one honest paragraph against your Stage 1 hypothesis: what you predicted, what the model found, and what your prior got wrong. Being wrong and precise about why is exactly what this paragraph is for; being vague about having been right defeats it.
Do — write the memo
The memo template — recommendation, why, the judgment call, what would change your answer — is on Deliverable templates.
Half a page in docs/decisions/perfect-competition-memo.md, written to whoever has
to sign off on the plan — a partner, a lender, or you next February. Briefs ask; memos answer.
You wrote the question in Stage 1; this is where you close it.
| What goes in it | What that means concretely |
|---|---|
| The plan | Plant 10 / 20 / 30 — and one sentence of reasoning a non-economist would accept |
| The judgment call | Both caps bind, and one is worth more to relax than the other. Which ground is worth buying first, and what is a bed of it worth? Your shadow prices turn into advice here |
| What would change your answer | One line. If tomato prices fell 20%, if a fifth worker were available, if a cap lifted — name the variable your recommendation is most sensitive to |
If the memo takes more than twenty minutes, the analysis hasn't finished its job. A memo that is hard to write is a diagnosis, not a writing problem.
Do — update the prompt log
Add a dated section for this engagement to the prompt-log.md at your repo root —
it accretes across every engagement rather than starting fresh each time. Log the sessions that
mattered: where AI explained something that finally landed, where it caught an
error, where it introduced one. Per session: date, tool, what you asked, what you got, what you
did with it. A curated record, not a transcript dump.
Then a reflection of 300 words or fewer. Where AI helped, where it was wrong, and — the part that matters most — how you verified. "It seemed right" is not verification. "I checked its MC formula against the labor function at q = 1 and it had dropped the exponent" is. If nothing it told you turned out wrong, document the checks that convinced you of that; "the AI was flawless" with no evidence of checking reads as "I didn't look."
Let AI keep the log — but only the half that is bookkeeping
Writing down what you did after you have already done it is the kind of chore that quietly
stops happening. You can hand that part over: a rule in your AGENTS.md — or a
.claude/skills/prompt-log/SKILL.md if your tool reads skills — telling the model to
append a dated entry after any substantive session.
After any session where you helped with graded work, append an entry to
prompt-log.md: the date, the tool, what I asked for, and what you
produced. Facts only. Never write the reflection, never fill in what you
got wrong, and never assess how I verified your output — those are mine.
The boundary is not a formality. The model may record what happened. It may not write the reflection, and it may not fill in "where it was wrong" or "how I verified" — an agent auditing its own errors has an obvious conflict of interest, and those two fields are the graded ones.
And note what automation makes easier: dumping. A log that appends everything is a transcript, and a transcript is worth less than four curated entries — it shows you were present, not that you were paying attention. If you automate the capture, budget a minute afterwards to delete the sessions that did not matter. Curation is the part being graded.
AI boundary for this stage: asking AI to critique your draft explanation of the MC dip is in bounds and worth logging. Pasting the case in and asking for an analysis is out of bounds — and it is obvious, because AI-written analysis explains the textbook rather than your workbook's numbers.
The one way AI may touch the analysis or the memo
Not as a writer — as a structural editor on a draft you have already committed. The order is what makes it legitimate, and it is not negotiable:
- Write the analysis and the memo yourself, and commit them. The commit is the control. Without it, "I only used it as an editor" is a claim nobody — including you — can check afterwards.
- Then ask a model to edit for structure: this paragraph belongs earlier; this claim is unsupported; this recommendation does not follow from this evidence; this sentence says the same thing twice.
- Apply what you agree with, in your own words, and commit again. The diff is the evidence. A reader can see exactly what changed and what it was before.
- Log the session.
What does not move: the reflection is never AI-touched. It is this stage's evidence that you can tell a good answer from a plausible one, and running it through the tool being evaluated destroys the only thing it measures.
Why the line sits here rather than one step earlier: a spreadsheet can be handed to AI because the check figures are an oracle — the numbers either reproduce or they don't. A memo has no oracle. Reviewing an argument you could not have written yourself feels identical whether the argument is sound or merely fluent, and telling those apart is the skill this stage exists to build.
Deliverable
| What | Where it goes |
|---|---|
| The evidence, with figures | analysis/perfect-competition-analysis.md + analysis/figures/ |
| The recommendation | docs/decisions/perfect-competition-memo.md |
| AI sessions + reflection | prompt-log.md (repo root) |
| The capability, now evidenced | capabilities/marginal-analysis/README.md — update the "exercised in:" line |
- P = MC evidence shown per crop, from your model's own numbers
- Binding caps identified, with shadow-price reasoning (~$352 carrots, ~$246 mesclun)
- Slack constraints named — 64 beds and 4 temp workers
- The tomato MC dip explained by mechanism, not merely observed
- The "grow at a loss?" paradox resolved with MC vs AVC
- At least two figures in
analysis/figures/, each referenced in the text - Figures render on the GitHub page, not just in your editor
- Honest paragraph comparing the result against your Stage 1 hypothesis
- Memo written: the plan, the judgment call, and what would change your answer
- Prompt log updated with curated sessions + a reflection of ≤300 words
- Reflection names something concrete you verified, and how
- Skill
README.md"exercised in:" line updated - At least two descriptive commits for this stage