member-console/design/documents/reference-software-capability-feature-terminology.md

The terminology of software capabilities, features, and their kin

"Capability" and "feature" are among the most overloaded terms in software and business discourse, each carrying at least four competing formal definitions across enterprise architecture, product management, agile delivery, and strategic management. The confusion is not merely semantic — it reflects a deeper ontological question about whether we describe software in terms of what organizations can do, what products offer, or what teams deliver. No authoritative cross-disciplinary resolution exists, despite decades of standards work and ontology projects. This report maps the full terminological landscape: the formal definitions, historical genealogies, disciplinary variations, hierarchical relationships, and pragmatic usage patterns of capability, feature, and twelve related terms — then provides concrete guidance for practitioners navigating this ambiguity.

The stakes are real. Imprecise terminology causes miscommunication in requirements engineering, misalignment between business strategy and engineering execution, and confusion in procurement processes where "capability statements" and "feature lists" serve fundamentally different audiences. Academic research has repeatedly identified this problem: Georgiadou (2018) observed that the need for a glossary in virtually every software engineering publication is "evidence that the discipline is not yet mature enough even after 50 years."

---

Capability: six meanings in search of a definition

The word "capability" carries distinct formal definitions in at least six major frameworks, all sharing a common thread — an ability to achieve outcomes — while diverging sharply in scope, granularity, and purpose.

In enterprise architecture (TOGAF/ArchiMate), a business capability is "a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome." The foundational insight, articulated by Ulrich Homann in his influential 2006 Microsoft white paper, is that a capability describes what a business does without explaining how, why, or where. Capabilities abstract over people, processes, information, and technology into stable building blocks for strategic planning. ArchiMate 3.2 classifies capability as a Strategy Layer behavior element, explicitly noting it "corresponds to the business capability in the TOGAF framework." Business capability maps typically decompose two to four levels deep and are deliberately independent of organizational structure, making them more stable than org charts or process models.

In maturity models (CMM/CMMI), capability refers to process proficiency — how well an organization performs a particular process area, measured on defined maturity levels. Watts Humphrey developed the original Capability Maturity Model at Carnegie Mellon's SEI in the late 1980s, and the current CMMI v3.0 (2023, now under ISACA) assesses individual process areas on a 0–3 capability scale or organizational maturity on a 1–5 scale. Here, capability is about quality and consistency of execution, not what an organization can do but how well it does it.

In strategic management, Jay Barney's Resource-Based View (1991) defines capabilities as a firm's capacity to deploy and coordinate resources effectively — organizational routines, processes, and managerial competencies that may generate sustained competitive advantage when they are valuable, rare, imperfectly imitable, and non-substitutable (the VRIN framework). David Teece, Gary Pisano, and Amy Shuen (1997) extended this with dynamic capabilities: "the firm's ability to integrate, build, and reconfigure internal and external competences to address rapidly changing environments." This sense — capability as organizational competence — differs fundamentally from any product-level usage.

In defense architecture (DoDAF/NATO), capability means "the ability to achieve a desired effect under specified standards and conditions." NATO's Architecture Framework specifies that a capability is dispositional — an entity may possess it even without ever having manifested it. The U.S. Department of Defense's Architecture Framework v2.0 (2009) introduced a dedicated Capability Viewpoint with seven models for taxonomy, phasing, and mapping. This military origin is the genealogical root of enterprise architecture's usage: TOGAF 1.0 (1995) was derived directly from the DoD's TAFIM framework.

In the Scaled Agile Framework (SAFe), capability is "a higher-level solution behavior that typically spans multiple Agile Release Trains (ARTs)," existing at the Large Solution level and decomposed into features for implementation. This is the narrowest definition: a delivery work item in a hierarchy, sized to fit within a single Program Increment. SAFe's usage is scale-based rather than conceptual — a capability becomes a feature when scoped to a single ART.

In the Information Systems discipline, Bharadwaj's seminal MIS Quarterly paper (2000) defined IT capability as "the ability to mobilize and deploy IT-based resources in combination or copresence with other resources and capabilities." Two decades later, Grego et al. (2025) published a critical review in the International Journal of Management Reviews explicitly addressing the persisting "ambiguity about the use of important related, yet distinct, constructs like IT capabilities, IT-enabled capabilities and digital capabilities."

The common thread across all six usages is ability or potential — what can be done. The critical variations concern whose ability (the organization's, the product's, the platform's, the process's), at what level of abstraction (strategic, operational, delivery), and whether the emphasis is on what versus how well.

---

Feature: from manufacturing attribute to contested agile artifact

"Feature" entered software vocabulary by analogy from manufacturing, where product features described physical attributes (power windows, screen size). Its migration into software followed the broader movement of product management practices from consumer goods to digital products — a lineage traceable to Neil McElroy's 1931 Procter & Gamble memo and Intuit's founding in 1983 by former P&G brand manager Scott Cook.

The most rigorous academic definition comes from Kang et al.'s Feature-Oriented Domain Analysis (FODA) at Carnegie Mellon's SEI (1990): "a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems." FODA introduced feature models for managing commonality and variability across software product lines, organizing features hierarchically as mandatory, optional, or alternative. Czarnecki and Eisenecker (2000) broadened this to "a property of a domain concept relevant to some domain stakeholder, used to discriminate between concept instances." Riebisch (2003) later identified that even these SPL definitions "lack clear definitions, leading to ambiguities" in industrial application.

Feature-Driven Development (FDD), created by Jeff De Luca in 1997 for a Singapore banking project, produced the most constrained definition: "a small piece of client-valued functionality expressed in the form <action> <result> <object>" — for example, "Calculate the total of a sale." FDD features must complete within two weeks and are grouped into Feature Sets (business activities) and Subject Areas.

In SAFe, a feature is "a service that fulfills a stakeholder need," sized to be delivered by a single ART within a single Program Increment (~8–12 weeks). Features contain a benefit hypothesis and acceptance criteria and are decomposed into user stories. This definition is precise but entirely scale-dependent.

In standard Scrum and agile practice, "feature" has no formal definition. The Scrum Guide's unit of work is the Product Backlog Item (PBI), expressed as a user story. Mike Cohn acknowledged that "feature" was "not used by the original user stories team, which has led to feature being applied to different things in different organizations." He informally defined it as "a user story that is big enough to be released or perhaps big enough that users will notice," while cautioning that "theme, epic, feature, and user story are not terms with important specific meanings."

In UML, feature means something entirely unrelated: a property of a classifier (an operation or attribute). This creates inter-notation confusion that Riebisch (2003) explicitly flagged.

In SaaS marketing, feature takes its loosest form: any item on a pricing page comparison table, including integrations, usage limits, support levels, and settings — many of which are not "features" in any engineering sense. The marketing usage is granular and binary (included/not included), while engineering and PM usage is more nuanced.

The modern product management community has developed a notable counter-movement against feature-centricity. Marty Cagan (SVPG) distinguishes "feature teams" (given features to build) from "empowered product teams" (given problems to solve), calling feature-centricity an anti-pattern. Melissa Perri's Escaping the Build Trap (2018) coined the widely adopted concept of the "feature factory" — organizations measuring success by outputs shipped rather than outcomes achieved. Teresa Torres' Opportunity Solution Tree framework (2021) repositions features as validated solutions emerging from discovery, not as starting points. Despite this intellectual movement, "feature" remains entrenched as the dominant practical unit across tools, pricing models, and delivery frameworks.

---

How these terms evolved across decades and disciplines

The genealogy of "capability" in enterprise architecture traces a clear military-to-business migration path. The U.S. Department of Defense initiated TAFIM (Technical Architecture Framework for Information Management) in 1986, which informed TOGAF 1.0 in 1995. The C4ISR Architecture Framework (1996) and its successor DoDAF (2003) made capability-based planning central to defense acquisition. Homann's 2005–2006 work on capability-oriented modeling bridged the gap to enterprise architecture, drawing explicitly on Barney's Resource-Based View and Prahalad and Hamel's core competence theory. Forrester mainstreamed the concept in 2009 with "Business Capabilities Provide the Rosetta Stone for Business-IT Alignment." ArchiMate formalized the Capability element in its Strategy Layer in version 3.0 (2016). The concept then migrated further into agile scaling frameworks (SAFe) and platform engineering (CNCF maturity models).

"Feature" followed a parallel consumer-goods-to-software path. Product management migrated from P&G's brand management (1930s) through hardware product development into software with Microsoft's creation of the Program Manager role in 1984. Joel Spolsky recalled that Jabe Blumenthal's role on Mac Excel involved "translating MBA-speak into actual features." FDD formalized the term in 1997. The Agile Manifesto (2001) accelerated feature-centricity through its emphasis on "working software" delivered frequently. The 2010s brought the outcome-oriented counter-movement, but the 2020s show features persisting as the dominant currency of product communication.

---

The extended terminological landscape mapped

Beyond capability and feature, a constellation of related terms occupies the same conceptual space, each with its own disciplinary home and definitional baggage.

Functionality operates primarily as a mass noun describing what a system can do in aggregate. ISO/IEC 25010 defines Functional Suitability as "the degree to which a product or system provides functions that meet stated and implied needs under specified conditions," decomposed into completeness, correctness, and appropriateness. The countable form ("a functionality") is non-standard in formal writing; standards prefer "function" for discrete operations. The key distinction from "feature" is perspective: functionality describes behavior from the system's viewpoint; a feature describes value from the user's viewpoint.

Module derives from David Parnas's foundational 1972 paper "On the Criteria To Be Used in Decomposing Systems into Modules," which established information hiding as the primary criterion for modular decomposition. A module is a logical grouping mechanism — a design-time concept that does not require physical separation. In enterprise SaaS (SAP, Oracle), "module" takes on larger meaning: SAP's FI, CO, SD, MM, and HR modules each correspond to an entire business function, are independently implementable, and require separate training and expertise. This enterprise usage — module as major functional domain — is distinct from Parnas's software architecture concept. Cloud-native SaaS companies (Salesforce, HubSpot) have largely replaced "module" with "Cloud," "app," or "add-on."

Service carries at least three overlapping definitions. The OASIS SOA Reference Model (2006) defines it as "a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface." ITIL 4 (2019) defines it as "a means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks." In microservices architecture, services are fine-grained, independently deployable units with their own data stores. The architectural relationship is critical: services realize capabilities. The OASIS SOA-RM uses an electric utility analogy: the capability is generating and distributing electricity; the service is the wiring providing access; the interface is the wall outlet.

Component, as defined by Clemens Szyperski in his landmark Component Software (1998), is "a unit of composition with contractually specified interfaces and explicit context dependencies only" that "can be deployed independently and is subject to composition by third parties." The key distinction from module is physical versus logical: modules are design-time logical groupings; components are deployment-time physical packages. Services add network accessibility on top of component characteristics.

Affordance provides a bridge between capability (what a system can do) and usability (how users perceive what they can do). James Gibson's original ecological psychology definition (1979) described affordances as relational action possibilities in the environment, independent of the actor's perception. Donald Norman adapted the concept for design in 1988, focusing on perceived affordances, then acknowledged in 1999 that his usage conflated the actual affordance with perceptual information about it, introducing "signifier" as a corrective term. Rex Hartson (2003) proposed four types — cognitive, physical, sensory, and functional affordances — mapping to different stages of user interaction. The concept connects to capability and feature thus: a capability is an objective action possibility (Gibson's sense), a feature packages it for users, and an affordance (or signifier) communicates how to engage with it.

Requirement bridges the gap between needs and implementations. ISO/IEC/IEEE 29148:2018 distinguishes three processes: business/mission analysis, stakeholder needs definition, and system/software requirements definition — the last transforming "the stakeholder, user-oriented view of desired capabilities into a technical view of a solution." Functional requirements specify what a system shall do; non-functional requirements (increasingly called "quality requirements") specify how well. A 2017 IEEE study analyzing 530 industrial NFRs found that most actually describe behavioral properties, questioning whether the functional/non-functional dichotomy is as clean as traditionally assumed. In agile practice, features satisfy requirements, and user stories are lightweight requirement representations — Cohn's "placeholders for conversations" following the 3 C's pattern (Card, Conversation, Confirmation).

Epic and User Story occupy the agile delivery hierarchy. In SAFe, the formal ordering is Epic → Capability → Feature → Story → Task, each level scoped to a progressively smaller delivery boundary. Outside SAFe, the hierarchy is informal and inconsistent. Cohn defines an epic simply as "a large user story" while Jira implements it as a container/grouping mechanism — an inversion that creates confusion when teams from different tool ecosystems collaborate.

Offering functions as the most business-level term, describing the complete value proposition presented to the market — product plus service plus support plus pricing model. Gartner evaluates "offerings"; Forrester's primary scoring axis is "Current Offering." The term appears in analyst reports and executive communications but is conspicuously absent from customer-facing pricing pages, where "plan" or "edition" prevails.

Capacity is frequently confused with capability but carries a distinct quantitative meaning: how much can be done versus what can be done. An organization might have the capability to manufacture semiconductors but lack the capacity to meet demand. Notably, even Homann's foundational TOGAF-cited definition uses both words — "a particular ability or capacity" — suggesting overlap at the definitional level.

Feature flags/toggles occupy a distinct technical niche. Martin Fowler and Pete Hodgson (ThoughtWorks) defined four categories: release toggles (hiding incomplete code), experiment toggles (A/B testing), ops toggles (kill switches), and permission toggles (user segment gating). Feature flags bridge the engineering and product senses of "feature" by decoupling deployment from release — code ships continuously while product features are released strategically.

---

Taxonomic hierarchies that organize these terms

Several relationship patterns emerge consistently across frameworks, though no single universal hierarchy exists.

The enterprise architecture chain runs: Business Capability → realized by Service → implemented by Component(s) → composed of Module(s). This is the TOGAF/ArchiMate architectural pattern, where capabilities are stable strategic constructs and services are the externally facing mechanisms providing access. The SEBoK definition makes this explicit: "an outcome or effect achievable through use of features of a system of interest."

The agile delivery hierarchy (SAFe) runs: Portfolio Epic → Capability → Feature → User Story → Task. Each level maps to a specific organizational boundary — portfolio, large solution, ART, team, individual — and a delivery timebox.

The product marketing hierarchy in practice runs: Offering → Product/Edition → Module → Feature, from most abstract to most granular. "Capability" sits orthogonally — it can modify any level (platform capabilities, product capabilities, feature capabilities).

The requirements traceability chain runs: Business Need → Stakeholder Requirement → System Requirement (functional + non-functional) → satisfied by Feature → described by User Story.

The design perception chain runs: System Capability (objective action possibility, Gibson's affordance) → exposed via Feature (user-visible packaging) → perceived through Affordance/Signifier (Norman's concept) → enables User Action.

These hierarchies are not perfectly nested and often conflict. SAFe's capability-to-feature relationship is scale-based (multi-ART vs. single-ART), while enterprise architecture's capability-to-feature relationship is conceptual (enduring ability vs. specific implementation). The OASIS SOA-RM positions services as realizing capabilities, while SAFe positions features as decompositions of capabilities. Practitioners must be explicit about which hierarchy they are operating within.

---

How the industry actually deploys these terms

SaaS companies, cloud platforms, and analyst firms have developed distinct usage patterns that diverge from any formal framework.

On pricing pages, "feature" dominates as the granular, countable unit of comparison — presented in checkmark grids across tiers. "Capability" appears at a higher level, describing tier-level strengths or broad functional areas. Salesforce describes tiers with "advanced Data Cloud and AI capabilities" while listing specific "features" within. Slack titles its comparison tables as "feature" comparisons. A reported HubSpot analysis found that pricing pages leading with outcomes (capability-oriented framing) converted 34% better than those leading with features — suggesting the distinction has commercial implications.

AWS maintains the clearest terminological hierarchy among cloud platforms. "Services" are the fundamental product catalog units (EC2, S3, Lambda — 200+ services). "Features" are attributes within a service (Auto Scaling, Spot Instances). "Capabilities" operate at the organizational/strategic level: the Cloud Adoption Framework groups capabilities into six perspectives (Business, People, Governance, Platform, Security, Operations), and the Cloud Foundation framework defines 29 foundational capabilities for establishing a cloud environment, explicitly defining capability as "an organizational ability to leverage processes to deploy resources to achieve a particular outcome."

Analyst firms use "capabilities" as their primary evaluation unit. Gartner's Critical Capabilities methodology explicitly defines its subject as "the features or attributes that most differentiate products and services in a market" — creating a formal bridge where capabilities equal differentiating features evaluated at a strategic level. Forrester evaluates "product and service capabilities" as part of its Wave methodology. Both firms use "offering" as the standard term for the vendor's product/service combination under evaluation.

In government contracting, a "capability statement" is a standardized 1–2 page business resume covering core competencies, past performance, differentiators, and company data (CAGE code, UEI, NAICS codes). This is fundamentally organizational — "what can this company deliver and what evidence proves it?" — versus a feature list's product focus ("what does this software include?"). Government agencies frequently require capability statements as prerequisites for bidding.

Enterprise ERP vendors preserve "module" as their organizing concept. SAP's modules (FI, CO, SD, MM, HR) each represent entire business functions requiring separate implementation, training, and licensing. Full implementation of all SAP modules can cost $50–500 million and take years. This is a fundamentally different granularity from "feature" — a module is closer to a product in scope.

No major tech company style guide (Microsoft, Google, Atlassian) prescribes when to use "feature" versus "capability" versus "functionality." A Microsoft Learn forum thread addressing this question concluded that the terms "are loosely used, likely not to confuse users" — an inadvertent admission that even the company's internal documentation lacks authoritative disambiguation.

---

What scholars have found about terminological confusion

Academic literature has explicitly identified and attempted to address the terminology problem, though no resolution has achieved cross-disciplinary adoption.

Clarke et al. (2016) found "a degree of term confusion, with the mapping of concepts to terms lacking precision" in software development, noting that newer process approaches (Agile, Lean) introduced terms that sometimes represent novel concepts but often "correspond to long established concepts that have been repackaged." They proposed developing a canonical software process ontological model. Georgiadou (2018) made the striking observation that the persistence of mandatory glossaries in software engineering publications demonstrates the discipline's terminological immaturity.

The feature interaction problem in telecommunications provides the most consequential evidence that imprecise feature definitions have engineering costs. Originating in Bowen et al.'s 1989 paper, this research community sustained its own dedicated workshop series (Feature Interaction Workshops) to address how features in telephony systems can conflict in unexpected ways. Keck and Kuehn's 1998 IEEE survey found that even defining what constitutes a "feature" or "feature interaction" was contested, and "no full approach exists; they are all partial solutions."

The SPL community's formalization efforts revealed similar problems. Schobbens et al. found that various feature diagram notations suffered from "purported ambiguity and lack of precision and expressiveness." Riebisch (2003) documented that industrial application of feature models exposed "a deficiency of clear definitions of the feature model elements, their syntax and semantics" causing "ambiguities and inconsistencies."

The IS discipline's capability literature shows parallel confusion. Bharadwaj's foundational IT capability definition (2000) spawned two decades of research, but Chae et al. (2014) found contradictory results — no significant link between IT capability and firm performance in 2000s data, possibly because IT standardization eroded capability-based advantages. Grego et al. (2025) directly addressed the terminological problem, distinguishing IT capabilities (technical organizational competencies), IT-enabled capabilities (emergent competencies from combining IT with organizational resources), and digital capabilities (digital objects encapsulating repeatable action patterns).

From a Science and Technology Studies perspective, Pinch and Bijker's concept of "interpretive flexibility" (1984) — where different social groups assign different meanings to the same artifact — directly explains why developers, product managers, marketers, and executives each define "feature" and "capability" differently. The concept of "technological frames" (shared assumptions within a social group) explains why these disciplinary meanings persist despite standardization efforts. The terminology problem is not merely technical but sociological.

The Jobs-to-Be-Done framework offers perhaps the most radical reframing. Clayton Christensen's insight — "customers don't buy products; they hire them to make progress in their lives" — repositions features as solutions to jobs rather than as ends in themselves. The famous milkshake study demonstrated that feature improvements (thicker, chocolatier) missed the actual job (making a boring commute less tedious). Thompson, Hamilton, and Rust's "Feature Fatigue" research (2005) found empirically that too many features encourage initial purchase but damage satisfaction — a finding that suggests the feature-centric paradigm has measurable costs.

The Kano model (Noriaki Kano, 1984) adds another dimension by categorizing features not by scope or hierarchy but by satisfaction impact: Must-Be features (expected; absence causes dissatisfaction), One-Dimensional features (satisfaction proportional to performance), Attractive features (delighters; absence causes no dissatisfaction), Indifferent features (no impact), and Reverse features (presence causes dissatisfaction). Critically, categories shift over time — WiFi in hotels migrated from Attractive to Must-Be as expectations evolved.

---

Practical guidance for choosing the right term

Given the genuine ambiguity, practitioners need contextual rules rather than universal definitions. The following guidance synthesizes the formal definitions, industry practice, and scholarly analysis above.

Use "capability" when describing what an organization, platform, or system can do at a strategic level, independent of specific implementation. Capability is the right term for business capability maps, enterprise architecture discussions, maturity assessments, government capability statements, and any context where the emphasis is on enduring abilities rather than specific implementations. In SAFe, use it specifically for solution behaviors spanning multiple ARTs. When using the term, specify which sense you intend — organizational capability (RBV/strategic), product capability (what the product enables), platform capability (what the platform provides), or delivery capability (SAFe work item).

Use "feature" when describing a discrete, user-visible unit of product functionality that delivers value and can be developed, released, and communicated as a distinct item. Feature is the right term for product backlogs, pricing page comparisons, release notes, feature flags, and any context where the audience is users, buyers, or delivery teams. In FDD, follow the <action> <result> <object> template. In SAFe, use it for functionality deliverable by a single ART within a PI. Be aware that leading PM thinkers advocate framing work in terms of outcomes rather than features to avoid the "build trap."

Use "functionality" as a mass noun describing what a system can do in aggregate ("this plan offers more functionality"), never as a countable noun. For discrete units, use "function" or "feature" instead.

Use "module" for major, independently implementable functional domains — particularly in enterprise ERP contexts (SAP modules, Oracle modules) or when describing large-scale system decomposition following Parnas's information-hiding principle.

Use "service" when describing a network-accessible mechanism that provides access to capabilities through a defined interface — in SOA, microservices, cloud platforms, and ITIL service management.

Use "component" for independently deployable units of composition with contractually specified interfaces — the physical packaging of logical modules.

Use "offering" in business-level, portfolio-oriented contexts — analyst evaluations, executive communications, and market positioning. It encompasses product, service, support, and pricing as a unified market proposition.

Use "affordance" (or "signifier") when discussing how interface design communicates possible actions to users. Follow Norman's later recommendation to use "signifier" for the perceptual cue and reserve "affordance" for the actual action possibility, though this distinction is rarely observed in industry practice.

---

Conclusion: terminology as a mirror of organizational structure

The terminological landscape of software development is not merely imprecise — it is productively ambiguous, reflecting genuine differences in how disciplines conceptualize the same artifacts. Enterprise architects see capabilities as stable strategic building blocks. Product managers see features as units of customer value. Software engineers see components and services as deployment artifacts. Marketers see features as competitive differentiators. Scholars see contested concepts requiring formal ontology work. Each perspective is internally coherent; the confusion arises at disciplinary boundaries.

Three insights emerge that existing literature has not adequately synthesized. First, the capability-feature relationship is not hierarchical in any single, stable sense — it is perspectival. In SAFe, it is scale-based (multi-ART vs. single-ART). In enterprise architecture, it is abstraction-based (enduring ability vs. specific implementation). In the SEBoK/defense tradition, it is outcome-based (capability as effect achieved through features). The common shorthand "capability > feature" obscures these fundamentally different relationship types.

Second, the JTBD and Kano frameworks suggest that the entire feature/capability vocabulary may be artifact-centric when it should be outcome-centric. Features describe what products have; jobs describe what customers need. Kano's dynamic categories reveal that the same functionality shifts from "attractive" to "must-be" over time — a lifecycle dynamic that static feature lists cannot capture.

Third, Conway's Law suggests that terminological disagreements between teams may be structural rather than semantic. When enterprise architects, product managers, and engineers use "capability" differently, they may not need a shared definition — they may need explicit translation protocols between their respective frames. The most practically useful intervention may not be universal definitions but rather well-documented mappings: "When the architecture team says 'capability,' the delivery team should understand this as corresponding to [X] in their framework."

The discipline's terminological immaturity, as Georgiadou noted, is a feature (in the Kang sense: a prominent characteristic), not a bug. Software development operates at the intersection of engineering, business strategy, design, and human psychology. A single vocabulary cannot serve all four without either oversimplifying or becoming so abstract as to be useless. The practical solution is not terminological unification but terminological awareness — knowing which definition you are using, which audience you are addressing, and which framework you are operating within.