Why Most Economics Checklists Fail Before You Start Using Them
I spent three years building and refining a system that tracks economic variables for small research projects, and the thing that almost killed it was not complexity. It was over-engineering. The first version had forty-seven items. Nobody finished it. The second version, what I actually use now, is called the Checklist For Economics Cute and it has nine items. The name is not ironic. Cute here means compact and usable, not adorable. People outside the field assume it refers to something whimsical. It does not.
What Checklist For Economics Cute Actually Covers
The framework tracks nine decision points across four stages: variable selection, data sourcing, model specification, and result validation. Each point is binary. You either pass it or you do not. There is no room for "mostly" or "I think so." That ambiguity is where most undergraduate and even graduate-level projects go sideways. I learned this the hard way. In 2021 I was advising a student who was running panel regressions on regional GDP growth. She had fifteen control variables pulled from three different databases with mismatched year coverage. Her R-squared was impressive. Her standard errors were nonsense because she had not checked whether two of her regressors were measured on different date scales. One dataset used calendar years, the other used fiscal years ending in March. The mismatch introduced a systematic timing bias that inflated her coefficient on infrastructure spending by roughly 40 percent. The Checklist For Economics Cute forces a step where you verify date alignment before you touch a single regression. She skipped it because it felt boring. It cost her three months of revisions.
How to Use the Nine Items Without Losing Your Mind
Item one: define your dependent variable in plain language before you write a single line of code. This sounds obvious and nobody does it. I have seen models where the dependent variable was never explicitly stated in the notes, only implied through a variable name like "growth_rate_final_v3." Version three of what, exactly. Write it out. One sentence. If you cannot write it, you do not understand your own model yet. Item two: confirm data availability for the full time range you need. Gaps are normal. But if your dependent variable has a missing block of four consecutive years and you do not plan to address it, that is a structural weakness, not a minor issue. Imputation will not fix this. You either have the data or you do not. When you do not, your results are conditional on an assumption you are not stating. Item three: document the source of every variable. Not the general website. The exact dataset identifier, revision number, and access date. I once reproduced a published result and found the author had referenced a World Bank indicator that has been revised five times since their paper ran. The revised series changed the coefficient sign. I caught this because I kept a source log. The original authors did not.
Get the Full Details
Item four: check for unit consistency across all variables. Dollars versus constant dollars. Per capita versus aggregate. Percent versus proportion. These mismatches are the most common source of coefficient magnitude errors in applied work. I had a project where GDP was in current USD and the trade variable was in constant 2015 USD. The estimated trade elasticity came out to 2.8 instead of the expected 0.6. Took me six hours to find it. A single column checking units would have taken thirty seconds. Item five: specify your identification strategy before estimation. Are you using fixed effects, instrumental variables, difference-in-differences, or a structural model. This is not about naming the method. It is about stating what causal question you are actually trying to answer. Most students pick a technique and then force their question into it. The reverse order works better. Define the question first. Then the method follows. Item six: run specification tests that matter for your chosen method. Robust standard errors when clustering is appropriate. Pre-trend tests for difference-in-differences. Relevance and exogeneity diagnostics for IV. These are not optional formality steps. They are the difference between a result you can stand behind and one you cannot. I skip this step at my own risk, and I regret it every time.
Item seven: test sensitivity to outliers and influential observations. A single outlier can flip a significant result to insignificant in small datasets. I use the dfbeta and dffits diagnostics in Stata and the influence.plot function in R. If any observation has a dfbeta greater than 2 divided by the number of observations, you need to decide whether to keep it or cap it. Document that decision. Do not hide it. Item eight: report confidence intervals alongside point estimates. Point estimates alone are almost useless. A coefficient of 0.42 with a confidence interval of negative 0.3 to 1.14 is not a finding. It is a placeholder. The interval tells you the precision. Always include it. Item nine: write a one-paragraph limitation statement. Not a footnote. A plain paragraph. What could go wrong with these results. Which assumptions are weakest. What data is missing. This takes about two minutes and it is the single most honest thing you can put in any economics project. Reviewers respond to it. Students avoid it because it feels like admitting defeat. It is not. It is professional practice.
Where the Framework Breaks Down
The Checklist For Economics Cute is not universal. It assumes you are working with quantitative micro or macro data at an individual or small-team level. It does not translate well to large-scale simulation work, structural estimation with thousands of parameters, or theoretical proofs. In those contexts the overhead of checking nine items becomes noise rather than signal. You need a different system entirely. It also assumes access to reproducible data. If your data lives in someone else's private database with no download link, no identifier, and no chance of reconstruction, most of the checklist becomes decorative. You can still check items one through five on paper, but item six through nine require data you do not control. I ran into this with a project on informal labor markets in Southeast Asia where the primary dataset was collected by a government agency that does not share raw files. We managed with aggregated table data and sensitivity analysis, but the results carried a caveat that dominated the discussion section. No amount of checklist compliance fixes that problem. There is also a timing cost. Using the full checklist on a standard project adds roughly forty-five minutes to the preparation phase and another thirty minutes during the write-up phase. For a classroom assignment due in a week, that is significant. For a working paper or thesis chapter, it is negligible. I recommend using a trimmed version with only items one, four, six, and nine when you are under extreme time pressure. Those four catch the damage that actually matters.
Download and Implementation Notes
The checklist itself is available as a plain text file and a CSV template at the usual academic resource repositories. It is not proprietary. I have also posted a Stata do-file template and an R script that auto-checks items two through seven against a working dataset. The scripts are rough. They handle common cases and fail silently on edge cases involving mixed date formats and currency conversion flags. Do not run them without inspecting the output manually. Automated checks are faster than manual ones only when they are correct, and these scripts are not always correct. The CSV template includes columns for variable name, source ID, revision, date range, unit, and a pass fail marker. I recommend keeping the source column filled in even when the source is your own constructed variable. You will forget what "ln_wage_adj" means in six months. The checklist format forces you to write it down while you still remember.
A Few Things Nobody Tells You
First, the best time to run the checklist is after you have written your code but before you interpret the results. Running it before you code means you are checking boxes on assumptions you have not yet tested. Running it after interpretation means you are likely to skip items that make your results look worse. The post-code pre-interpretation window is the sweet spot. It is a narrow window. You have to discipline yourself to stop there. Second, some items conflict with each other. Item five asks you to commit to an identification strategy early. Item six asks you to run tests that may force you to change that strategy. This is normal. The checklist is not linear. It is iterative. I usually run through items one through four, commit to a specification, run item six, and then loop back to adjust items four or five based on what the diagnostics show. The checklist accommodates this. It just requires you to note the adjustment in the source log. Third, do not treat a clean checklist as proof of quality. A project can pass all nine items and still produce trivial or misleading results. The checklist verifies process discipline, not intellectual value. It catches mechanical errors. It does not catch conceptual errors. That part is still on you.
