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?
Select an answer to reveal the explanation.
Short Explanation
Not every feature in an "AI project" is actually AI. The itinerary lookup is a plain database query — build it like one. Save the ML methodology for the part that genuinely needs to interpret ambiguous language.
Full Explanation
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. Option A is an unfounded generalization about cost with no basis in this scenario. Option B is false and dangerous; cognitive components require substantial testing, arguably more than deterministic ones, precisely because their behavior is probabilistic. Option C 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.