Kumu / Micro/Macro Econ / Research Paper
Individual Research Paper — a global or local 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 or local 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. Frame the question in a brief, specify the work, build the argument in the open, validate every number, and decide 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, and it does not have to be global: a well-defined problem important to your own community is fully acceptable, provided the subject is well thought out. Families of topics that fit the course: 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. Starting from something you have watched hit your own industry gives you a head start on the evidence.
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: the five steps, applied to a paper
These are the five steps every project follows; here is what each one means for a paper. 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. The repo is preferred, not required: the PDF you upload to the LMS is the graded copy, and the repo is the evidence trail that shows how the paper was made.
| Step | What you produce | Where it lives |
|---|---|---|
| 1 · Frame | The challenge in your own words, the economic concepts it touches, and the analysis you plan to run | docs/briefs/YYYY-MM-DD-research-brief.md |
| 2 · Specify | 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 · Build | Dated drafts you write, one per working session that moved the paper; AI researches and attacks, and every session goes in the log | drafts/YYYY-MM-DD-draft.md |
| 4 · Validate | Every AI-supplied number and source checked against the original, and the log showing what you asked, what came back, and what you did with it | prompt-log.md at the repo root |
| 5 · Decide | The finished paper with its recommendation, 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 largest piece of
work in your portfolio, 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.
A push is how you ask for feedback. If you want your instructor's read on the topic or on a draft, commit the brief or the draft and push it; pushed work gets reviewed periodically and the feedback lands in the repo. Until you want that input, keep the work local. Pushes close to the deadline may not get a read before it; the cutoff date is in your syllabus.
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.
The rubric, and the constraints
This page describes the deliverable and the headings the rubric uses. Weights and due dates are in your course schedule.
| Category | What the reviewer asks |
|---|---|
| Content and Relevance | Does the paper clearly identify and explain the challenge (global or local)? Is the challenge linked appropriately to class concepts? |
| Analysis | Is the economic analysis detailed and insightful? Are implications and potential outcomes critically examined? |
| Recommendation | Are the suggested economic policies/strategies logical and based on the preceding analysis? |
| Presentation and Writing | Is the paper well-organized? Is the writing clear and free of errors? |
| Graph/Chart/Diagram | Is the graph relevant? Is it clearly labeled and effectively supports the analysis? |
Who reads it. Assigned peers score each paper on the rubric above in a double-anonymous review, your instructor scores it too, and submitting your own reviews is part of the assignment.
The constraints. Four pages maximum, not counting the title page, graphs, bibliography, or appendix. Typed, double-spaced, 12-point Times New Roman, one-inch margins. A title page with your name, the date, the course title, and the assignment title, and it is the only page with identifying information. At least one graph, chart, or diagram. Citations in APA, MLA, or Chicago with a separate bibliography page. Submit a PDF to the Assignment tab of your LMS; after the deadline you receive instructions and links to review your assigned classmates' papers anonymously.
Topic sign-off is not required if you are comfortable with your subject. If you want a read on it, commit your brief and push; that is the ask.
Where AI fits, and where it doesn't
You draft first and AI reviews; the doer–reviewer dilemma explains why.
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/YYYY-MM-DD-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
This page teaches the method; your course sets the terms. Weights and due dates are in your course schedule.