Chapter 7.1 — Idea-Generation Workshop

For six weeks you have been a passenger. Every dataset arrived pre-cleaned, every regression had a known right answer in the back of the book, and every “research question” was really a teaching device — a scaffold built so you would meet difference-in-differences, or weak instruments, or the Loughran–McDonald dictionary, in a controlled setting. Starting today that scaffold comes down. The rest of the camp is your own project: a real empirical question, on real data you will acquire and clean yourself, answered with a design you choose and defend. Phase 2 of the program ends with you standing in front of a room presenting it.

That is exciting and it is also where most first projects die. They do not die in the regression — by now you can run a regression in your sleep. They die at the very beginning, in the gap between “I’m interested in crypto” and “here is a specific, answerable, falsifiable question I can attack with data I can actually get in five weeks.” That gap is the entire subject of this chapter. We are going to reveal the trick that experienced researchers use to cross it, again and again, in minutes rather than weeks — because it is a trick, a repeatable procedure, not a flash of genius you either have or you don’t.

Here is the trick stated in one sentence, the way this book states every trick before unpacking it: a good empirical project is a vague interest passed through three filters — Does anyone care? Is it new? Can I actually do it? — until what comes out the other side is a single sentence of the form “the effect of [a specific treatment or variation] on [a specific, measurable outcome], identified by [a specific source of variation], using [a specific dataset I can get].” Everything else in Week 7 — acquiring the data (Ch 7.2), writing it down as a pre-analysis plan (Ch 7.3), building the dataset (Ch 7.4), and arguing the identification in a memo (Ch 7.5) — is downstream of getting that one sentence right. Get the sentence right and the project almost runs itself. Get it wrong and no amount of clever econometrics will save you. So we spend this chapter, and the workshop it sets up, getting the sentence right.

7.1.1 From puzzle to hypothesis: the shape of a researchable question

A puzzle is a feeling that something is interesting. “Crypto seems to crash all at once” is a puzzle. “Insurers are pulling out of wildfire states” is a puzzle. “Banks treat some borrowers differently” is a puzzle. Puzzles are necessary — you should not work on something you find boring for five weeks — but a puzzle is not a research question, because you cannot be wrong about a puzzle. It makes no prediction. Nothing you could observe in data would force you to abandon it. And a claim that nothing could refute is, in Karl Popper’s sense, not a scientific claim at all. The first job of this chapter is to teach you to turn a puzzle into something you can be wrong about.

The target is a falsifiable hypothesis: a statement, sharp enough to be written as a sign on a coefficient, that some specific pattern in data would contradict. Watch the transformation happen on Devon’s puzzle. “Crypto seems to crash all at once” becomes, after sharpening, “When a large stablecoin loses its dollar peg, trading volume on decentralized exchanges spikes within the same day.” Notice what the sharpening did. It named the trigger (a stablecoin depeg), named the outcome (DEX trading volume), named the timing (same day), and — this is the crucial part — it committed to a direction: volume goes up, not down, not “changes.” Now Devon can be wrong. If he pulls the data and volume does not move, or moves down, the hypothesis is dead, and that is a feature. A hypothesis you cannot kill is a hypothesis you cannot learn from.

The grammar of a sharp hypothesis is worth memorizing, because you will run every project idea through it. It has four slots:

An outcome y — a thing you can measure, ideally a number, for many units. (“DEX trading volume,” “loan approval,” “homeowner premium,” “next-month return,” “citations to a patent.”) If you cannot say what number you would put in the y column of a dataset, you do not yet have an outcome; you have a mood.
A treatment or key variation D — the thing whose effect on y you want to know, and which varies across your units. (“A stablecoin depeg,” “being above the credit-score cutoff,” “a new wildfire-pricing regulation,” “a momentum signal,” “winning a patent grant.”) No variation, no study: if every unit has the same D, there is nothing to compare.
A direction or magnitude — the prediction. Up or down. Larger for group A than group B. This is what makes it falsifiable.
A unit and a window — whose outcome, over what period. (“U.S. mortgage applicants, 2018–2022.” “ERC-20 stablecoins, 2022–2024.” “S&P 500 firms, monthly, 2010–2024.”)

You met this grammar before without it being labeled as such. CONVENTIONS §4 — the empirical-spec discipline this whole book runs on — demands that every regression name its outcome · treatment · controls · fixed effects · clustering · sample · identifying assumption. A sharp hypothesis is just the first, second, and last of those, written down before you have any data. The rest of Week 7 fills in the middle slots.

7.1.2 The “so what / who cares / what’s new” filter

Suppose you have a sharp, falsifiable hypothesis. It can still be a bad project — because being answerable is not the same as being worth answering. Before you spend a week acquiring data, you run the idea through three questions, in this order, and you have to survive all three.

So what? (the consequence test.) If you found the answer — either answer — would anything change? Would a regulator price risk differently, an investor trade differently, a borrower be treated more fairly, a firm patent differently? The test is brutal and useful: write down the sentence “If I find that [result], then [someone] should [do something / believe something different].” If you cannot fill in that sentence for both possible answers, the question is inert. Maya’s fair-lending question survives easily: if she finds that minority applicants are denied at higher rates after controlling for everything a lender is legally allowed to use, a regulator has a disparate-impact case to investigate; if she finds the gap vanishes once you control for legitimate factors, that too is a publishable, policy-relevant finding. Both answers matter. That is a “so what” that holds.

Who cares? (the audience test.) Different from “so what.” A result can have consequences in principle but an audience of zero. “Does the closing price of one obscure micro-cap stock follow a hidden pattern?” might be falsifiable and even consequential to one day-trader, but there is no community of people — no regulator, no academic literature, no class of investors — who would read it. A good question sits inside a conversation. Weeks 5 and 6 were, secretly, training for exactly this: you read Kelly–Pruitt, Hoberg–Phillips, Loughran–McDonald, the Bartlett–Bhutta fair-lending work, precisely so you would know which conversations exist and where the live arguments are. A project that extends, tests, or challenges something in one of those conversations has an audience built in. A project floating in empty space does not.

What’s new? (the novelty test.) The hardest of the three for a beginner, and the one where you will most need the literature scan in §7.1.4. “New” does not mean “no one has ever studied anything like this” — that bar is impossible and, frankly, suspicious when met. It means your specific combination of outcome, variation, data, or period adds something not already on the shelf. Newness comes in flavors, and recognizing the flavor you are offering keeps you honest: a new dataset (on-chain data that did not exist a decade ago), a new period or event (climate-driven insurance retreat is a phenomenon of the last few years), a new outcome for an old treatment, a new identification strategy that cleans up a relationship others could only show as a correlation, or a careful replication in a new setting (genuinely valuable, and far more respectable than the field’s reputation suggests). What does not count: re-running a famous result on the same data with no new angle. If your honest answer to “what’s new” is “nothing, I just wanted to see it for myself,” that is a fine learning exercise but not a project for Phase 2.

The order matters. Run “so what” first because it is cheap and kills the most ideas. Run “who cares” second because it tells you which literature to scan. Run “what’s new” last, after the scan, because you cannot know what is new until you know what exists. An idea that survives all three is not guaranteed to be a good project — feasibility can still kill it, which is §7.1.3 — but an idea that fails any one of them is not worth carrying further, no matter how clever the econometrics would be.

7.1.3 The anatomy of a good research question: outcome, variation, identification

Now we get specific about the second slot — the treatment — because that is where Weeks 3 and 4 come back with full force. A sharp, consequential, novel hypothesis is necessary but not sufficient. The thing that turns it into empirical research rather than a plausible story with a regression attached is identification: a credible argument that the correlation you measure is the causal effect you claim, and not the confounding, reverse causality, or selection that Week 3 taught you to fear.

Recall the spine of Weeks 3 and 4. Chapter 3.1 posed the fundamental problem: you never see the same unit both treated and untreated, so every causal claim leans on an assumption about the counterfactual. Maya’s financial-literacy example was the lesson — a 21-point approval gap that was some unknown blend of the program’s effect and the head start that the kind of person who enrolls already had. The entire toolkit that followed was a catalog of strategies for making that blend legible: matching and weighting (Ch 3.2–3.3) when you believe selection is on observables; instrumental variables (Ch 3.4–3.5) when it is not and you can find an exogenous wiggle; difference-in-differences and event studies (Ch 4.1–4.2) when a policy switches on at a date for some units and not others; regression discontinuity (Ch 4.3) when a sharp rule assigns treatment at a cutoff; synthetic control (Ch 4.4) for a single treated unit; and shift-share (Ch 4.5) when you must build an instrument from shares and shifts.

The practical move for project design is to run this catalog backwards. Do not pick a method and go looking for a question. Pick a question, then ask: where, in the world that generates my data, is there a source of variation in my treatment that is plausibly unrelated to the confounders I fear? That source of variation is your identification, and finding it is the single highest-leverage thing you will do all of Week 7. Three patterns are realistic for a high-schooler’s project:

A sharp rule or cutoff gives you regression discontinuity essentially for free. The loan-approval credit-score threshold, the Russell 1000/2000 reconstitution boundary Sam already met in Chapter 4.3 — these are institutions that randomize for you, just above and below a line. If your treatment is switched on by a number crossing a threshold, you have a design.
A dated policy or shock that hits some units and not others gives you difference-in-differences. Priya’s wildfire-pricing regulation, a state’s adoption of a new disclosure rule, an exchange delisting a token on a specific date — anything with a clean before/after for a treated group and a comparable untreated group.
A natural event with a clear timestamp gives you an event study. A stablecoin depeg, an earnings announcement, a hurricane landfall — measure the outcome in a tight window around the event, against what it was doing before.

A fourth pattern, a found or built instrument (IV in Ch 3.4–3.5, shift-share in Ch 4.5), is real but the hardest to pull off well in five weeks, because a valid instrument is something you find rarely and defend with difficulty, and the weak-instrument pathology of Chapter 3.5 can quietly poison your inference. Reach for it only if the instrument is so clean you could explain it to a skeptic in one sentence; otherwise prefer a cutoff, a policy date, or an event, where the identifying assumption is closer to the surface and easier to argue in front of an audience.

If none of these is available — if your treatment varies for reasons hopelessly tangled with the outcome and you have no cutoff, no policy date, no clean event, and no instrument — then be honest: your project is descriptive, not causal. That is allowed, and for a first project it is often wise. A careful, well-measured description of a new phenomenon (“here is how DEX volume behaves around depegs, with no causal claim”) is a real contribution and a survivable Phase 2 presentation. What is not allowed is a descriptive correlation dressed up in causal language — “the regulation caused premiums to rise” when all you have is a before-and-after with no control group. CONVENTIONS §4 forbids exactly this: name the threat and the design that addresses it, or do not make the causal claim. Knowing the difference between what you can identify and what you can only describe is the maturity Weeks 3 and 4 were building toward, and it is what separates a project that survives questioning from one that collapses under the first sharp question from the audience.

7.1.4 Feasibility: what a high-schooler can actually finish in five weeks

This is the filter that students skip and then regret. An idea can be sharp, consequential, novel, and well-identified, and still be impossible for you to finish now. Feasibility is not a lack of ambition; it is the discipline of matching scope to the resources you actually have — which are, realistically, five weeks, a laptop, free or program-provided data, and an AI co-pilot whose limits you learned to respect in Chapter 6.5. Four constraints bind.

Data access. The first and most common project-killer. Before you fall in love with a question, ask the unglamorous question: can I actually get the data, legally, for free or through the program, in a usable form, this week? Some data is genuinely open and downloadable today: HMDA loan records, NOAA storm events, FEMA disaster declarations, FRED macro series, USPTO PatentsView, on-chain data via public APIs, daily prices via yfinance. Some is licensed and lives only on GMU infrastructure — CRSP, Compustat, Bloomberg — which per CONVENTIONS §5 you may use read-only on Hopper/WRDS, never copied off. And some data you imagine exists but does not, or exists behind a paywall you cannot cross, or requires an approval process longer than the whole camp. The §7.1.6 map below pairs every cast member with data in the first category for a reason: a feasible project starts from data you can have in hand by the end of Ch 7.2, not data you are hoping to find.

Scope. A first project should answer one question, not five. The beginner’s instinct is to widen — “and I’ll also check whether it differs by firm size, and across countries, and over three different decades, and…” Each “and” multiplies the data you must clean and the ways the analysis can break, and none of them helps if the core question isn’t nailed first. The professional instinct is the opposite: find the smallest version of the question that is still interesting, answer that cleanly, and only then add. One outcome, one treatment, one well-chosen sample. You can always extend a tight project; you can rarely rescue a sprawling one.

Time and reproducibility. Five weeks is not long, and a third of it goes to acquiring and cleaning data — always more than you expect (Ch 7.4 is entirely about why). Budget backward from the presentation: if Phase 2 is the deadline, you need results in hand a week before, analysis the week before that, a clean dataset the week before that, which leaves you about a week from today to lock the question and start pulling data. That arithmetic alone should make you ruthless about scope. And everything you build must be reproducible — every snippet runs on a fresh environment, secrets via env vars only, licensed data stays put (CONVENTIONS §5) — because a result you cannot re-run is a result you cannot defend.

Your own skills. Be honest about the gap between a method’s elegance and your ability to execute it correctly under time pressure. You can run an IV; you have to ask whether you can find a valid instrument and survive the weak-instrument pathology of Chapter 3.5 in the time you have. A clean difference-in-differences you fully understand beats a fragile structural model you half-understand. Pick the design you can defend line by line, because in Phase 2 someone will ask.

7.1.5 The fast literature scan — with the AI co-pilot on a leash

You cannot answer “what’s new” from your armchair, and you cannot afford a six-week reading marathon. You need a fast scan — a few hours that tells you whether your question already has a settled answer, what the live arguments are, and which two or three papers you must actually read. Here is the procedure, and where the AI co-pilot helps and where it will hurt you.

Start broad with Google Scholar: search your outcome and treatment in plain words (“mortgage denial race HMDA,” “stablecoin depeg contagion,” “patent grant firm innovation”), sort by relevance, and skim titles and abstracts for ten minutes to map the terrain. Use the “cited by” link on any paper that looks central — it walks you forward in time to who built on it, which is how you find the current edge of a conversation rather than its history. When you find a paper squarely on your question, read its introduction’s literature review, which is a curated map drawn by an expert. This is the reading skill Week 5 built: you do not read every paper, you read the right three, and you read them the way Chapter 5 taught — find the question, the data, the identification, and the punchline first.

Now the AI co-pilot, and this is where Chapter 6.5 earns its place in Week 7. An LLM is genuinely excellent at literature triage — the first of the five safe uses from §6.5.1. Paste twenty abstracts and ask it to sort them into “directly on my question / adjacent / off-topic” and summarize each method in one line; you lose almost nothing if it miscategorizes one, because you were going to skim the borderline cases anyway. It is excellent at explaining a method you half-remember, parsing a data dictionary, and suggesting search terms you hadn’t thought of. A good prompt for this stage borrows the cite-or-decline discipline of §6.5.2: ask it to “summarize only the abstracts I paste below, and if an abstract doesn’t address my question, say so rather than guessing” — constraining the model to the text you supply, not its blurry parametric memory. Use it for all of that.

But here is the non-negotiable rule, lifted directly from Chapter 6.5’s first critical limit: an LLM will fabricate citations that look perfect and do not exist. Ask it “what papers study stablecoin depegs” and it will hand you author lists, titles, years, and journals in flawless bibliographic format — some real, some pure invention, and you cannot tell which from the page. This has already embarrassed lawyers and students who trusted the output. So the rule for your scan, which is also CONVENTIONS §6: verify every single citation against a real index — Google Scholar, the journal’s own site, a DOI lookup — before it enters your proposal. If you cannot find the paper, it does not exist, no matter how confident the model sounded. Treat the LLM as a suggestion engine for what to go verify, never as the citation itself, and never as the source of a specific number (“the 2022 depeg wiped out $40B”) — that is a hypothesis to check against the primary source, not a fact to cite. If you genuinely cannot verify a claim, tag it [CHECK] and move on rather than letting a fabrication stand. The whole point of a leash is that the dog still does the hunting; you just decide what’s real.

7.1.6 The cast’s projects: five feasible questions, five real datasets

Enough abstraction. Here is the payoff — a concrete, feasible, fully open-data project mapped to each member of the cast, the same five students whose interests you have followed since Week 1. Each pairing is chosen so the data is genuinely obtainable for free or through the program, the scope fits five weeks, and an identification strategy from Weeks 3–4 is at least available. Use these as templates; your own project will be a variation on one of them.

Student	Interest	Dataset (open / free)	A feasible question	Candidate design
Maya	Fair lending	HMDA (CFPB Loan/Application Register)	Do denial rates differ by applicant race after controlling for legitimate underwriting factors?	DiD around a policy date, or RD at a credit-score cutoff
Devon	Crypto / on-chain	Etherscan API + CoinGecko API	Does DEX trading volume spike when a stablecoin depegs?	Event study around the depeg timestamp
Priya	Climate & insurance	NOAA storm events + FEMA disaster declarations + FRED	Do homeowner-insurance costs rise faster in counties with more billion-dollar disasters?	DiD: disaster-hit vs. comparable un-hit counties
Sam	Momentum / anomalies	CRSP (on WRDS) or `yfinance`	Do past-12-month winners outperform losers in the next month?	Portfolio-sort / factor regression (descriptive→predictive)
Leah	Innovation / patents	USPTO PatentsView API	Do firms that win a patent grant receive more forward citations than near-miss applicants?	RD / matched comparison on application quality

A few notes before two worked examples. Maya’s HMDA is the same dataset you met in the Week 4 fair-lending lab and the Bartlett–Bhutta reading (Ch 6.4), so she starts with home-field advantage. Sam’s momentum question is deliberately descriptive-leaning: he can build a clean portfolio sort with yfinance data on a laptop, and only reach for CRSP on WRDS (read-only, snapshot-dated, per CONVENTIONS §5) if he wants the long, survivorship-bias-free history. Devon’s and Priya’s questions both have a clean event or policy timestamp, which is exactly what makes them identifiable. Each of these datasets will get its own data card under data-cards/ as you acquire it in Ch 7.2 — the documented provenance, license, and known gotchas that make the work reproducible.

Worked example A — Devon: stablecoin depegs and DEX volume

Watch the full pipeline run, from mood to spec.

Puzzle (a mood): “Crypto crashes seem to feed on themselves.”
Filter pass. So what? If volume spikes predictably at depegs, that is information for risk managers, exchanges sizing circuit-breakers, and regulators worried about contagion — both answers (it spikes / it doesn’t) inform someone. Who cares? There is a live academic and policy conversation on stablecoin runs and crypto contagion. What’s new? On-chain DEX volume at high frequency around specific depeg events is a dataset that did not exist a few years ago and that few have used; that is the new-data flavor of novelty.
Refined question: When an ERC-20 stablecoin loses its dollar peg by more than 5%, how does same-day DEX trading volume in that token respond?
Testable hypothesis (with a direction): DEX volume rises sharply on the day of a depeg relative to the prior 30-day average; H_0: no change. Now Devon can be wrong.
Identifying variation: an event study (Ch 4.2). The depeg is a dated shock with a precise on-chain timestamp; Devon measures volume in a tight window around it against the pre-event baseline. The threat to identification — was the depeg caused by something that independently moved volume? — is named and addressed by the tight window and by checking the pre-trend, exactly as Chapter 4.1 insisted.
Spec (CONVENTIONS §4): outcome = daily DEX volume (log); treatment = depeg event indicator; window = [-30, +5] days; unit = stablecoin × day; sample = major ERC-20 stablecoins, 2022–2024; data = Etherscan + CoinGecko; identifying assumption, in one sentence: absent the depeg, the token’s volume would have continued on its pre-event path.

Worked example B — Priya: disasters and the price of insurance

Puzzle: “Insurers are fleeing wildfire and hurricane country.”
Filter pass. So what? If disaster exposure drives up insurance cost, it bears directly on housing affordability, regulation of insurer exit, and the climate-adaptation debate — a regulator and a homeowner both care, either way the result comes out. Who cares? A fast-growing climate-finance literature, and you read climate-risk material across Weeks 3–6. What’s new? The recent surge in billion-dollar disasters is a new period, and county-level NOAA/FEMA/FRED data linked this way is a new combination.
Refined question: Do counties hit by federally declared disasters see homeowner-insurance costs rise faster than comparable counties that were not hit, in the years after the disaster?
Testable hypothesis: Insurance cost grows faster in disaster-hit counties post-event than in matched un-hit counties; H_0: parallel growth.
Identifying variation: difference-in-differences (Ch 4.1). Treated = counties with a FEMA declaration in a given year; control = comparable counties without one; the FEMA declaration is the dated treatment. The threat — disaster-prone counties differ systematically — is addressed by the difference in differences (which sweeps out fixed county characteristics) plus a parallel-trends check on pre-disaster cost growth, precisely the discipline Priya learned in her own Chapter 4.1.
Spec: outcome = county insurance-cost proxy (e.g., a FRED/CPI insurance series or premium index); treatment = FEMA major-disaster declaration; controls = county fixed effects + year fixed effects; clustering = by county; sample = U.S. counties, 2010–2023; identifying assumption: absent the disaster, hit and un-hit counties’ insurance costs would have trended in parallel.

Two passes through the same machine, two different designs, both arriving at a single defensible sentence. That is the whole skill. Run your own mood through it.

7.1.7 A feasibility-and-novelty scoring rubric

You will not carry one idea into Week 7; you will carry three or four, and you need a fast, honest way to rank them. Here is the rubric you will use in PS 7.1 — score each candidate idea on five dimensions, 0–2 points each, for a total out of 10. It is deliberately blunt, because its job is to kill weak ideas early, not to flatter them.

Dimension	0 — fatal	1 — workable	2 — strong
Falsifiable?	A mood; no direction.	A direction, vaguely stated.	A sharp signed hypothesis with H_0.
So what / who cares?	No one acts on either answer.	A niche audience cares.	A real conversation cares; both answers matter.
Novel?	Re-run of a known result, same data.	New setting or period for a known idea.	New data, outcome, or identification.
Identifiable?	Pure correlation dressed as causal.	Descriptive, honestly labeled.	A real design (RD/DiD/event/IV) from Weeks 3–4.
Feasible in 5 weeks?	Data unavailable or out of scope.	Data obtainable; scope tight but real.	Data in hand by Ch 7.2; one clean question.

Read the scores like a checklist with veto power, not a sum to maximize. Any 0 on “Identifiable?” or “Feasible?” is a veto — kill the idea, regardless of its total, because an unidentifiable question is not research and an infeasible one will not finish. A solid project lands at 7 or above with no zeros. An idea scoring 4–6 is usually salvageable by narrowing: tighten the hypothesis, find the cutoff or the event date, shrink the sample to data you can actually get. Score your three or four candidates, keep the top one or two, and bring them to the workshop. The goal is not to find the perfect idea — there isn’t one — but to find the best feasible one and commit, because a good question you finish beats a brilliant one you don’t.

Your Turn

Open nb7.1 — the idea-to-spec template. It walks your own raw interest through the exact pipeline this chapter built: puzzle → “so what / who cares / what’s new” filter → four-slot hypothesis grammar → backward search for identifying variation → the scoring rubric → a finished one-sentence spec in the CONVENTIONS §4 format. Bring at least three candidate ideas; the notebook makes you score and rank them, and you leave with one project locked and a runner-up in reserve. That spec is the input to everything that follows: Ch 7.2 turns it into acquired data, Ch 7.3 freezes it into a pre-analysis plan, Ch 7.4 builds the dataset, and Ch 7.5 makes you defend the identification in a memo.

Three questions to sit with before the workshop:

Take your favorite puzzle and try to make it un-falsifiable on purpose. Write the vaguest version you can — no direction, no measurable outcome. Now write the sharpest. The distance between those two sentences is the work this chapter is asking of you; which slot (outcome, treatment, direction, window) was hardest to pin down, and what does that tell you about where your idea is still soft?
For your top idea, where does the identifying variation come from — and what is the single most dangerous confounder it does not handle? If you cannot name a cutoff, a dated policy, or a clean event, be honest about whether your project is causal or descriptive. Either is allowed; pretending the second is the first is not.
Run your AI co-pilot’s literature suggestions through the §6.5 leash. Ask it for five papers on your question, then try to verify each one in Google Scholar. How many were real? What does the failure rate tell you about how much of the model’s confident output you should ever take on faith?

# Chapter 7.1 — Idea-Generation Workshop For six weeks you have been a passenger. Every dataset arrived pre-cleaned, every regression had a known right answer in the back of the book, and every "research question" was really a teaching device — a scaffold built so you would meet difference-in-differences, or weak instruments, or the Loughran–McDonald dictionary, in a controlled setting. Starting today that scaffold comes down. The rest of the camp is your own project: a real empirical question, on real data you will acquire and clean yourself, answered with a design you choose and defend. Phase 2 of the program ends with you standing in front of a room presenting it. That is exciting and it is also where most first projects die. They do not die in the regression — by now you can run a regression in your sleep. They die at the very beginning, in the gap between *"I'm interested in crypto"* and *"here is a specific, answerable, falsifiable question I can attack with data I can actually get in five weeks."* That gap is the entire subject of this chapter. We are going to reveal the trick that experienced researchers use to cross it, again and again, in minutes rather than weeks — because it is a trick, a repeatable procedure, not a flash of genius you either have or you don't. Here is the trick stated in one sentence, the way this book states every trick before unpacking it: **a good empirical project is a vague interest passed through three filters — Does anyone care? Is it new? Can *I* actually do it? — until what comes out the other side is a single sentence of the form "the effect of [a specific treatment or variation] on [a specific, measurable outcome], identified by [a specific source of variation], using [a specific dataset I can get]."** Everything else in Week 7 — acquiring the data (Ch 7.2), writing it down as a pre-analysis plan (Ch 7.3), building the dataset (Ch 7.4), and arguing the identification in a memo (Ch 7.5) — is downstream of getting that one sentence right. Get the sentence right and the project almost runs itself. Get it wrong and no amount of clever econometrics will save you. So we spend this chapter, and the workshop it sets up, getting the sentence right. --- ## 7.1.1 From puzzle to hypothesis: the shape of a researchable question A *puzzle* is a feeling that something is interesting. "Crypto seems to crash all at once" is a puzzle. "Insurers are pulling out of wildfire states" is a puzzle. "Banks treat some borrowers differently" is a puzzle. Puzzles are necessary — you should not work on something you find boring for five weeks — but a puzzle is not a research question, because you cannot be *wrong* about a puzzle. It makes no prediction. Nothing you could observe in data would force you to abandon it. And a claim that nothing could refute is, in Karl Popper's sense, not a scientific claim at all. The first job of this chapter is to teach you to turn a puzzle into something you *can* be wrong about. The target is a **falsifiable hypothesis**: a statement, sharp enough to be written as a sign on a coefficient, that some specific pattern in data would contradict. Watch the transformation happen on Devon's puzzle. "Crypto seems to crash all at once" becomes, after sharpening, *"When a large stablecoin loses its dollar peg, trading volume on decentralized exchanges spikes within the same day."* Notice what the sharpening did. It named the trigger (a stablecoin depeg), named the outcome (DEX trading volume), named the timing (same day), and — this is the crucial part — it committed to a *direction*: volume goes **up**, not down, not "changes." Now Devon can be wrong. If he pulls the data and volume does not move, or moves down, the hypothesis is dead, and that is a *feature*. A hypothesis you cannot kill is a hypothesis you cannot learn from. The grammar of a sharp hypothesis is worth memorizing, because you will run every project idea through it. It has four slots: 1. **An outcome $y$** — a thing you can measure, ideally a number, for many units. ("DEX trading volume," "loan approval," "homeowner premium," "next-month return," "citations to a patent.") If you cannot say what number you would put in the $y$ column of a dataset, you do not yet have an outcome; you have a mood. 2. **A treatment or key variation $D$** — the thing whose effect on $y$ you want to know, and which *varies* across your units. ("A stablecoin depeg," "being above the credit-score cutoff," "a new wildfire-pricing regulation," "a momentum signal," "winning a patent grant.") No variation, no study: if every unit has the same $D$, there is nothing to compare. 3. **A direction or magnitude** — the prediction. Up or down. Larger for group A than group B. This is what makes it falsifiable. 4. **A unit and a window** — *whose* outcome, over *what* period. ("U.S. mortgage applicants, 2018–2022." "ERC-20 stablecoins, 2022–2024." "S&P 500 firms, monthly, 2010–2024.") You met this grammar before without it being labeled as such. CONVENTIONS §4 — the empirical-spec discipline this whole book runs on — demands that every regression name its *outcome · treatment · controls · fixed effects · clustering · sample · identifying assumption*. A sharp hypothesis is just the first, second, and last of those, written down before you have any data. The rest of Week 7 fills in the middle slots. --- ## 7.1.2 The "so what / who cares / what's new" filter Suppose you have a sharp, falsifiable hypothesis. It can still be a bad project — because being answerable is not the same as being worth answering. Before you spend a week acquiring data, you run the idea through three questions, in this order, and you have to survive all three. **So what? (the *consequence* test.)** If you found the answer — either answer — would anything change? Would a regulator price risk differently, an investor trade differently, a borrower be treated more fairly, a firm patent differently? The test is brutal and useful: write down the sentence "If I find that [result], then [someone] should [do something / believe something different]." If you cannot fill in that sentence for *both* possible answers, the question is inert. Maya's fair-lending question survives easily: if she finds that minority applicants are denied at higher rates *after* controlling for everything a lender is legally allowed to use, a regulator has a disparate-impact case to investigate; if she finds the gap vanishes once you control for legitimate factors, that too is a publishable, policy-relevant finding. Both answers matter. That is a "so what" that holds. **Who cares? (the *audience* test.)** Different from "so what." A result can have consequences in principle but an audience of zero. "Does the closing price of one obscure micro-cap stock follow a hidden pattern?" might be falsifiable and even consequential to one day-trader, but there is no community of people — no regulator, no academic literature, no class of investors — who would read it. A good question sits inside a *conversation*. Weeks 5 and 6 were, secretly, training for exactly this: you read Kelly–Pruitt, Hoberg–Phillips, Loughran–McDonald, the Bartlett–Bhutta fair-lending work, precisely so you would know which conversations exist and where the live arguments are. A project that extends, tests, or challenges something in one of those conversations has an audience built in. A project floating in empty space does not. **What's new? (the *novelty* test.)** The hardest of the three for a beginner, and the one where you will most need the literature scan in §7.1.4. "New" does not mean "no one has ever studied anything like this" — that bar is impossible and, frankly, suspicious when met. It means *your specific combination* of outcome, variation, data, or period adds something not already on the shelf. Newness comes in flavors, and recognizing the flavor you are offering keeps you honest: a **new dataset** (on-chain data that did not exist a decade ago), a **new period or event** (climate-driven insurance retreat is a phenomenon of the last few years), a **new outcome** for an old treatment, a **new identification strategy** that cleans up a relationship others could only show as a correlation, or a careful **replication** in a new setting (genuinely valuable, and far more respectable than the field's reputation suggests). What does *not* count: re-running a famous result on the same data with no new angle. If your honest answer to "what's new" is "nothing, I just wanted to see it for myself," that is a fine learning exercise but not a project for Phase 2. The order matters. Run "so what" first because it is cheap and kills the most ideas. Run "who cares" second because it tells you which literature to scan. Run "what's new" last, *after* the scan, because you cannot know what is new until you know what exists. An idea that survives all three is not guaranteed to be a good project — feasibility can still kill it, which is §7.1.3 — but an idea that fails any one of them is not worth carrying further, no matter how clever the econometrics would be. --- ## 7.1.3 The anatomy of a good research question: outcome, variation, identification Now we get specific about the second slot — the treatment — because that is where Weeks 3 and 4 come back with full force. A sharp, consequential, novel hypothesis is necessary but not sufficient. The thing that turns it into *empirical research* rather than *a plausible story with a regression attached* is **identification**: a credible argument that the correlation you measure is the causal effect you claim, and not the confounding, reverse causality, or selection that Week 3 taught you to fear. Recall the spine of Weeks 3 and 4. Chapter 3.1 posed the fundamental problem: you never see the same unit both treated and untreated, so every causal claim leans on an assumption about the counterfactual. Maya's financial-literacy example was the lesson — a 21-point approval gap that was *some unknown blend* of the program's effect and the head start that the kind of person who enrolls already had. The entire toolkit that followed was a catalog of strategies for making that blend legible: matching and weighting (Ch 3.2–3.3) when you believe selection is on observables; instrumental variables (Ch 3.4–3.5) when it is not and you can find an exogenous wiggle; difference-in-differences and event studies (Ch 4.1–4.2) when a policy switches on at a date for some units and not others; regression discontinuity (Ch 4.3) when a sharp rule assigns treatment at a cutoff; synthetic control (Ch 4.4) for a single treated unit; and shift-share (Ch 4.5) when you must *build* an instrument from shares and shifts. The practical move for project design is to run this catalog *backwards*. Do not pick a method and go looking for a question. Pick a question, then ask: **where, in the world that generates my data, is there a source of variation in my treatment that is plausibly unrelated to the confounders I fear?** That source of variation is your identification, and finding it is the single highest-leverage thing you will do all of Week 7. Three patterns are realistic for a high-schooler's project: - **A sharp rule or cutoff** gives you regression discontinuity essentially for free. The loan-approval credit-score threshold, the Russell 1000/2000 reconstitution boundary Sam already met in Chapter 4.3 — these are institutions that randomize *for* you, just above and below a line. If your treatment is switched on by a number crossing a threshold, you have a design. - **A dated policy or shock that hits some units and not others** gives you difference-in-differences. Priya's wildfire-pricing regulation, a state's adoption of a new disclosure rule, an exchange delisting a token on a specific date — anything with a clean *before/after* for a *treated* group and a comparable *untreated* group. - **A natural event with a clear timestamp** gives you an event study. A stablecoin depeg, an earnings announcement, a hurricane landfall — measure the outcome in a tight window around the event, against what it was doing before. A fourth pattern, **a found or built instrument** (IV in Ch 3.4–3.5, shift-share in Ch 4.5), is real but the hardest to pull off well in five weeks, because a *valid* instrument is something you find rarely and defend with difficulty, and the weak-instrument pathology of Chapter 3.5 can quietly poison your inference. Reach for it only if the instrument is so clean you could explain it to a skeptic in one sentence; otherwise prefer a cutoff, a policy date, or an event, where the identifying assumption is closer to the surface and easier to argue in front of an audience. If none of these is available — if your treatment varies for reasons hopelessly tangled with the outcome and you have no cutoff, no policy date, no clean event, and no instrument — then be honest: your project is **descriptive**, not causal. That is allowed, and for a first project it is often *wise*. A careful, well-measured description of a new phenomenon ("here is how DEX volume behaves around depegs, with no causal claim") is a real contribution and a survivable Phase 2 presentation. What is *not* allowed is a descriptive correlation dressed up in causal language — "the regulation *caused* premiums to rise" when all you have is a before-and-after with no control group. CONVENTIONS §4 forbids exactly this: name the threat and the design that addresses it, or do not make the causal claim. Knowing the difference between what you can identify and what you can only describe is the maturity Weeks 3 and 4 were building toward, and it is what separates a project that survives questioning from one that collapses under the first sharp question from the audience. --- ## 7.1.4 Feasibility: what a high-schooler can actually finish in five weeks This is the filter that students skip and then regret. An idea can be sharp, consequential, novel, and well-identified, and still be impossible for *you* to finish *now*. Feasibility is not a lack of ambition; it is the discipline of matching scope to the resources you actually have — which are, realistically, five weeks, a laptop, free or program-provided data, and an AI co-pilot whose limits you learned to respect in Chapter 6.5. Four constraints bind. **Data access.** The first and most common project-killer. Before you fall in love with a question, ask the unglamorous question: *can I actually get the data, legally, for free or through the program, in a usable form, this week?* Some data is genuinely open and downloadable today: HMDA loan records, NOAA storm events, FEMA disaster declarations, FRED macro series, USPTO PatentsView, on-chain data via public APIs, daily prices via `yfinance`. Some is licensed and lives only on GMU infrastructure — CRSP, Compustat, Bloomberg — which per CONVENTIONS §5 you may use *read-only on Hopper/WRDS*, never copied off. And some data you imagine exists but does not, or exists behind a paywall you cannot cross, or requires an approval process longer than the whole camp. The §7.1.6 map below pairs every cast member with data in the *first* category for a reason: a feasible project starts from data you can have in hand by the end of Ch 7.2, not data you are hoping to find. **Scope.** A first project should answer *one* question, not five. The beginner's instinct is to widen — "and I'll also check whether it differs by firm size, and across countries, and over three different decades, and..." Each "and" multiplies the data you must clean and the ways the analysis can break, and none of them helps if the core question isn't nailed first. The professional instinct is the opposite: find the *smallest* version of the question that is still interesting, answer that cleanly, and only then add. One outcome, one treatment, one well-chosen sample. You can always extend a tight project; you can rarely rescue a sprawling one. **Time and reproducibility.** Five weeks is not long, and a third of it goes to acquiring and cleaning data — always more than you expect (Ch 7.4 is entirely about why). Budget backward from the presentation: if Phase 2 is the deadline, you need results in hand a week before, analysis the week before that, a clean dataset the week before *that*, which leaves you about a week from today to lock the question and start pulling data. That arithmetic alone should make you ruthless about scope. And everything you build must be reproducible — every snippet runs on a fresh environment, secrets via env vars only, licensed data stays put (CONVENTIONS §5) — because a result you cannot re-run is a result you cannot defend. **Your own skills.** Be honest about the gap between a method's elegance and your ability to execute it correctly under time pressure. You *can* run an IV; you have to ask whether you can find a *valid* instrument and survive the weak-instrument pathology of Chapter 3.5 in the time you have. A clean difference-in-differences you fully understand beats a fragile structural model you half-understand. Pick the design you can defend line by line, because in Phase 2 someone will ask. --- ## 7.1.5 The fast literature scan — with the AI co-pilot on a leash You cannot answer "what's new" from your armchair, and you cannot afford a six-week reading marathon. You need a *fast* scan — a few hours that tells you whether your question already has a settled answer, what the live arguments are, and which two or three papers you must actually read. Here is the procedure, and where the AI co-pilot helps and where it will hurt you. Start broad with **Google Scholar**: search your outcome and treatment in plain words ("mortgage denial race HMDA," "stablecoin depeg contagion," "patent grant firm innovation"), sort by relevance, and skim titles and abstracts for ten minutes to map the terrain. Use the **"cited by"** link on any paper that looks central — it walks you *forward* in time to who built on it, which is how you find the current edge of a conversation rather than its history. When you find a paper squarely on your question, read *its* introduction's literature review, which is a curated map drawn by an expert. This is the reading skill Week 5 built: you do not read every paper, you read the *right* three, and you read them the way Chapter 5 taught — find the question, the data, the identification, and the punchline first. Now the AI co-pilot, and this is where Chapter 6.5 earns its place in Week 7. An LLM is genuinely excellent at **literature triage** — the first of the five safe uses from §6.5.1. Paste twenty abstracts and ask it to sort them into "directly on my question / adjacent / off-topic" and summarize each method in one line; you lose almost nothing if it miscategorizes one, because you were going to skim the borderline cases anyway. It is excellent at explaining a method you half-remember, parsing a data dictionary, and suggesting search terms you hadn't thought of. A good prompt for this stage borrows the *cite-or-decline* discipline of §6.5.2: ask it to "summarize only the abstracts I paste below, and if an abstract doesn't address my question, say so rather than guessing" — constraining the model to the text you supply, not its blurry parametric memory. Use it for all of that. But here is the non-negotiable rule, lifted directly from Chapter 6.5's first critical limit: **an LLM will fabricate citations that look perfect and do not exist.** Ask it "what papers study stablecoin depegs" and it will hand you author lists, titles, years, and journals in flawless bibliographic format — some real, some pure invention, and *you cannot tell which from the page*. This has already embarrassed lawyers and students who trusted the output. So the rule for your scan, which is also CONVENTIONS §6: **verify every single citation against a real index — Google Scholar, the journal's own site, a DOI lookup — before it enters your proposal.** If you cannot find the paper, it does not exist, no matter how confident the model sounded. Treat the LLM as a *suggestion engine for what to go verify*, never as the citation itself, and never as the source of a specific number ("the 2022 depeg wiped out \$40B") — that is a hypothesis to check against the primary source, not a fact to cite. If you genuinely cannot verify a claim, tag it `[CHECK]` and move on rather than letting a fabrication stand. The whole point of a leash is that the dog still does the hunting; you just decide what's real. --- ## 7.1.6 The cast's projects: five feasible questions, five real datasets Enough abstraction. Here is the payoff — a concrete, feasible, fully open-data project mapped to each member of the cast, the same five students whose interests you have followed since Week 1. Each pairing is chosen so the data is genuinely obtainable for free or through the program, the scope fits five weeks, and an identification strategy from Weeks 3–4 is at least *available*. Use these as templates; your own project will be a variation on one of them. | Student | Interest | Dataset (open / free) | A feasible question | Candidate design | |---|---|---|---|---| | **Maya** | Fair lending | **HMDA** (CFPB Loan/Application Register) | Do denial rates differ by applicant race after controlling for legitimate underwriting factors? | DiD around a policy date, or RD at a credit-score cutoff | | **Devon** | Crypto / on-chain | **Etherscan API** + **CoinGecko API** | Does DEX trading volume spike when a stablecoin depegs? | Event study around the depeg timestamp | | **Priya** | Climate & insurance | **NOAA** storm events + **FEMA** disaster declarations + **FRED** | Do homeowner-insurance costs rise faster in counties with more billion-dollar disasters? | DiD: disaster-hit vs. comparable un-hit counties | | **Sam** | Momentum / anomalies | **CRSP** (on WRDS) or **`yfinance`** | Do past-12-month winners outperform losers in the next month? | Portfolio-sort / factor regression (descriptive→predictive) | | **Leah** | Innovation / patents | **USPTO PatentsView API** | Do firms that win a patent grant receive more forward citations than near-miss applicants? | RD / matched comparison on application quality | A few notes before two worked examples. Maya's HMDA is the same dataset you met in the Week 4 fair-lending lab and the Bartlett–Bhutta reading (Ch 6.4), so she starts with home-field advantage. Sam's momentum question is deliberately *descriptive-leaning*: he can build a clean portfolio sort with `yfinance` data on a laptop, and only reach for CRSP on WRDS (read-only, snapshot-dated, per CONVENTIONS §5) if he wants the long, survivorship-bias-free history. Devon's and Priya's questions both have a clean event or policy timestamp, which is exactly what makes them identifiable. Each of these datasets will get its own **data card** under `data-cards/` as you acquire it in Ch 7.2 — the documented provenance, license, and known gotchas that make the work reproducible. ### Worked example A — Devon: stablecoin depegs and DEX volume Watch the full pipeline run, from mood to spec. - **Puzzle (a mood):** "Crypto crashes seem to feed on themselves." - **Filter pass.** *So what?* If volume spikes predictably at depegs, that is information for risk managers, exchanges sizing circuit-breakers, and regulators worried about contagion — both answers (it spikes / it doesn't) inform someone. *Who cares?* There is a live academic and policy conversation on stablecoin runs and crypto contagion. *What's new?* On-chain DEX volume at high frequency around specific depeg events is a dataset that did not exist a few years ago and that few have used; that is the new-data flavor of novelty. - **Refined question:** *When an ERC-20 stablecoin loses its dollar peg by more than 5%, how does same-day DEX trading volume in that token respond?* - **Testable hypothesis (with a direction):** *DEX volume rises sharply on the day of a depeg relative to the prior 30-day average; $H_0$: no change.* Now Devon can be wrong. - **Identifying variation:** an **event study** (Ch 4.2). The depeg is a dated shock with a precise on-chain timestamp; Devon measures volume in a tight window around it against the pre-event baseline. The threat to identification — was the depeg *caused* by something that independently moved volume? — is named and addressed by the tight window and by checking the pre-trend, exactly as Chapter 4.1 insisted. - **Spec (CONVENTIONS §4):** outcome = daily DEX volume (log); treatment = depeg event indicator; window = $[-30, +5]$ days; unit = stablecoin × day; sample = major ERC-20 stablecoins, 2022–2024; data = Etherscan + CoinGecko; identifying assumption, in one sentence: *absent the depeg, the token's volume would have continued on its pre-event path.* ### Worked example B — Priya: disasters and the price of insurance - **Puzzle:** "Insurers are fleeing wildfire and hurricane country." - **Filter pass.** *So what?* If disaster exposure drives up insurance cost, it bears directly on housing affordability, regulation of insurer exit, and the climate-adaptation debate — a regulator and a homeowner both care, either way the result comes out. *Who cares?* A fast-growing climate-finance literature, and you read climate-risk material across Weeks 3–6. *What's new?* The recent surge in billion-dollar disasters is a *new period*, and county-level NOAA/FEMA/FRED data linked this way is a *new combination*. - **Refined question:** *Do counties hit by federally declared disasters see homeowner-insurance costs rise faster than comparable counties that were not hit, in the years after the disaster?* - **Testable hypothesis:** *Insurance cost grows faster in disaster-hit counties post-event than in matched un-hit counties; $H_0$: parallel growth.* - **Identifying variation:** **difference-in-differences** (Ch 4.1). Treated = counties with a FEMA declaration in a given year; control = comparable counties without one; the FEMA declaration is the dated treatment. The threat — disaster-prone counties differ systematically — is addressed by the *difference* in differences (which sweeps out fixed county characteristics) plus a parallel-trends check on pre-disaster cost growth, precisely the discipline Priya learned in her own Chapter 4.1. - **Spec:** outcome = county insurance-cost proxy (e.g., a FRED/CPI insurance series or premium index); treatment = FEMA major-disaster declaration; controls = county fixed effects + year fixed effects; clustering = by county; sample = U.S. counties, 2010–2023; identifying assumption: *absent the disaster, hit and un-hit counties' insurance costs would have trended in parallel.* Two passes through the same machine, two different designs, both arriving at a single defensible sentence. That is the whole skill. Run your own mood through it. --- ## 7.1.7 A feasibility-and-novelty scoring rubric You will not carry one idea into Week 7; you will carry three or four, and you need a fast, honest way to rank them. Here is the rubric you will use in PS 7.1 — score each candidate idea on five dimensions, 0–2 points each, for a total out of 10. It is deliberately blunt, because its job is to *kill* weak ideas early, not to flatter them. | Dimension | 0 — fatal | 1 — workable | 2 — strong | |---|---|---|---| | **Falsifiable?** | A mood; no direction. | A direction, vaguely stated. | A sharp signed hypothesis with $H_0$. | | **So what / who cares?** | No one acts on either answer. | A niche audience cares. | A real conversation cares; both answers matter. | | **Novel?** | Re-run of a known result, same data. | New setting or period for a known idea. | New data, outcome, or identification. | | **Identifiable?** | Pure correlation dressed as causal. | Descriptive, honestly labeled. | A real design (RD/DiD/event/IV) from Weeks 3–4. | | **Feasible in 5 weeks?** | Data unavailable or out of scope. | Data obtainable; scope tight but real. | Data in hand by Ch 7.2; one clean question. | Read the scores like a checklist with veto power, not a sum to maximize. Any **0 on "Identifiable?" or "Feasible?"** is a veto — kill the idea, regardless of its total, because an unidentifiable question is not research and an infeasible one will not finish. A solid project lands at **7 or above with no zeros**. An idea scoring 4–6 is usually salvageable by *narrowing*: tighten the hypothesis, find the cutoff or the event date, shrink the sample to data you can actually get. Score your three or four candidates, keep the top one or two, and bring them to the workshop. The goal is not to find the perfect idea — there isn't one — but to find the *best feasible* one and commit, because a good question you finish beats a brilliant one you don't. --- ## Your Turn Open **nb7.1 — the idea-to-spec template.** It walks your own raw interest through the exact pipeline this chapter built: puzzle → "so what / who cares / what's new" filter → four-slot hypothesis grammar → backward search for identifying variation → the scoring rubric → a finished one-sentence spec in the CONVENTIONS §4 format. Bring at least three candidate ideas; the notebook makes you score and rank them, and you leave with one project locked and a runner-up in reserve. That spec is the input to everything that follows: Ch 7.2 turns it into acquired data, Ch 7.3 freezes it into a pre-analysis plan, Ch 7.4 builds the dataset, and Ch 7.5 makes you defend the identification in a memo. Three questions to sit with before the workshop: 1. *Take your favorite puzzle and try to make it un-falsifiable on purpose.* Write the vaguest version you can — no direction, no measurable outcome. Now write the sharpest. The distance between those two sentences is the work this chapter is asking of you; which slot (outcome, treatment, direction, window) was hardest to pin down, and what does that tell you about where your idea is still soft? 2. *For your top idea, where does the identifying variation come from — and what is the single most dangerous confounder it does not handle?* If you cannot name a cutoff, a dated policy, or a clean event, be honest about whether your project is causal or descriptive. Either is allowed; pretending the second is the first is not. 3. *Run your AI co-pilot's literature suggestions through the §6.5 leash.* Ask it for five papers on your question, then try to verify each one in Google Scholar. How many were real? What does the failure rate tell you about how much of the model's confident output you should ever take on faith?