Meridian's rebooking assistant needs to both interpret a passenger's free-text request (a cognitive task) and look up that passenger's itinerary in a legacy reservations database (a deterministic lookup). Why does separating these two components matter during Business Understanding?

Separating cognitive from non-cognitive components is a distinct Business Understanding enabler because not every feature bundled into an 'AI project' actually requires AI/ML methodology. Interpreting a passenger's free-text rebooking request is genuinely cognitive — it involves ambiguity and pattern recognition best suited to a language model. Looking up a known passenger's itinerary in a structured legacy database, however, is a deterministic operation with a fixed, rule-based answer, and forcing it through ML methodology (data collection, labeling, model training, ongoing monitoring) would add unnecessary cost, complexity, and risk with no accuracy benefit over conventional software engineering. The claim that deterministic components are always more expensive to build than cognitive ones is an unfounded generalization about cost with no basis in this scenario. The claim that cognitive components never require any testing before deployment is false and dangerous; cognitive components require substantial testing, arguably more than deterministic ones, precisely because their behavior is probabilistic. The suggestion that the legacy database lookup should be reclassified as an AI capability for consistency across the project inverts the correct logic — reclassifying a deterministic lookup as an AI capability adds needless overhead rather than removing it. Correctly separating these component types keeps the project's AI effort focused only where it delivers real value.