Hot air diagnostic
The hot-air diagnostic is a test for whether a name for a piece of user activity has anything specific underneath it, or whether it's just being held up by convention. To run it, try to list the concrete particulars that justify the name; if nothing specific surfaces, the name is hot air. Aspirational phrasings like "finds the right job" or "a seamless experience" tend to fail this test — they sound concrete but resist any actual specification.
Definition
A test for whether a scoped transition has specifiable difference-structure underneath its name, or is sustained by convention alone.
The dense-cluster test
The diagnostic asks one question: can a dense cluster of underlying differences be surfaced to justify the name? The differences here are condition-deltas — what about the user's state changes from start to result. If those differences can be specified concretely and they cohere around the name, the name is doing structural work. If the name floats free of any specifiable cluster, it's hot air — held up by familiar phrasing rather than by anything underneath it.
The diagnostic is the validation side of the aspect toggle discipline. The toggle alternates way-naming (the transition as activity) with difference-specification (the transition as condition-deltas); hot air is what way-naming alone produces when difference-specification isn't run against it.
Operations that need underlying structure
A scoped transition with specifiable difference-structure can participate in framework apparatus. A hot-air name cannot. Three operations break without underlying structure:
- Clustering: overlapping characteristics with neighboring transitions requires specifiable characteristics to overlap. A name with nothing underneath has nothing to align against.
- Nesting: anchoring parent-child relationships in a stack requires specified start and result conditions. A name without endpoints can't sit inside larger transitions or contain smaller ones.
- Verification: instrumenting and checking against actual user behavior requires concrete specification. A name with no specified contents can't be confirmed or refuted.
A hot-air name may show up in a slide deck, a metric definition, or an OKR, but it can't anchor framework work. It's a research artifact, not a workable object.
How names go hot-air
- Aspirational modifiers unratified by specification — "the right job," "properly onboarded," "a seamless flow." The modifier carries weight the specified differences don't substantiate.
- Coherent phrase, heterogeneous characteristics — the name reads cleanly but covers cases that don't share underlying difference-structure. Unrelated transitions get bundled under one label.
- Composite name with unspecified sub-relationships — the name strings together sub-transitions whose connection to each other is asserted by the phrase but not specified beneath it.
Example
"Aha moment" is the canonical hot-air name in activation work. It sounds central — the moment the user gets it — and team after team builds programs around producing one. Run the diagnostic and the name fragments. What specifically changes in the user's state at this moment? The honest answers tend to be either generic ("they understand the product better") or proxy-substitutes ("they hit our activation event"), neither of which specifies a difference-structure. The name persists by industry convention, with no underlying cluster of differences to ground it. See aha moment for the longer critique.