Cappelen-Plunkett Conceptual Engineering

Why it matters

A concept is a tool, not a discovery. We tend to treat the meaning of a word — planet, fairness, addiction, parent — as a fact about the world we are obliged to get right. But many concepts are things we built, for purposes, and when one stops serving its purpose the honest move is not to keep arguing about what it “really” means. It is to ask what it should mean, and redesign it.

For example: people argue endlessly over whether a tomato is a fruit or a vegetable. Botanists say fruit (it is the seed-bearing part of the plant); cooks say vegetable (it is savory, belongs in the salad, never the dessert). The argument never ends because there is nothing to win — there are two different concepts doing two different jobs, one built for biological classification and one for the kitchen. Ask what each concept is for and the dispute dissolves. Insisting there is a single right answer just keeps it alive.

What it reveals. Whether a dispute is really about what a concept currently means (a descriptive question) or about what it should mean (an engineering question) — and, when a concept is failing, what a better-designed version would be and what it would cost.
How it changes the read. You stop asking “what does this term really mean?” and start asking “what is this concept for, is it doing that job, and if not, what should it become?”
When to foreground it. A definitional fight that won’t resolve on the facts; an inherited term that quietly distorts (“X doesn’t really count as Y”); any moment someone says a word should mean something — that is an engineering proposal wearing the clothes of a description.
What you’d miss without it. That two sides can both be “right” because they are answering different questions — one describing usage, one proposing a revision — and that proposing a better concept is the easy half; getting a whole community to actually adopt it is the hard half most proposals quietly skip.
Where it misleads. Not every concept can be cleanly redesigned — some are essentially contested, where the dispute is the whole point (think “democracy,” “art”); and an engineering proposal smuggled in as a flat description (“X simply is Y”) robs you of the chance to weigh it as the proposal it actually is.

How it works

In 2006 the International Astronomical Union held a vote, and Pluto stopped being a planet. The reaction was furious — schoolchildren wrote letters; people felt something had been taken from them. You can’t just vote on what a planet is. That reaction, understandable as it was, rests on a confusion worth taking apart, because once you see it you see it everywhere.

Here is what actually happened. For most of the twentieth century “planet” was a comfortable word with nine comfortable members. Then, through the 1990s and 2000s, astronomers began finding things out past Neptune — icy bodies, lots of them, some nearly Pluto’s size, one of them (Eris) heavier. A question that had never needed answering suddenly demanded one: is Pluto a planet, or the first-found member of a whole swarm of icy leftovers? Notice that this is not a question about Pluto. Pluto had not changed; the telescopes had. The real question was about the word: should “planet” be drawn so that it includes Pluto — and therefore Eris, and Makemake, and Haumea, and the long line of iceballs behind them — or drawn so that it picks out the eight big bodies and files the rest under a different kind? The astronomers were not uncovering a hidden fact about Pluto’s planethood. They were choosing how to cut. They were redesigning a concept.

That is the move at the center of the whole idea, and once you have it, disputes that look factual start to come apart in your hands. There are really two different questions you can ask about any concept. The first is descriptive: what does this word actually mean, as people use it now? The second is an engineering question — philosophers call the careful version of it ameliorative: what should this word mean, given the work we need it to do? These are different questions with different kinds of answers, and a startling number of bitter arguments are just two people answering different ones and mistaking it for a head-on clash. One says “a hot dog is a sandwich” (an engineering proposal — let’s classify by structure); the other says “nobody calls it a sandwich” (a descriptive report of usage). They can both be right, because they were never actually contradicting each other.

The philosopher Sally Haslanger pushed the engineering question into territory that matters far more than hot dogs. Instead of asking “what is gender?” or “what is race?” as though the answer were waiting to be uncovered, she asked: what work do we want these concepts to do — politically, analytically — and what version of them would do that work best? That reframing is the method in miniature. You don’t litigate the true essence of a loaded concept; you name the purpose, design the concept to serve it, and argue openly for the design — instead of pretending you have merely described reality.

But there is a catch, and it is the honest heart of the enterprise. Proposing a better concept turns out to be the easy part. Getting it adopted is brutally hard, because a concept isn’t owned by anyone. It lives spread across millions of speakers, textbooks, habits, and institutions, and no committee can reach in and reset it. The astronomers could vote, but they could not make the world’s museums repaint their displays or stop a generation from feeling, in its gut, that Pluto is a planet. The philosopher Herman Cappelen made this implementation problem the central difficulty of the field: you can be entirely right that a concept should change and still have almost no lever with which to change it. Which is why a serious proposal never stops at “here is a better concept.” It asks who would have to adopt it, and through what mechanism — argument, education, law, sheer repeated use — and admits, plainly, how wide the gap is between the proposal and the world actually picking it up.

That whole discipline — diagnosing whether a fight is descriptive or engineering, naming the purpose a concept should serve, designing a revision to serve it, and reckoning honestly with what it would cost and whether it could ever be adopted — is what Herman Cappelen and David Plunkett named conceptual engineering: treating our concepts not as facts to be discovered but as tools we are allowed, and sometimes obligated, to redesign.

Framework & implementation

Origin and evidence

The framework is Herman Cappelen and David Plunkett’s, consolidated in their field-defining survey “Introduction: A Guided Tour of Conceptual Engineering and Conceptual Ethics” and the collection it opens (Conceptual Engineering and Conceptual Ethics, Oxford University Press, 2020, edited with Alexis Burgess). Its book-length spine is Cappelen’s Fixing Language: An Essay on Conceptual Engineering (2018), which lays out the master argument — our concepts are defective in various ways; we can sometimes do better by revising the concept than by accepting the poor fit; such revision is therefore a legitimate, sometimes obligatory project — and which makes the implementation problem central: concepts are decentralized, distributed across speakers, and resistant to top-down redesign. The engineering method had a powerful independent source in Sally Haslanger’s ameliorative analysis, developed in feminist philosophy: her “Gender and Race: (What) Are They? (What) Do We Want Them To Be?” (Noûs, 2000, reprinted in Resisting Reality, 2012) asks not what a loaded concept is but what work we want it to do, and designs the concept to that purpose. The two camps differ on a live debate the analysis deliberately does not adjudicate: Cappelen is broadly skeptical that an engineer can control uptake, while Haslanger treats adoption as continuous with social and political contestation — concepts gaining ground through use, argument, education, and movement-building. The lens reaches back to W. B. Gallie’s essentially-contested concepts for the cases where engineering must reckon with contestation as a feature rather than a bug.

Applications and common uses

Conceptual engineering is a working tool wherever a concept itself — not the facts — is what’s in dispute.

Law and policy. Statutory and regulatory definitions are engineered concepts: what should count as “income,” “disability,” “refugee,” “employee”? The method names the purpose the definition serves and designs to it, rather than mining ordinary usage.
Science and measurement. Redrawing “planet,” “species,” “gene,” or “addiction” as evidence accumulates — choosing category boundaries that carve nature at useful joints, openly, as revisions rather than discoveries.
Social and political concepts. Haslanger’s home ground: redesigning loaded concepts (gender, race, merit, fairness) around the analytical and political work they are meant to do, with the proposal argued openly as a proposal.
Organizations and product. Settling what a contested internal term — “active user,” “done,” “incident,” “customer” — should mean for a given purpose, and recognizing that the definition is a design choice with costs, not a fact to be looked up.
Resolving stuck definitional fights. Diagnosing whether the parties are describing usage or proposing a revision — the single move that dissolves a surprising share of arguments that only looked factual.

In every case the payoff is the same: the dispute is correctly typed (descriptive or engineering), the purpose is named, the redesign is argued from that purpose with its costs and its adoption problem on the table — instead of two sides each insisting their preferred meaning is the one true one.

Failure modes and when not to use it

The lens’s characteristic ways of going wrong are catalogued in its Common Failure Modes:

Mode confusion. Engaging an engineering question as a descriptive one, or the reverse — offering usage evidence against a proposal, or a normative argument against a report of usage. The tell: the parties are arguing past each other. Diagnose the mode each is in and restructure the exchange around it.
Implementation ignored. Proposing a revision without saying how it would be taken up. The tell: a rigorous proposal whose author cannot say what would actually happen if it were “adopted.” Name the population, the levers (academic, legal, professional, cultural), and the realistic uptake horizon; document the residual gap.
Purpose-vacuum engineering. Proposing a revision with no purpose identified, so it reads as personal preference. The tell: the case for the revision is aesthetic, not functional. Name the purposes and argue from them; with none, the project lacks its materials.
Strawman of current usage. Making the revision look obviously needed by misdescribing how the concept is used now. The tell: the descriptive claim wouldn’t survive scrutiny by competent users. Get the description right first, then argue for revision against the accurate baseline.
Neutrality theatre. Presenting an engineering proposal as a neutral observation to bypass the audience’s right to weigh it. The tell: the report says “X is Y” while the supporting argument is about purposes, not usage. Recast the claim explicitly as a proposal and let it be evaluated against alternatives.

When not to reach for it. When the task is genuinely descriptive — you want to know what a term currently means — the ameliorative move is presumptuous, and a plain clarification of usage is the right tool. When a concept already has a settled, stipulated technical definition that works, engineering it is busywork. And when a concept’s contestation is constitutive — an essentially-contested concept where the ongoing dispute is the concept’s whole life — the method still helps you see the structure, but it should offer revisions with an explicit overreach caveat rather than pretending to settle what cannot honestly be settled.

Conceptual Engineering — the analysis this lens is the method for; walks a concept from descriptive baseline through function-failure to candidate revision, with the implementation problem and costs surfaced.
The Map is Not the Territory — the sibling mental model in the same analysis: a concept is a map, a revisable representation, not the reality it tracks — the stance that licenses redesigning it when it stops fitting.
Lakoff Conceptual Metaphor — the metaphorical infrastructure many concepts carry, which constrains what an engineering revision can quietly change and what will fight back.
Deep Clarification — the descriptive counterpart analysis: when the goal is to clarify how a concept is currently used rather than to redesign it, this is where the question belongs.