Kumu / Micro/Macro Econ / Research Paper
Individual Research Paper — a global challenge, analyzed
The cases handed you a scenario, a framework, and a set of numbers somebody had already checked. This one hands you a world. Pick a global challenge, explain it with the economics this course taught you, and say what should be done about it — alone, on a question nobody has pre-solved for you.
The method does not change. Ask the question in a brief, define the work in a spec, build the argument in the open, log the AI, deliver something a reader could act on. What changes is that the rails are gone: you choose the challenge, you choose the framework, and you decide when the evidence is enough.
What the paper has to do
Four jobs, and a survey of a problem does none of them. The test is the same one every engagement in this course has been graded against: does this let somebody decide something?
- Identify and explain the challenge — what it is, who it affects, and why it is a problem now rather than in general
- Link it to the course's economics — micro (elasticity, market structure, incentives, who captures what), macro (growth, fiscal and monetary policy, trade), or both
- Analyze implications — what the mechanism is doing now, and what it does next under conditions you name
- Propose policy or strategy, and defend it against the obvious objection
At least one graph, chart, or diagram carries evidence the text actually uses. Not decoration — a figure your argument would be weaker without, labeled well enough to read on its own.
Choosing the challenge
Anything the course covers is fair game. The families that reliably produce good papers: poverty, inflation, or unemployment; climate change and environmental policy; global trade dynamics and supply-chain fragility; international debt; technological disruption and labor markets; geopolitical risk to food, water, or energy. That is a menu, not a fence — the strongest papers usually start from something the author has watched hit their own industry.
Scope beats ambition. A challenge narrow enough to put a number on is worth more than a sweeping one you can only describe. The Econ Policy Lab is a fast way to find out whether your challenge has a welfare story worth telling before you commit to it.
The workflow — five steps, in the repo you already built
No new tooling. This is the brief → spec → analysis shape the case work drilled, run once at full scale, in the same portfolio repo everything else this term landed in. If you have not stood the repo up yet, that is Stage 0, part 2, and it comes first.
| Step | What you produce | Where it lives |
|---|---|---|
| 1 · Ask | The challenge in your own words, the economic concepts it touches, and the analysis you plan to run | docs/briefs/research-brief.md |
| 2 · Plan | Data sources, the model and figures you intend to build, and the success criteria a finished paper has to meet | capabilities/economic-research/spec.md |
| 3 · Draft | Dated snapshots — one per working session that actually moved the paper | drafts/YYYY-MM-DD-draft.md |
| 4 · Log | Every AI session: what you asked, what came back, what you did with it | prompt-log.md at the repo root |
| 5 · Deliver | The finished paper, its figures, and a short reflection closing the log | analysis/research-paper.pdf · figures/ · prompt-log.md |
The capability slug is economic-research, and it earns a
capabilities/ folder for the same reason the cases did: this is the single biggest
demonstration of the method you will produce, and a reader following your portfolio should find it
where every other capability lives. Update its README.md so the "exercised in:" line
points at the brief, the drafts, and the paper.
Briefs ask; specs define; the paper answers. The deliverable templates carry the structure for the first two and the prompt log; the spec section is the one worth re-reading, because a spec written before the research starts is what stops a paper from becoming whatever the sources happened to be about.
The drafts are committed — that is the point
Every dated draft goes into the repository. Not the final version with a clean history behind it: the actual chain, including the one where the argument was wrong and the one where the figure did not support the claim you hung on it.
The messy middle is evidence, not something to hide. A draft that lives only on your laptop is invisible, and invisible work cannot be shown to anybody — not to your instructor, not to an employer reading the repo next year, not to you when you want to remember how the argument got there. The draft chain plus the prompt log is the pair that shows who wrote this paper, which is the whole reason the workflow exists.
One snapshot per real working session is the right cadence — not every save, and not one giant commit at the end. A history that shows the paper being built is worth more than a history that shows it appearing.
scratch/ is the one ignored place
Add scratch/ to your .gitignore and put genuine throwaway work
there — half-cleaned data pulls, abandoned outlines, the paragraph you already know you are
cutting. That is the pressure valve: messy work stays private without becoming invisible
history. Everything else in the workflow is committed. And remember that
history is permanent — the ignore rule goes in before
the first scratch file, not after it.
Two places it lands, and why
| Destination | What it is for |
|---|---|
| The LMS — a PDF of the finished paper | The reviewed copy. Peer review runs on this file and nothing else |
| Your repo — brief, spec, drafts, log, figures, paper | The evidence trail: the work, in the order it happened, for your instructor and for you |
Peer review here is double-anonymous: you read papers without knowing whose they are, and yours is read the same way. That is what makes the feedback usable, and it is also a constraint on what goes in the file. Your repository is named for you, so:
- The repository URL never appears in the paper — not in the text, not in a footnote, not in a figure caption, not in the bibliography.
- Keep identifying information off the paper's body pages, so a reviewer cannot tell whose work they are holding.
- Reviewers are never pointed at repositories. The repo is the instructor's evidence trail, not the reviewers' package — the two audiences read two different things on purpose.
When your turn comes to review, remember what a review is worth. "Great job" is worth nothing to the person receiving it: name what worked, name what did not land, and say what you would have done instead. You are being asked to judge, which means paying the kind of attention you would want paid to you.
Where AI fits, and where it doesn't
The boundary is the same one the cases enforced, and it is sharper here because the deliverable is prose. The AI may help you research and may attack what you wrote. It may not write the paper.
| Good uses — log them | Yours alone |
|---|---|
| Finding data series, sources, and counterarguments you had not considered — every one of them verified against the source before it enters the paper | Choosing the challenge and taking the position |
| Explaining a framework until it clicks, and quizzing you on whether it did | Writing the brief and the spec — human-first, exactly as in the cases |
| Attacking a draft: the weakest claim, the missing objection, the figure that does not prove what the sentence says it proves | The prose of the paper, the analysis behind it, and the reflection |
| Building a figure from a specification you wrote, and debugging one that came out wrong | Deciding what the recommendation is, and defending it |
A prompt log is not a formality here — it is the other half of the evidence. Log the sessions as
you go, because a log reconstructed at the end is a memoir, and reads like one. A short reflection
closes it: where AI helped, where it oversimplified or invented something, and one error you caught
and how you verified it. If you use an AGENTS.md, the
AI conventions page is worth ten minutes before you start — a
model that knows your rules up front argues with your draft instead of rewriting it.
Deliverable
| What | Where it goes |
|---|---|
| The question and your planned analysis | docs/briefs/research-brief.md |
| Sources, model, figures, success criteria | capabilities/economic-research/spec.md |
| The dated draft chain | drafts/YYYY-MM-DD-draft.md |
| The finished paper and its figures | analysis/research-paper.pdf · figures/ |
| Sessions and reflection | prompt-log.md at the repo root |
| The reviewed copy | Uploaded to your LMS as a PDF |
- Challenge chosen and narrow enough to analyze — brief committed before the research started
- Spec committed: data sources named, figures planned, success criteria stated
- Micro and/or macro concepts from the course do the explaining, by name
- Analysis covers current implications and what happens next under stated conditions
- A policy or strategy recommendation, defended against its strongest objection
- At least one figure, labeled, carrying evidence the text uses
- Every AI-supplied number checked against a real source
- Citations and bibliography in one consistent style
- Dated drafts committed in
drafts/— the chain, not just the last one scratch/in.gitignore; nothing else ignoredprompt-log.mdcurrent, closing with the reflection and one AI error you caughtcapabilities/economic-research/README.md"exercised in:" line updated- Paper carries no repository URL and no identifying information on its body pages
- PDF uploaded to the LMS; paper, figures, and log pushed to the repo
Check yourself
Reference
Open before you start
- Stage 0, part 2 — set up your workspace — the repo everything below commits into, if it is not standing yet
- Portfolio repo standard — where
docs/briefs/,capabilities/, andanalysis/come from, and why the repo is organized by capability rather than by course - AI conventions —
AGENTS.md, and how to tell a model your rules once instead of every session - Deliverable templates — the brief, the spec, and the prompt log
- .gitignore and why history is permanent — read before
scratch/has anything in it - Econ Policy Lab — tax, subsidy, ceiling, or floor on a live diagram, with the welfare boxes moving
Weights, deadlines, format rules, and the peer-review schedule live on your syllabus and in your offering's README — not here. This page teaches the method; your course sets the terms.