Conceptual Engineering

Why it matters

Some arguments are not really about the facts at all — they are about a word that is quietly buckling under the weight of the jobs we ask it to do. “Is a hot dog a sandwich?” is a joke version of a serious problem: when one word has to cover too many cases, or the world it was coined for has changed, the word starts producing bad calls, and no amount of clearer describing fixes it. Conceptual engineering is the discipline of treating a concept as a tool that can be well-made or badly-made — checking whether it is actually doing its job, and if it is not, redesigning it on purpose.

For example: in 2006 astronomers had a problem. “Planet” had no sharp definition, and newly found objects out past Neptune — some bigger than Pluto — were forcing the question of how many planets the solar system really had. The honest answer was that the concept was broken: it had never been built to handle these cases. So they did not just describe how “planet” was being used; they re-engineered it, adding the requirement that a planet must have “cleared its orbital neighborhood.” That single design choice demoted Pluto and held the count at eight. The fight that followed was loud precisely because everyone understood, correctly, that this was not a discovery about Pluto — it was a decision about what the word should mean.

What it reveals. Whether a concept is fit for purpose — and if it is not, a redesigned version: what the concept should mean to do its job well, distinct from the tangle of things it currently means.
How it changes the read. You stop asking “what does this term mean?” and start asking “what is this term for, is it doing that job, and what would a better-built version look like?”
When to foreground it. A word is causing the trouble, not just describing it — it bundles several incompatible jobs, the world has moved on around it, rival parties use it in clashing ways, or a metric meant to track something real is being gamed.
What you’d miss without it. That you can sharpen a definition perfectly and still be stuck, because the problem was never fuzziness — it was that the concept was built wrong for what you now need it to do.
Where it misleads. Pushed too hard it slides into redefinition-by-decree — quietly swapping a word’s meaning to win an argument, then acting as if everyone already agreed; the honest version always pays the bill of saying this is a change, here is what it costs, here is who has to come along.

Realtime examples

See real, dated analyses where this mode put a contested concept on the workbench and asked what it should mean → Conceptual Engineering on Main Street Independent

How to invoke it in Ora

You have an inherited concept you need to keep using but that is no longer doing its job well — it is carrying several incompatible meanings at once, the world has shifted around it, or different parties are using it in ways that clash — and you want a redesigned version, not just a clearer description of the mess.

Name the concept, say where it is failing concretely, and ask:

“Conceptual engineering on ‘[concept]’ as it’s used in [domain] — the inherited concept isn’t doing the work it should. What should it mean?”

The phrase conceptual engineering on plus an explicit what should it mean is what routes you here. Bring the failure in specifics — “‘consent’ in data-privacy law” is fine, but “‘consent’ in data-privacy law, where it’s become a one-click checkbox that supplies legal cover without anyone actually understanding what they agreed to” is far better — and, if you can, name the purpose you want the revised concept to serve, because the redesign is only as good as the job you tell it to do.

Two boundaries worth knowing. If the real question is what the concept currently means — you want the existing usage mapped and disambiguated, not redesigned — that is descriptive work, and the deep-clarification mode fits. And if the concept is fine but you keep mistaking your model, metric, or plan for the reality it stands for, that confusion has its own dedicated tool (the map-is-not-the-territory lens) rather than a full redesign. This mode produces the engineering groundwork — the diagnosis and the candidate redesigns with their costs — not the political work of making a new meaning stick.

How it works

Start with the move that makes this mode different from its neighbor. Most clarification work is descriptive: you take a fuzzy word, look at how people actually use it, and draw the boundaries clearly — you report what the concept does mean. Conceptual engineering does something the philosopher Herman Cappelen called “fixing” language. It treats the concept as a piece of equipment that can be sharp or dull, well-made or badly-made for the work at hand, and asks the prescriptive question instead: what should this concept mean if it is to do its job well? You are not surveying the tool. You are deciding whether to keep it, sharpen it, or replace it.

The clearest case is one almost everyone has an opinion on. Should Pluto count as a planet? You cannot answer that by describing harder, because there was no fact about Pluto hiding under the fuzziness — the concept “planet” simply had no rule for the objects telescopes were now finding. The astronomers had to engineer a fix: add a clause (“clears its orbital neighborhood”) that draws the line where they judged it ought to be drawn. Notice the shape of the move. They diagnosed a defect in the concept, proposed a revised concept, and then had to make it stick against people who liked the old one. That three-beat shape — diagnose, redesign, implement — is the whole method.

The first beat is diagnosis: what, exactly, is wrong with the concept? Sometimes it is doing five jobs at once and the jobs have started to conflict — think of how “addiction,” coined for a disease model of drugs and alcohol, now gets stretched over phones, sugar, and gambling until it stops tracking anything single. Sometimes the world moved: “public square” was built for a literal place where anyone could speak, and it strains badly when applied to an algorithmic feed that ranks and filters what you see. Sometimes a measure that was meant to reflect reality has become a target people optimize, and so it drifts away from the thing it was supposed to track. The diagnosis is not “this word is vague” — it is “this word is failing at a specific job, here is the job, here is the failure.”

The second beat is the redesign, and the philosopher Sally Haslanger gave the sharpest example of it. Instead of asking what “woman” or “race” happen to mean, she asked what those concepts would have to mean to do useful work against injustice — and proposed definitions built around social position and subordination, deliberately, because of what that revision would let us see and do. She called this the ameliorative project: you start from the purpose the concept ought to serve, then build the concept backward from that purpose. The crucial honesty here is that choosing the purpose is itself a value-laden move. “What should this mean for our aims?” only has an answer once you say whose aims, and say it out loud — pretending the purpose is neutral is one of the classic ways this work goes wrong.

The third beat is the one beginners skip and experts dwell on: the implementation problem. Even a beautifully redesigned concept is useless if you cannot actually get people to use it. Words are anchored in shared habit; you do not get to stipulate a new meaning by decree and expect the world to follow. So honest conceptual engineering ends not with “here is the better concept” but with “here is the better concept and here is what adopting it would cost” — the loss of easy coordination while everyone is half-using the old meaning and half the new, the charge that you are just redefining words to win, the institutions and laws and habits that would have to move. A redesign that names its own price is worth far more than one that pretends change is free. The deepest open debate in the field is exactly how much change is even available — whether concepts are pinned to ordinary usage so tightly that most engineering is aspirational — and the discipline’s answer is not to wave that away but to be explicit about the work adoption would take.

Framework & implementation

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

Pipeline execution

Conceptual Engineering is an atomic mode in the conceptual-clarification territory — a single redesign pass, not a composite of sub-analyses. It runs at Gear 4, Ora’s most thorough setting: a Depth analyst and a Breadth analyst work the concept in parallel and then critique each other (cross-adversarial evaluation) before a consolidator integrates the result. The split fits the method — depth drives one candidate redesign hard while breadth keeps the field of alternatives and their costs open, which is exactly the guard against tunnelling on a single favored definition.

The pass does five things in order. It locks the target concept and the specific places the current usage is failing, with examples that show the failure rather than asserting it. It elicits or infers the ameliorative purpose — the job the revised concept should serve — while naming whose interests that purpose serves and whose it does not, because the choice of purpose is a normative move and is marked as one. It surveys the candidate revisions across the relevant tradition (tighten the existing definition, replace the concept, split it into several distinct concepts, narrow its operative domain, or broaden it on normative grounds). It evaluates each candidate against the stated purpose, spelling out what the revision would and would not do. Finally it assembles the structured output, carrying the implementation problem and the costs of departure through to the end.

The mode’s reasoning tools ride in its ANALYTICAL PERSPECTIVES block — the lenses it loads as it works. The required one is the Cappelen-Plunkett conceptual-engineering lens, which supplies the discipline’s own machinery: the description-versus-prescription distinction, the ameliorative move, and the implementation/anchoring problem. The map-is-not-the-territory lens rides alongside it as the corrective that keeps the redesigned concept honest — a concept is a representation, and the lens guards against treating the new definition as if it simply were the reality it is meant to carve.

Output contract

The deliverable is a fixed set of sections, so the redesign is auditable rather than a persuasive essay: Target concept (the concept locked, with the engineering question stated as what it should mean), Current usage — descriptive baseline (how the inherited concept actually functions today, kept explicitly separate from the prescriptive work to come), Identified function failures (each job the concept is failing at, the cost of that failure, and the concrete mechanism behind it), Ameliorative purpose (the functions the revised concept must serve, stated as deliberate aims), Candidate revisions (several redesigns, each with its rationale and — crucially — its tradeoffs and what it would displace), Implementation problem (what adoption would actually require and who would resist), and a confidence read that separates how solid the diagnosis is from how solid the proposed revision and its adoption feasibility are.

Origin and evidence

The method comes from a revival in analytic philosophy across the 2010s and 2020s. Herman Cappelen’s Fixing Language (2018) gave the field its name and its central problem — that we can deliberately improve our concepts, but that “implementing” a new meaning runs into how little control any of us has over what words mean. Cappelen and Plunkett, with their collaborators, mapped the whole area in the volume Conceptual Engineering and Conceptual Ethics (2020), whose guided-tour introduction laid out the description / prescription / “whose purposes” structure the mode runs on. The deepest worked precedent is Sally Haslanger’s ameliorative analysis — set out in her 2000 Noûs paper on gender and race and developed in Resisting Reality (2012) — the discipline’s clearest demonstration that you can build a concept backward from the purpose you want it to serve.

Applications and common uses

Law and policy concepts under strain. “Consent” in data-privacy law, “misinformation” in platform moderation — inherited concepts that supply legal or regulatory cover while failing at the job they were meant to do.
Concepts the world has outrun. “Public square,” “privacy,” “employee” — terms coined for a world that has since changed shape under them, where the old definition no longer tracks what is happening.
Concepts doing too many jobs at once. “Addiction” stretched across phones, sugar, and gambling; “gender” carrying legal, medical, and identity-rights work simultaneously — candidates for splitting into several cleaner concepts.
Metrics that have become targets. A measure built to reflect something real that is now being optimized for its own sake, and so needs redesigning to re-anchor it to the underlying reality.
Contested terms in a dispute. Where two parties argue past each other because they are running incompatible definitions, and choosing the better-built concept is the way through.

Failure modes and when not to use it

Smuggling prescription in as description. The classic failure of all conceptual reasoning: start by asking what a word means and end by asserting what it should mean without flagging the switch. The mode forces the descriptive baseline first and marks the boundary, so the redesign cannot masquerade as a discovery.
Stipulation-by-decree. Treating the revised concept as if naming it were the same as adopting it. The mandatory implementation-problem section is the guard — a redesign that ignores what adoption costs is the redesign most likely to be ignored in turn.
Hidden purposes. Invoking “what should this mean for our purposes” without saying whose purposes, which lets a value-laden choice ride in disguised as neutral cleanup. The mode names the purpose and whom it serves as an explicit step.

When not to reach for it. When the question is descriptive — you want the current meaning mapped and disambiguated, not redesigned — route to deep-clarification, the descriptive-stance sibling in this territory. When nothing is wrong with the concept itself and the trouble is that you keep mistaking a model, metric, or plan for the reality it stands for, that is the work of the map-is-not-the-territory lens, not a full redesign. When the candidate revisions are themselves arguments under dispute whose soundness is the real issue, that is argument-audit work in the argument-analysis territory. And when the concept is a technical term with a settled stipulative definition, the engineering move is unnecessary — there is nothing buckling to fix.

Deep Clarification — the descriptive-stance sibling in this territory: the mode for when you want to know what a concept currently means, before — or instead of — deciding what it should mean.
The Map is Not the Territory — one of the two lenses this mode loads, and the right standalone tool when the trouble is mistaking a model or metric for the reality it stands for rather than a concept needing redesign.
Cappelen-Plunkett Conceptual Engineering — the required lens this mode runs on: the description-versus-prescription distinction, the ameliorative move, and the implementation/anchoring problem at the heart of fixing a concept.
Synthesis — the mode to reach for when the redesign turns out to need insight from several frameworks that have each engineered an adjacent concept under different commitments, and the task becomes integrating them.