Fairness definitions, slices, thresholds, tradeoffs
Fairness work makes the chosen harm, comparison, uncertainty, and policy tradeoff explicit for every affected slice.
A high-performing system creates subgroup harm and leaks sensitive information.
This chapter moves from name the harm and comparison to choose a documented tradeoff. We will make the idea concrete in a small code example before placing it back inside a production system with risk-tiered human oversight.
Test data, objective, threshold, review, and recourse mitigations, then record remaining disparities and monitor them after release.
Verify the behavior illustrated in slice_rates.py, then measure decision utility, slice reliability, and system latency.
The team reports one aggregate fairness number, deletes the protected field, loads an untrusted pickle, and logs sensitive inputs forever. An unsafe release must degrade to a named baseline or the last known-good version.
Build the idea one layer at a time.
Fairness is not one metric that certifies a model. It is a structured question about who is affected, which harm matters, what comparison is appropriate, and how data, scores, thresholds, and human processes distribute that harm.
Demographic parity compares positive-decision rates; equal opportunity compares true-positive rates; equalized odds also considers false-positive rates; calibration asks whether equal scores carry equal empirical meaning. These criteria can conflict when base rates differ, so the team must justify the criterion from the decision and harm rather than optimize every number blindly.
Aggregate metrics hide intersections. Evaluate sample size and uncertainty across relevant combinations of groups, regions, channels, and time. Threshold changes move false positives and false negatives differently, and group-specific policies can introduce legal, operational, or legitimacy concerns. Measurement should lead to mitigation, human review, monitoring, and recourse—not a dashboard-only exercise.
- equalized odds
- intersectional slices
- privacy threat modeling
- differential privacy
Follow the reasoning before touching the code.
- 01
Name the harm and comparison
Describe the decision, affected groups, benefit or burden, legitimate conditioning variables, and fairness criterion that matches the context.
- 02
Measure scores and policy
Report base rates, score distributions, calibration, confusion rates, thresholds, coverage, and uncertainty for aggregate and intersectional slices.
- 03
Choose a documented tradeoff
Test data, objective, threshold, review, and recourse mitigations, then record remaining disparities and monitor them after release.
def rates(rows, group, threshold=0.5):
selected = [r for r in rows if r['group'] == group]
tp = sum(r['score'] >= threshold and r['label'] == 1 for r in selected)
fp = sum(r['score'] >= threshold and r['label'] == 0 for r in selected)
positives = sum(r['label'] == 1 for r in selected)
negatives = sum(r['label'] == 0 for r in selected)
return {'tpr': tp / positives, 'fpr': fp / negatives}
# Supply rows from one fixed, mature evaluation window.
print(rates(rows, group='A'))Compute decision-relevant rates for each group
What to notice
- The same threshold can produce different true- and false-positive rates because score and label distributions differ by group.
- Rates without counts or intervals can look precise on tiny slices; always report support and uncertainty.
YOUR TURN Pause and predict before revealing the answer.
Two groups have equal accuracy but one has a much higher false-negative rate. Is the system fair?
Need a hint?
Accuracy combines different errors and does not define the relevant harm.
Check your reasoning
The equality of accuracy is insufficient. Determine whether missed positives are the relevant harm, inspect base rates and uncertainty, justify the comparison, and evaluate mitigation and recourse in context.
Lessons 1 in this course.
Connect the chapter to the course’s quantitative spine.
Fairness work makes the chosen harm, comparison, uncertainty, and policy tradeoff explicit for every affected slice. The differential privacy guarantee below is the shared course-level lens that helps quantify the surrounding system. Name each symbol, check its units or shape, and use only values that were available at the production cutoff.
Differential privacy guarantee
| Symbol | Meaning / shape / unit |
|---|---|
M | randomized mechanism |
D, D′ | adjacent datasets |
ε, δ | privacy-loss parameters |
Open derivation and numerical substitution
Start from the production quantity being optimized, substitute the observed values with their declared units, then isolate the model-controlled term. Preserve shape annotations at each step so broadcasting or aggregation cannot silently change the result.
- Write the named inputs: M, D, D′, ε, δ.
- Substitute one small, hand-checkable batch before vectorizing.
- Calculate an independent reference value and compare within a declared tolerance.
# equation → code contract
inputs = validate_shapes_and_units(batch)
value = compute_c20(inputs)
assert is_finite(value)Change one assumption and make the tradeoff visible.
Use the worked chapter as your prediction, then change one input in the lab and explain why the output moves. The lab runs predefined TypeScript and never executes learner code, so the focus stays on the concept rather than setup.
Threshold parity lab
Move one group threshold and inspect error-rate and utility tradeoffs.
Assumption: Fixed score/label table with different group base rates; group A threshold is 0.5.
Open nonvisual data table
| Item | Computed state | Interpretation |
|---|---|---|
| A | 0.50 | TPR 1.00 / FPR 0.33 |
| B | 0.50 | TPR 0.50 / FPR 0.33 |
Trace the complete operating path.
Carry the chapter’s central idea into the system: Fairness work makes the chosen harm, comparison, uncertainty, and policy tradeoff explicit for every affected slice. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.
- 01
Turn “Name the harm and comparison” into a written invariant and a failing test.
- 02
Promote slice_rates.py from illustration to a versioned implementation with representative fixtures.
- 03
Use “Choose a documented tradeoff” as the release checkpoint: Test data, objective, threshold, review, and recourse mitigations, then record remaining disparities and monitor them after release.
- 04
Serve or materialize behind explicit risk-tiered human oversight.
- 05
Join telemetry to mature outcomes and retain a rollback path.
Observability
Join service health, input quality, prediction distributions, slice behavior, and mature outcomes by exact version.
Cost
Measure storage, preprocessing, compute, queueing, and human review under a representative arrival pattern.
Failure modes
The team reports one aggregate fairness number, deletes the protected field, loads an untrusted pickle, and logs sensitive inputs forever. Add a detector, owner, mitigation, and stop condition for this class of failure.
Alternatives
Compare a rule, a simpler statistical baseline, and a different system boundary before adding model complexity.
Explain the contract, not just the vocabulary.
Model assurance package
Produce intended-use, fairness, privacy, security, human-review, monitored-rollout, and release evidence.
- Model/data cards
- Intersectional analysis
- Privacy/retention plan
- Threat model and recourse
Read primary material with a purpose.
Return to the opening failure.
Governance evidence must travel with the exact model, data, policy, and runtime release throughout its lifetime.
For this lesson, the release evidence is the worked code example, a hand-checked formal result, deterministic simulation output, a ≥80% checkpoint, the production rubric, and a named fallback. The course resolves when the system can produce a launch review covering fairness, privacy, licensing, abuse, security, and response.