Meridian is deciding between two designs for the maintenance-triage assistant: (A) one large prompt that asks the model to read a raw log entry and, in a single pass, extract fields, classify the fault, and decide the shutdown flag; or (B) three separate, chained prompts, each handling one of those three sub-tasks in sequence. Which factor most directly favors design (B) for this use case?
Select an answer to reveal the explanation.
Short Explanation
Splitting the job into three smaller, single-purpose steps means that if the shutdown-flag decision comes out wrong, you can look at exactly that step in isolation and fix it - one giant prompt doing everything at once makes it much harder to tell which part misfired.
Full Explanation
Separating extraction, classification, and the shutdown decision into distinct chained steps most directly helps because it isolates each sub-task's output, making it far easier to verify correctness, debug a wrong result, or independently improve one step's prompt without disturbing the other two - a single monolithic prompt entangles all three, so a failure in the shutdown-flag decision is harder to trace back to its cause. The claim that the chained design is always cheaper in total token cost is not reliably true - splitting into multiple calls can add overhead (repeated system context, multiple round trips) and is not guaranteed to be cheaper in every case, so cost is not the dependable justification here. The claim that a single prompt can never perform more than one task is factually wrong - well-designed prompts routinely ask a model to extract, classify, and decide in one pass, and many production systems do exactly that; it's a legitimate design option, just one with the debugging trade-off described above. The claim that chaining removes the need for any prompt engineering is false - each of the three separated steps still needs its own carefully designed prompt; chaining changes how the work is organized, it does not eliminate the work of designing each prompt. This item tests weighing chain-composition trade-offs (debuggability/verifiability) rather than picking an answer based on absolute claims about cost or feasibility.