Skip to content

Essential/Incidental Feature Sort

A classification method — instantiates Design-Principle Extraction and Reapplication

Sorts every feature of a single source into essential, supporting, optional, accidental, or source-specific — using cases where the source fails to test which features actually carry the logic.

The Essential/Incidental Feature Sort is the archetype's main defense against cargo-cult copying, applied to one source in depth. It takes the full feature list of a single admired example and forces each feature into a category — essential, supporting, optional, accidental, or source-specific — so that the design logic can be separated from the things that merely came along with it. Its distinguishing test is counterfactual: a feature earns "essential" only if the source's function would break without it, and the sharpest way to find out is to look at negative cases — situations or imitators where the feature is present but the result still fails, or absent yet the result still holds. Visibility is not evidence of importance, and this sort exists to sever that link.

Example

A beloved independent coffee shop is opening a second location, and the owners are terrified of losing the magic. They list what the flagship is: single-origin beans dosed by weight, baristas who learn regulars' names, the exposed-brick wall, the hand-thrown ceramic cups, the specific playlist, a nine-minute average wait. Then they sort. Comparing against negative cases does the real work: a nearby copycat that installed identical exposed brick and ceramic cups but hemorrhaged customers tells them those are source-specific atmosphere, not the logic; a busy airport kiosk with none of the decor but rigorous dose-by-weight and fast, warm service that people still love tells them those are essential. The playlist sorts to optional, the nine-minute wait to accidental (a symptom of one espresso machine, not a virtue).

The output is a labeled feature list the second location can act on: replicate the essentials (weighed dosing, name-learning service), budget the supporting bits as affordable, and consciously not spend on the exposed brick as though it were the secret — because the failed copycat already proved it isn't.

How it works

The method's engine is the five-way taxonomy plus a counterfactual test for each feature: would the source still achieve its function without this? Features that pass are essential; features whose removal only degrades are supporting; features that could be swapped freely are optional; features explained by history or accident are accidental; features tied to this source's unique context are source-specific. Negative-case comparison is what makes the test bite — instead of arguing in the abstract about importance, the sort looks for real cases where the feature and the outcome come apart, which is the fastest way to expose a visible-but-inessential feature.

Tuning parameters

  • Category granularity — the full five-way taxonomy vs a blunt essential/incidental binary. Finer categories guide reuse better (you know what's supporting vs merely optional) but take longer and invite bickering over borderline calls.
  • Counterfactual strictness — how demanding the "would it break without this?" test is. Strict testing shrinks the essential set toward the true core; lax testing lets cherished-but-inessential features slip into "essential."
  • Negative-case effort — how hard you hunt for real failing/succeeding counter-cases vs reasoning from armchair. More hunting is more reliable and more expensive.
  • Aggregation level — sorting fine-grained features vs bundled feature groups. Bundling is faster but can hide an incidental feature riding along inside an essential group.

When it helps, and when it misleads

Its strength is that it directly attacks the failure this whole archetype exists to prevent: earnestly reproducing the visible trappings of a success while missing the mechanism. The negative-case discipline gives it teeth a pure judgment call lacks.

Its central risk is exactly the pathology it fights — cargo-cult reasoning, mistaking a salient surface feature for the cause because it is what you can see.[1] The sort can also be gamed: a team fond of a feature can quietly relax the counterfactual test until its darling qualifies as "essential." And it can under-credit features that matter only in combination, since the one-at-a-time test misses interactions. The discipline is to anchor every "essential" label to a real negative case, and to re-run the sort on feature pairs where interactions are suspected.

How it implements the components

  • essential_incidental_feature_filter — this is the sort's whole job: classifying each feature of a single source into essential / supporting / optional / accidental / source-specific so only the logic-carrying features are considered for transfer.
  • negative_case_comparison — it uses cases where the source (or an imitator) fails to test whether a feature actually carries the function, rather than accepting visibility as importance.

It sorts within one source by functional necessity, where the Benchmark Deconstruction Grid separates essential from incidental by recurrence across many sources; it consumes the structure and constraint analysis produced by the Function-Behavior-Structure Matrix and Constraint Laddering Interview rather than producing them.

References

[1] Cargo cult — Richard Feynman's coinage for reproducing the visible forms of a successful practice (the runways, the headphones) while missing the mechanism that actually made it work. The sort exists to break the assumption that a feature's visibility is evidence of its importance. ↩