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 to invoke it in Ora

You have a concept that isn’t doing its job — an inherited term that distorts, a word used in incompatible ways, a definition that no longer fits the work you need it to do — and you want to redesign it rather than merely describe how it’s used now.

Name the concept, say what’s going wrong with it, and ask:

“Do a conceptual-engineering analysis of how we use the word ‘X’ — what’s it failing to do, what should it mean instead, and what would the revision cost?”

This rides inside the Conceptual Engineering analysis. Ora first maps the descriptive baseline (what the concept currently does — its uses, distinctions, and commitments), then names the function failures (where it falls short or distorts), states an ameliorative purpose (the job the revised concept should do, phrased as a function, not as a verdict you want it to deliver), proposes one or more candidate revisions with their tradeoffs, and — the part most redesigns skip — names the implementation problem: who would have to adopt the new concept and how, plus the costs the revision would impose.

One thing to know: phrases like conceptual engineering, ameliorative analysis, redefine, what should X mean, should the concept be, or the word isn’t doing its job are what route you here. Asking only “what does this term currently mean?” routes to a descriptive clarification instead — this analysis is for redesign, so say that the concept could or should be different.

Bring the concept and a concrete sense of what’s wrong with it; the analysis is only as sharp as the function-failure you can point to.

One thing Ora won’t do: smuggle your desired conclusion into the redefinition. It insists the purpose be stated as a function the concept should serve (“help us distinguish A from B”), not as the verdict you want (“classify X as Y”), and it will not pretend that proposing a revision is the same as getting the world to adopt it — it names that gap rather than hiding it. And where a concept’s contestation is constitutive (an essentially-contested concept), it flags the overreach instead of pretending the dispute is cleanly resolvable.

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

This section uses Ora’s own terms for the parts of an analysis, so that if you open the actual mode and lens files they line up. Each is glossed in plain language on first use.

Pipeline execution

Cappelen-Plunkett conceptual engineering is the required lens of the Conceptual Engineering analysis — it sits in the mode’s lens_dependencies.required, which means it supplies the analysis’s actual method rather than merely informing it (it also rides in the ANALYTICAL PERSPECTIVES block as an always-loaded mental model, beside Lakoff’s conceptual metaphor, the framing effect, and the map-territory discipline). The mode runs at Gear 4, Ora’s most thorough setting — a Depth analyst and a Breadth analyst work the concept in parallel, critique each other (cross-adversarial evaluation), and revise. The lens’s defining contribution is the descriptive/engineering distinction: it forces the analysis to know, at every step, whether it is reporting how a concept is used or proposing how it should be built.

Where the lens engages. It activates on its Detection Signals — a concept whose usage is contested in a way facts alone won’t settle; a question of the form “should this term mean X” rather than “does it”; a reform project (legal, scientific, political) that needs its proposed revision structured; two parties talking past each other, where the diagnosis is that one is in descriptive mode and the other in engineering mode. Its Application Steps run the engineering routine: diagnose which mode the question is in; if descriptive, report current usage; if engineering, identify the purposes the concept serves, propose a revision that serves them better, argue from purposes to proposal, and address who would have to adopt it.

What it contributes to the analysis. Because it is the method lens, it populates the whole output skeleton: the Current usage — descriptive baseline (what the concept does now, mapped before any redesign), the Identified function failures (where it fails or distorts, each with its cost), the Ameliorative purpose (the function the revised concept should serve), the Candidate revisions (each with rationale and tradeoffs), the Implementation problem (who adopts it, through what mechanism), and the Revision costs and displacement (what current usage the revision would lose). The analysis keeps three confidences separate — confidence in the diagnosis, in the proposed revision, and in adoption feasibility — because a sharp diagnosis does not guarantee a good revision, and a good revision does not guarantee uptake.

Cross-adversarial evaluation. At Gear 4 each analyst’s reading is critiqued by the other, which catches the lens’s signature failures — keyed to its Critical Questions and Common Failure Modes and to the mode’s named failure modes. The sharpest is stipulation-smuggle (the mode’s stipulation-smuggle, tested by CQ1): an “ameliorative purpose” stated as the verdict you want (“the concept should classify X as Y”) rather than as a function (“the concept should help distinguish A from B”) — a redefinition rigged to deliver a conclusion. Then baseline-skip (baseline-skip, CQ2): redesigning a concept without first mapping how it’s actually used, so the revision answers a strawman. Then implementation-blindness (implementation-blindness, CQ3): the lens’s namesake problem — proposing a revision while ignoring the gap between proposal and uptake. Then cost-blindness (cost-blindness, CQ4): presenting a revision as pure gain, with current usage written off as worthless. The lens’s own catalog adds mode confusion (engineering and descriptive claims argued past each other), purpose-vacuum engineering (revision by personal preference, with no purpose named), strawman of current usage, and neutrality theatre (an engineering proposal dressed as a plain description to bypass the audience’s right to evaluate it).

Honesty discipline. The lens refuses false confidence on principle — conceptual engineering is hard, and a good analysis admits the difficulty rather than concealing it. It will not let an engineering proposal be defended by appeal to current usage (a category mistake: proposals are defended by purpose-fit, not descriptive accuracy), and it flags ameliorative-overreach when a concept’s contestation is constitutive — an essentially-contested concept in W. B. Gallie’s sense, like “democracy” or “art” — where treating the dispute as cleanly resolvable is itself the error.

What the analysis will not do. It will not pass off a proposal as a description; will not state the purpose as a smuggled conclusion; will not treat articulating a revision as achieving its adoption; and will not present a redesign as costless. Where the user only wants to know what a term currently means, it routes sideways to a descriptive clarification instead of presuming to redesign.

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.