Decision Making questions present you with a fixed set of eligibility conditions — for a job, a bank loan, a housing scheme, or any other selection process — and then give you a candidate's profile. Your job is to match the profile against the conditions and pick the right outcome: selected, rejected, referred to some authority, or data inadequate.
Think of yourself as a junior officer sitting in an office. A file lands on your desk. You have a checklist (the conditions). You go through each item on the checklist against the applicant's details. You do not exercise personal judgment — you follow the rules exactly as written. That is the entire skill this question type tests.
Here is the analogy that makes this click: imagine a bouncer at a club with a strict entry list. Age above 18? Ticket purchased? ID proof? If any mandatory condition fails, no entry. If there is a "special case" condition — like "if the guest is on the VIP list, call the manager" — you do that instead of a flat rejection. You do not improvise. The rules are the rules.
What makes these questions tricky is not the logic itself — it is the volume of conditions and the presence of special-case exceptions. Most candidates rush through the conditions, miss one special case buried at the end, and pick the wrong outcome. The exam is testing whether you are methodical, not whether you are clever.
In the UP Police Constable exam, these questions typically appear as a set: one paragraph of 5–7 conditions followed by 4–6 individual candidate profiles, each carrying its own question. This means if you read the conditions once carefully, you can solve the entire set quickly. The time investment is front-loaded.
The four possible outcomes you will encounter are almost always some variation of:
Understanding when each outcome applies — especially the referral and inadequate-data options — is where most marks are won or lost.
Every problem has two parts: the condition set and the candidate data. Before you touch the candidate data, you need to understand the condition set deeply.
Mandatory Conditions — Every candidate must satisfy these. If even one mandatory condition fails and there is no special exception for it, the answer is rejection.
Special Exception Conditions — These are the "but if..." rules. They save a candidate from outright rejection by redirecting the decision to a higher authority. These almost always appear near the end of the condition list. Missing them is the single most common error.
The "Data Inadequate" trap — This outcome applies when the candidate's profile does not mention something that is a mandatory condition. If the condition says "must have 60% in graduation" and the candidate's data says nothing about graduation marks, you cannot assume they qualify — the data is inadequate.
Read the conditions in two passes.
First pass: Identify which conditions are mandatory (always required) and which are special-case redirects. Label them mentally:
Second pass: For the special-case redirects, identify exactly what triggers them — is it a failure of one specific condition, or an exceptional value in a condition?
Look at the difference between these two types of redirect conditions:
Both types appear in UP Police exam sets. The second type (triggered by a positive exceptional value) catches more candidates off-guard.
Here is the correct sequence for evaluating any candidate profile:
Step 1: Check all mandatory conditions first. If any mandatory condition fails, immediately check whether there is a special exception for that specific failure. If yes, output the exception (referral). If no exception exists for that failure, output rejection.
Step 2: If all mandatory conditions pass, check whether any special-case conditions are triggered by the candidate's data (for example, collateral above a threshold, or age outside range when everything else is fine).
Step 3: If no special conditions are triggered and all mandatory conditions pass, output selection/grant.
Step 4: If the candidate's profile is silent on a mandatory condition — no mention at all — output data inadequate.
Consider a candidate who fails the age condition but meets everything else. Many conditions sets say: "If the candidate satisfies all other qualifications except age, refer to the Director." If you check age first and stop there, you will output "not selected" — which is wrong. You need to verify that all other conditions pass before applying the age exception.
This is the critical discipline: when a referral condition says "satisfies all other conditions except X", you must verify the "all other conditions" part before applying the referral.
These two are frequently confused. Use this rule:
If the candidate's profile gives you enough information to confirm a failure, it is "not selected." If the profile is simply missing information needed to evaluate a condition, it is "data inadequate."
Some sets have two or more special-case conditions. When evaluating a candidate, check all of them. If two special conditions are simultaneously triggered, the question will typically make it clear which one takes precedence (or the scenario will be designed so only one can trigger at a time). If genuinely ambiguous, "data inadequate" may be correct.
Label the four possible outcomes as M-R-E-D: Met (selected/granted), Referred (special case), Ejected (not selected), Data absent (inadequate). Before touching the candidate's profile, write MRED on your rough paper. As you check each condition, eliminate options. This prevents you from settling on "Ejected" when a referral condition applies. Standard approach: random scanning of conditions, ~90 seconds. MRED approach: sequential elimination, ~50 seconds per candidate after reading the condition set once.
When you first read the condition set, underline every "if... then refer to..." phrase before solving any individual question. In a set of 5–6 questions, this 20-second investment saves you from re-reading the full condition set for each candidate. Without this: re-reading conditions 5 times = 150 seconds lost. With this: one targeted check against your underlined triggers = 15 seconds per candidate.
When a candidate's profile does not mention a parameter that is part of a mandatory condition, immediately mark it as a "data inadequate" candidate. Do not assume the parameter is satisfied. For example, if conditions require a recommendation letter and the profile says nothing about a recommendation letter, that is missing data — not a passing condition. This rule alone separates a 3/5 score from a 5/5 score on a five-question set.
When a referral condition says "if candidate meets all other conditions except [X]", create a quick mental checklist of all non-X conditions and tick them off. If even one other condition also fails, the referral does not apply and the answer becomes outright rejection. This two-second verification step prevents the common error of applying a referral when the candidate has multiple disqualifications. Saves 1 wrong answer approximately every 3 sets.
Age conditions appear in almost every Decision Making set. Convert the given birth year to age relative to the exam year immediately. If the exam question mentions a year (e.g., "as of December 2005"), calculate age as: exam year minus birth year, then adjust for whether the birthday has occurred yet in that year. Do this calculation the moment you see a birth date — before reading the rest of the profile. Standard approach: revisiting birth date while checking conditions = recalculation error risk. Anchor approach: one calculation upfront, referenced throughout = zero recalculation errors.
When a Decision Making set lands in front of you, follow this sequence without deviation.
Read conditions (90 seconds max): Mark each condition as mandatory (M) or referral-trigger (R). Underline referral triggers specifically.
For each candidate profile:
Start with the disqualifying conditions — outstanding loans, missing documents, or any hard-rejection criterion. If one is triggered and has no referral exception, mark "not selected/not granted" and move on.
If no hard rejection, check mandatory conditions one by one. If one fails, check whether a referral condition covers that specific failure. If yes, verify that all other mandatory conditions pass. If all others pass, apply the referral.
If all mandatory conditions pass, check whether any exceptional-value conditions (like very high collateral, or being over-age when everything else is fine) trigger a referral.
If everything is clean and all conditions pass, select/grant.
If the profile is silent on any mandatory condition, mark data inadequate.
Commit to your answer and move on. Do not second-guess once you have applied the framework.
Why this question: This is the classic faculty selection format — multiple conditions with both a deficiency referral (missing PG) and an age-limit referral. Babli's profile is designed to test whether you notice the age exception.
Solving path: Check Babli's profile against each condition. MCA with 68% — condition (c) satisfied. Programming experience of 2.5 years — condition (b) satisfied (the "or" means either work or programming experience works). Interview score 40 out of 50 — condition (d) satisfied (minimum 25 required). Now check condition (a): age limit is 23–28 years, Babli is 30 — this fails. Now look for the referral covering age: condition (g) says if the candidate satisfies all other qualifications except age, refer to Director. All other conditions are met. Therefore, case goes to the Director of the Centre.
Why this question: This tests the bank loan format. Raman's profile appears straightforward — but the age calculation relative to an implied reference year is the subtle check.
Solving path: Raman has 7 acres (more than the required 5), can produce ₹8 lakhs collateral (meets the threshold exactly), has a Panchayat Pradhan recommendation letter, and has no outstanding loan. The age calculation: born 1955, reference year 2005 = 50 years, which is at the boundary of the age limit. All conditions pass. Advance is to be granted.
Why this question: Digvijoy's profile introduces the "two crops" special condition — a positive trigger that redirects to Chairman. Many candidates will look at 4 acres (below the 5-acre minimum) and immediately output "not granted" without reading the special crop condition.
Solving path: Digvijoy has only 4 acres, which normally fails the land condition. Before marking "not granted", check the special conditions. The special condition states that if a farmer grows more than one crop per piece of land, the case is referred to the Chairman. Digvijoy grows two crops per piece of land — this triggers the Chairman referral. The answer is: case to be referred to the Chairman.
Why this question: Dinesh Singh has an outstanding loan — this is a hard rejection criterion with no referral exception. The question is testing whether you are distracted by his other strong credentials (9 acres, ₹8 lakhs collateral, fixed deposit).
Solving path: Scan Dinesh's profile. Outstanding loan of ₹4 lakhs — this directly violates the condition requiring no outstanding unpaid loan. Check whether any referral condition covers outstanding loans. No such referral exists in the condition set. Therefore: advance is not to be granted. His 9 acres, ₹8 lakhs collateral, and ₹6 lakhs fixed deposit are irrelevant — one hard disqualification ends the analysis.
Why this question: Vijay's case tests the "data inadequate" distinction. He has 72% marks in his "final examination" — but the condition requires 65% in the overall degree. These are not the same thing.
Solving path: Vijay is a Computer Engineer (correct discipline), 70% in Selection Test, 48% in Interview. Now check degree marks: the condition requires first class with minimum 65% in the degree overall. The profile says 72% in "final examination" — this refers to the final semester or year exam, not the aggregate degree percentage. Since the aggregate degree marks are not provided, the condition about overall degree marks cannot be verified. Output: data inadequate.
Stopping at the first failed condition without checking referral rules. When a condition fails, the analysis is not over. You must check whether a referral condition exists for that specific failure before outputting rejection.
Applying a referral without verifying "all other conditions." Referral conditions that say "meets all other qualifications except X" require you to confirm that every other condition is indeed satisfied. If two conditions fail, no referral applies — it is outright rejection.
Confusing "more than ₹6 lakhs" with "at least ₹8 lakhs." In bank loan problems, collateral thresholds are precise. "More than ₹6 lakhs" does not meet a requirement of "at least ₹8 lakhs." Read the exact wording of both the condition and the candidate's data.
Treating "final examination marks" as "overall degree marks." These are different. Semester or final-year exam percentages are not the same as the aggregate degree percentage. When the condition specifies overall degree marks and only partial marks are given, the correct answer is data inadequate, not a pass or fail decision.
Ignoring the "or" in compound conditions. A condition like "work experience or programming experience" is satisfied if either is present. Many candidates read this as "and" and wrongly reject candidates who have one but not the other.
Not calculating age before starting condition checks. Leaving the age calculation for later creates errors under time pressure. Calculate age from the birth date the moment you see it, before evaluating any other condition.