Conceptual Clarification

Overview

The Conceptual Clarification Framework (T10) handles the case where the question is not what to do, what to argue, or what to choose, but what a concept actually means. Concepts arrive in three different shapes that need three different operations performed on them. Sometimes the concept is in current use and the user wants its mechanics surfaced — what is actually being claimed when the word is said, and what changes about action or inference once the deeper structure is visible. Sometimes the concept is doing normative work badly and the user wants to engineer a revision — name the failures, articulate what the concept should do, and propose a candidate revision honest about the gap between proposal and adoption. Sometimes the concept is essentially contested across users and no descriptive clarification or engineered revision can settle the dispute — the contestation is constitutive of the concept’s role in social-political life. The framework’s first job is to route to the operation that fits.

The framework runs in three modes. Deep clarification is the descriptive Tier-2 mode — pushing two levels deeper than the user’s starting depth, with each successive level a genuine mechanism beneath rather than horizontal detail at the same level. The mode produces four required sections in prose: surface explanation; mechanistic clarification two levels deeper; epistemic boundary (where settled knowledge ends and current-best-understanding begins); practical implications (what the deeper understanding changes about action or inference). Conceptual engineering is the ameliorative mode — taking a concept that’s failing to do what it should and proposing a revision via the Cappelen-Plunkett three-step structure (descriptive analysis of current function → normative analysis of what function the concept should serve → prescriptive proposal for revision). Definitional dispute (deferred per CR-6) handles essential contestation in Gallie’s sense — surfacing the structure of the disagreement rather than picking sides.

The framework’s load-bearing intellectual content is the stance routing between descriptive and ameliorative work, the vertical-depth discipline in deep clarification, and the implementation-problem acknowledgment in conceptual engineering. The stance routing happens at Q1 — “are you trying to clarify what the concept already means in current usage, or trying to engineer the concept toward what it should mean?” — and the routing matters because the two modes have different success conditions. Deep clarification succeeds when the user’s understanding of a stable concept gains depth; conceptual engineering succeeds when a candidate revision is proposed honestly with its costs and adoption challenges named. Conflating them produces the worst of both — descriptive drift presented as analysis, or stipulation smuggled in as a function the concept “really” serves.

The vertical-depth discipline in deep clarification is what separates this framework from explanation-as-restatement. Each successive level must be a genuine mechanism beneath the previous one, not horizontal detail at the same level (the lateral-drift trap), elaboration that adds words without depth (the elaboration trap), or jargon that signals expertise without showing mechanism (the jargon trap). The Feynman test applies — if you can’t explain it from primitives to a novice, you don’t understand it. The framework draws explicitly on Wittgenstein, Austin, Ryle, and Cavell on the ordinary-language tradition — meaning is constituted by patterns of use; premature stipulation produces definitions that miss what the concept is actually doing.

The implementation-problem acknowledgment in conceptual engineering is the framework’s defense against academically satisfying but practically inert revision proposals. Cappelen’s Fixing Language (2018) is unambiguous: even a correctly identified revision faces the problem that there is no clear mechanism by which the revision is taken up by language users. The framework requires the implementation problem to be acknowledged — without prescribing the Cappelen-pessimist or Haslanger-engaged response. Where the user is engineering for use within their own work, the implementation problem shrinks (the user is the adopter); where proposing for a wider community, it looms larger and the proposal must engage with social-political mechanisms rather than pretend proposal-equals-adoption.

The framework answers questions like: What does this author actually mean by ‘freedom’ in this passage? The current definition of this term in our organization isn’t doing the work it should — can you propose a revision? The word is being used in incompatible ways and we need to choose — or do we? What’s really going on underneath this concept beyond the surface explanation?

Systemic context

Conceptual Clarification is one of the analytical territory frameworks in Ora’s reasoning catalog (super-cluster A, Argument and Reasoning). It routes from upstream territories when concept-precision becomes the load-bearing issue — Argumentative Artifact (T1) hands off to T10 when an argument’s coherence problem is actually a concept-precision problem in a load-bearing premise; Paradigm Examination (T9) hands off to T10 when a paradigm-level dispute is concentrated on a single concept rather than the broader frame; Quick Orientation (T14) hands off to T10 when newcomer orientation is sufficient and the user wants depth on a specific concept rather than terrain-mapping. The framework’s three modes consume specific lenses — deep clarification draws on ordinary-language-clarification (Wittgenstein, Austin, Ryle, Cavell) and first-principles-decomposition (Aristotle, Descartes, Feynman); conceptual engineering draws on cappelen-plunkett-conceptual-engineering and haslanger-ameliorative-analysis; the deferred definitional-dispute mode draws on gallie-essentially-contested-concepts. Output from T10 flows back into the upstream framework that invoked it, or stands alone when the user invoked T10 directly.

Ora’s output

Example question: Our team keeps arguing about what “ownership” means when we say someone “owns” a project. The disagreements feel substantive but I can’t tell if they’re about the word or about something deeper. Can you clarify what’s going on?

Ora’s response (running T10 in deep-clarification mode, with escalation hook to conceptual-engineering):

The question presents as a routing question first — does this need descriptive clarification (the team is using “ownership” inconsistently and a clearer description of current uses would settle it) or ameliorative engineering (the inherited concept is failing to do work the team needs and a revision is in order)? I’ll start with deep clarification and watch for the escalation signal.

Surface explanation. “Ownership” in the team context names the relationship between a person and a project where the person is taken to be authoritative about the project’s direction, accountable for its outcome, and entitled to make decisions within its scope. That’s the usable everyday gloss.

Mechanistic clarification — level one beneath. The everyday gloss bundles three distinct relationships: authority (the right to make decisions); accountability (being answerable for outcomes); entitlement (the standing to be consulted, credited, or held responsible). In most workplace usage these three travel together, which is why the gloss works — but the bundling is contingent. Authority without accountability is dictatorship-shaped; accountability without authority is scapegoat-shaped; entitlement without authority or accountability is symbolic-ownership-shaped. When teammates argue about ownership, they are often arguing about which of the three components someone has, not whether they “own” the project simpliciter.

Mechanistic clarification — level two beneath. Beneath the three components is a structural question about what the project itself is. Authority over what? Accountability for what outcome? Entitlement to what credit? When the project’s boundaries are well-defined, the three components have clear referents. When the project’s boundaries are contested (does “the launch” include the post-launch support window? does “the redesign” include the migration plan?), authority/accountability/entitlement become contested by extension. Most workplace ownership disputes are downstream of project-boundary disputes that haven’t been surfaced.

Epistemic boundary. The decomposition into authority/accountability/entitlement is well-established in organizational theory and management scholarship — it’s not contested. The claim that ownership disputes are typically downstream of project-boundary disputes is current-best-understanding rather than settled — there’s good evidence for it in case studies of organizational conflict but the generality is empirical, not definitional.

Practical implications. When your team argues about ownership, the productive move is usually to translate the dispute into the three-component vocabulary: “Are we disagreeing about who has authority? Who is accountable? Who is entitled?” — and then check whether the disagreement is upstream of those three, in the project boundary itself. The translation tends to dissolve the worst disputes (it turns out two people thought they had authority over different things) and surface the genuinely substantive ones (two people both think they have authority over the same decision).

Escalation check. Does the deep clarification surface a normative tension that suggests escalation to conceptual-engineering? Yes, candidate one: if your team’s working concept of “ownership” routinely bundles authority and accountability without entitlement (the person held responsible but not credited), the concept is doing work that has costs the team may want to revise. That would be an ameliorative move — the concept of ownership in our team should function so that authority, accountability, and entitlement travel together rather than being split for managerial convenience. If you want me to run conceptual-engineering on that, I can. The descriptive baseline is what I just produced; the ameliorative pass would propose a candidate revision with the implementation problem acknowledged (your team is the adopter, so implementation is mostly within your control — the cost is in undoing inherited splits, not in coordinating a wider community).

That is what T10 produces on a concept that arrived as a descriptive question with normative tension underneath. The deep clarification surfaced the three-component structure, traced it down to the project-boundary level, and named the practical move (translate the dispute into the vocabulary, check upstream). The escalation hook surfaced the ameliorative work that would be available if the user wants it — without forcing it. The framework’s discipline is that the operation matches the question; the escalation is offered, not assumed.

Commercial AI comparison

Comparison content auto-populates when the comparison-refresh framework runs against this question. Drafters do not author this section.

Brief comparison commentary

Auto-populates with the comparison content above.

How to use this framework

You can run the Conceptual Clarification pattern with any AI of your choice. The composition is single-pass for whichever mode the routing question selects.

The prompt:

[Paste the framework specification]

The concept I want clarified: [name the concept and quote the context where it appears, if relevant.]

My stance (optional): [if you’re trying to engineer a revision rather than understand current usage, say so — that routes to conceptual-engineering rather than deep-clarification.]

The AI runs Q1 first to confirm the stance, then proceeds through whichever mode applies. Deep-clarification produces the four required sections (surface explanation, mechanistic clarification two levels deeper, epistemic boundary, practical implications). Conceptual-engineering produces the eight required sections (target concept named, descriptive baseline, function failures, ameliorative purpose, candidate revisions, implementation problem acknowledgment, revision costs, confidence per finding).

For best results:

1. State the stance if you have one. If you already know you want a revision, saying so up front routes you to conceptual-engineering rather than the descriptive baseline. If you want to understand the concept first and then decide whether revision is in order, leave the stance open and the framework will start with deep clarification with the escalation hook available.
2. Push back on horizontal drift. If the framework produces a “deeper” level that reads as more detail at the same level rather than a genuine mechanism beneath, ask explicitly for the mechanism — what does this depend on that the previous level didn’t name?
3. Don’t ask the framework to settle essentially contested concepts. If the concept’s contestation is constitutive (different users mean different things and no analysis closes the gap because the disagreement is about values rather than information), the framework will not produce a winner — it produces a structural map of the contestation. Asking it to pick is asking it to violate its own discipline.

The framework is deliberately tool-agnostic. The stance routing, the vertical-depth discipline, and the implementation-problem acknowledgment are conceptual disciplines that survive the lift to any environment.

Other examples

• Deep clarification on a technical concept that has accumulated overlays. A user asks what “consciousness” means when AI researchers use the term. The framework runs deep clarification, surfacing that the term bundles at least four distinct things in current AI discourse (phenomenal experience; access consciousness in Block’s sense; self-modeling; behavioral correlates of awareness). Level two beneath traces each component to its philosophical or empirical home and notes that “AI consciousness” claims are usually claims about one of the four with the others smuggled in by association. Practical implication: when reading AI consciousness debates, identify which of the four the writer means, and treat the other three as contested separately. Demonstrates deep clarification on a concept where the failure mode is conflation across components.

• Conceptual engineering on a concept causing organizational dysfunction. A user asks for a revision of “diversity” as their organization currently uses it — the descriptive baseline is that the term bundles demographic representation, viewpoint diversity, and inclusion-of-experience under one word, which has produced incoherent measurement and politicized debate. The framework produces the eight required sections: descriptive baseline (current bundled use); function failures (incoherent measurement, politicized debate); ameliorative purpose (the revised concept should be measurable, decoupled from political contestation, and serve the organization’s actual goals); candidate revision (split into three explicit terms with separate measurement and goals per term); implementation acknowledgment (the user is the head of the organization, so implementation is high-leverage but still requires coordination across managers and teams); revision costs (loss of the rhetorical convenience of the bundled term, possible alienation of stakeholders attached to the bundled framing). Demonstrates conceptual engineering on a concept where the load-bearing failure is bundling.

• Routing to definitional dispute. A user asks for clarification of “art” in the context of a debate about whether AI-generated images are art. The framework runs Q1 and surfaces that the question is essentially contested in Gallie’s sense — art is appraisive, internally complex, admits multiple competing weightings, and the contestation is socially productive rather than resolvable. The framework declines to produce a winner; instead it documents the structure of the contestation (which criteria each side weights — originality, intentionality, craft, expression, reception — and which exemplars each emphasizes). The user can act on the structural map by identifying their own weighting and recognizing that the disagreement is about values rather than information. Demonstrates the framework’s discipline against settling disputes that are constitutively unsettled.

Citations

The Conceptual Clarification Framework draws on three substantial traditions. The deep-clarification mode draws on the ordinary-language tradition (Wittgenstein’s Philosophical Investigations, 1953; Austin’s How to Do Things with Words, 1962; Ryle’s The Concept of Mind, 1949; Cavell’s The Claim of Reason, 1979) — meaning is constituted by patterns of use; premature stipulation misses what the concept is actually doing — and on first-principles reasoning (Aristotle, Descartes, Feynman) for the mechanistic-decomposition discipline that pushes each level to a genuine mechanism beneath the previous.

The conceptual-engineering mode draws on Cappelen’s Fixing Language (2018) for the three-step ameliorative structure and the implementation-problem framing; on Plunkett and Sundell’s “Disagreement and the Semantics of Normative and Evaluative Terms” (Philosophers’ Imprint 2013) for the metalinguistic-disagreement framework; on Haslanger’s Resisting Reality (2012) and “Going on, not in the same way” (2020) for the alternative implementation orientation that treats ameliorative work as continuous with social-political contestation; and on Burgess and Plunkett’s “Conceptual Ethics” (Philosophy Compass 2013) for the broader normative framing.

The deferred definitional-dispute mode (mode three, deferred per CR-6) would draw on Gallie’s “Essentially Contested Concepts” (1956), Connolly’s The Terms of Political Discourse (1974), and Waldron’s Law and Disagreement (1999) for the structural diagnosis of essential contestation and the discipline against forcing resolution where contestation is constitutive of the concept’s role.

The framework is single-author and originated 2026-05-01 as part of the analytical territory build-out. The within-territory disambiguation tree (Q1: stance) operationalizes the routing decision between descriptive and ameliorative work; the escalation hooks across modes ensure that work begun in one stance can pivot when the analysis surfaces material the other stance is shaped to handle.

Downloads

• Framework specification (PDF) — link to ora-ai.org canonical artifact when published
• Framework specification (plain text) — link to ora-ai.org canonical artifact when published
• Full white paper (PDF) — link when published