AI Glossary / Governance, ethics and safety / Beginner
Favorable label
Definition
A favorable label is the outcome category designated as desirable or beneficial for the people considered in a fairness analysis. In a binary decision dataset, it might represent receiving access to a service rather than being denied access. The designation gives fairness calculations a clear direction. It is a contextual choice, not a property that follows automatically from whether the stored value is 1, 0, positive, or negative.
What it means
Software needs to know which outcome an assessment treats as favorable. Otherwise “positive” predictions can be interpreted in the wrong direction. A dataset's positive class may describe a problem, while the favorable outcome for an affected person may be its absence.
For example, a label coded 1 could mean “request delayed”. That numerical value is positive, but delay is not necessarily the beneficial outcome. Another dataset could use 1 for “request completed”, producing the opposite interpretation.
The meaning should be documented in words before configuring the metric. Favorable also depends on whose interests and which decision are being assessed; a label's convenience for the organization is not enough to settle that question.
How it works
Identify the decision represented by the labels and the people affected by it. State which outcome is treated as favorable for the analysis and why. Check how that outcome is encoded in both reference labels and model predictions.
Configure the fairness tool with the corresponding value. In AIF360's binary-label dataset interface, favorable and unfavorable values are explicit configuration fields, so the numerical mapping can be made clear rather than inferred from a column name.
When reporting results, describe the outcome and denominator in ordinary language. If labels are recoded, update the configuration and verify a small set of hand-calculated examples. A correct calculation using the wrong favorable label can produce a misleading interpretation even when the software runs without an error.
Three practical examples
1. A service-access review designates “access granted” as favorable and checks that its encoded value matches the fairness tool's configuration.
2. A queue-management analysis treats “resolved within the agreed period” as favorable rather than assuming that a label called “positive delay flag” represents a benefit.
3. A dataset migration reverses the numeric coding of two outcomes, prompting the team to update favorable-label metadata and confirm that reported selection rates retain their intended meaning.
Think of it this way
Think of putting an arrow on a measuring scale to indicate which direction represents the outcome being examined. Without the arrow, a larger number can be mistaken for improvement even when it means more of an undesirable event.
The analogy is limited because not every decision has a universally agreed beneficial direction. Some outcomes involve tradeoffs or different stakeholder perspectives. The label designation clarifies a specific analysis; it does not resolve all questions about whether the decision process is appropriate.
Worked example
Suppose a toy dataset codes “completed on time” as 0 and “delayed” as 1. In group A, 80 of 100 requests are completed on time. In group B, 60 of 100 are completed on time.
If on-time completion is the favorable outcome, its rates are 80% and 60%, with a lower-to-higher ratio of 0.60/0.80 = 0.75. The delay rates are instead 20% and 40%.
If an analyst mistakenly treats stored value 1 as favorable, the analysis measures delay and reverses which group has the higher favorable-coded rate. The software may perform the arithmetic correctly while the report describes the wrong benefit. These invented counts illustrate label orientation, not a legal threshold or a complete fairness assessment. Sample uncertainty and the reasons for delays require separate examination.
Illustrative case study
Fictional case: Brooklane Services merges two request datasets. One uses 1 for a successful completion, while the other uses 1 for an unresolved request. A preliminary dashboard combines them without reconciling the meanings.
The team writes an explicit label dictionary, recodes both datasets to the same semantic outcome, and checks example records against their source descriptions. It then recalculates group outcome rates with the favorable value stated in the report.
This fictional case illustrates a data-definition error. The corrected mapping makes the analysis interpretable, but does not establish that the underlying service is fair or that the original outcomes were recorded accurately.
Common misconceptions and mistakes
Do not assume favorable always means the number 1. Encoding is a convention that must be checked.
Do not confuse favorable with correct. A model can incorrectly predict a favorable outcome, and a correct prediction can describe an unfavorable outcome. Fairness and performance calculations need those distinctions.
Avoid assuming a favorable label settles every stakeholder's interests. A decision may have several consequences, and a binary label can hide them. Also distinguish a predicted label from a final action: a model recommendation is not always the outcome a person actually receives.
Business use
Explicit favorable-label definitions reduce interpretation errors in fairness dashboards, data integrations, and model comparisons. They make it easier for technical and operational teams to discuss the same outcome.
Include the mapping in dataset documentation and review it whenever outcomes are recoded or workflows change. Reports should name the benefit or disadvantage being measured instead of relying on unexplained positive and negative labels. Where a decision has several relevant outcomes, use an assessment that reflects that complexity rather than forcing every concern into one binary field.
People also ask
Is the positive class always favorable?
No. The positive class can represent an undesirable event, such as a delay. The favorable outcome must be defined from the analysis context.
Does favorable mean the prediction is correct?
No. Favorability describes the outcome's intended meaning; correctness compares a prediction with a reference outcome.
Can a dataset use zero as the favorable value?
Yes, if zero encodes the designated favorable outcome and the tool is configured accordingly. Numeric order does not determine desirability.
Check your understanding
A dataset uses 1 for a delayed request and 0 for an on-time request. Which value should represent favorable completion in an on-time-service analysis?
Answer: Zero, provided on-time completion is the documented favorable outcome. The metric configuration must follow the meaning of the labels rather than the default numerical convention.
Related terms
- Label
- Positive class
- Negative class
- Fairness metric
- Group fairness
- Outcome
- selection rate
- reference label
- predicted label
- data dictionary
Learn next
Learn positive and negative classes next, separating numerical encoding, outcome meaning, and prediction correctness. Then calculate a selection-rate comparison after deliberately reversing the encoding to see why the favorable-label configuration must change with it.
More in Governance, ethics and safety
- Facial recognition - Facial recognition is the automated comparison of facial information to help verify or identify a person.
- Fairness constraint
- Fault tolerance - Fault tolerance is a system's ability to continue providing an acceptable service when one or more components fail.
- Feedback Loop Bias - Feedback Loop Bias occurs when a system's outputs influence the behavior or observations that later become its learning data, reinforcing a distorted pattern.
- Fraud detection - Fraud detection is the process of identifying activity that may involve deception for an improper benefit, such as unauthorized transactions or false claims.
- Funding Bias - Funding Bias is a distortion in research or evaluation that favors the interests or expectations of the organization or person providing financial support.
Sources
AIF360 primary documentation, BinaryLabelDataset: https://aif360.readthedocs.io/en/stable/modules/generated/aif360.datasets.BinaryLabelDataset.html
Fairlearn primary documentation, common fairness metrics: https://fairlearn.org/main/user_guide/assessment/common_fairness_metrics.html
Primary tool documentation was read for explicit favorable-value configuration and outcome-rate interpretation. NIST's supplied glossary landing page was accessible, but its linked spreadsheet did not expose definition text in the browser. The on-time example and Brooklane Services case are original illustrations.
Previous: Fault tolerance Next: FCO-IM