Equal-Treatment Checklist¶
Checklist — instantiates Symmetry-Based Fairness
A fixed set of questions a reviewer works through on every case — what treatment must stay invariant, what difference would justify departing, and what to record — so the same discipline lands on each decision as it is made.
Equal-Treatment Checklist is a prospective, per-case job aid: a short, fixed list of questions the reviewer answers on every single decision, in the moment they make it. It names the treatment that must stay the same across equivalent cases, asks whether any difference in front of the reviewer is strong enough to justify departing, and — if the reviewer departs — forces the reason onto the record before the case can close. Its defining move is that it operates decision by decision at the point of judgment, standardizing the individual act rather than measuring a population of acts after the fact or testing the rule in the abstract. It is the discipline that keeps a well-meaning reviewer from unconsciously asking more of one claimant than another.
Example¶
A property-insurance adjuster works a queue of storm-damage claims. Left to habit, an adjuster tends to demand more documentation from unfamiliar claimants and wave through familiar ones — the kind of drift no one intends. An Equal-Treatment Checklist sits on every claim and forces the same four questions: What makes claims equivalent here? (same peril, same coverage tier). What must be invariant across them? (the payout formula and the evidence bar). Is there a relevant difference justifying different handling? (a genuine fraud indicator, a policy exclusion — not "I don't recognize this name"). If I'm departing, what's the recorded reason? An adjuster about to fast-track a familiar claimant hits the second question and has to apply the same evidence bar; one about to demand extra proof from an unfamiliar one hits the third and finds no relevant difference to justify it. The checklist does not decide the claim; it makes the reviewer's own standard consistent and self-documenting.
How it works¶
The checklist is an ordered set of prompts with a forcing function: the case cannot be closed until each is answered, and the departure prompt cannot be satisfied without a recorded rationale. The sequence matters — equivalence and invariant treatment come first, so the reviewer establishes the baseline before considering any difference, rather than reverse-engineering a difference to justify a decision already felt. It is self-applied and lightweight, which is what lets it ride on every decision at scale rather than on a sampled few.
Tuning parameters¶
- Prompt granularity — a handful of high-level questions versus a detailed field-by-field form. Finer prompts catch more but slow every case and invite rote completion.
- Forcing strictness — whether answers are mandatory blocking fields or advisory nudges. Hard blocks guarantee the discipline but breed resentment and gaming; soft nudges are ignored under load.
- Departure threshold — how strong a difference must be before the exception-record step triggers. A low threshold documents everything (and buries signal); a high one lets small departures slip unrecorded.
- Rationale review — whether recorded departures are ever read, and by whom. Unread rationales decay into boilerplate.
When it helps, and when it misleads¶
Its strength is that it is cheap, scales to every decision, cuts in-the-moment inconsistency, and leaves each case self-documenting — the reviewer's reasoning is captured as they go, not reconstructed later.
Its failure mode is ritualization: a checklist can decay into box-ticking, where the reviewer clicks through the prompts without engaging and the exception rationale becomes a copy-pasted phrase. It also cannot catch bias that hides inside the answers — a reviewer who sincerely believes an irrelevant difference is relevant will document it confidently. The classic misuse is treating a completed checklist as proof that a decision was fair, when it only proves the questions were displayed. The guarding discipline is to keep the list short enough to be taken seriously, and to periodically read the recorded rationales for quality — an aggregate review that hands off to a Consistency Audit rather than living on the checklist itself. The forcing-function logic it borrows is the same one that made surgical and aviation checklists effective: guarantee the essential steps happen every time.[1]
How it implements the components¶
Equal-Treatment Checklist realizes the point-of-decision face of the archetype — the components that shape a single judgment as it is made:
equal_treatment_rule— it states, on every case, exactly what treatment must remain invariant across equivalent cases, so the baseline is explicit before any difference is weighed.relevant_difference_test— a prompt requires the reviewer to name a genuine relevant difference before departing, blocking casual asymmetry.exception_rationale— the departure prompt forces the reason to be recorded on the case, turning each exception into a reviewable entry.
It does not aggregate many decisions to detect variation (case_set_scope, audit_trail) — that is [Consistency Audit], which reads outcomes across a population where the checklist shapes one case at a time; nor does it line a case up against decided precedents (precedent_reference) — that is [Precedent Analysis].
Related¶
- Instantiates: Symmetry-Based Fairness — the checklist is how the equal-treatment invariant is enforced at the moment of each individual decision.
- Sibling mechanisms: Policy Symmetry Test · Consistency Audit · Anti-Discrimination Check · Precedent Analysis · Classification Fairness Review · Exception Register
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: For every case, the checklist verifies the invariant baseline, any relevant difference, and the recorded rationale before the reviewer may close the case.
Nearest alternative: Decision, Gate & Allocation — The verification accompanies a decision, but its operative output is assurance that any departure from equal treatment is evidence-backed and documented.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Equality and rule-of-law doctrine supplies the requirement that equivalent cases receive invariant treatment unless a relevant difference is recorded.
Related originating lineages:
- Public Administration & Policy — Administrative casework supplies standardized per-decision checklists and stated-reason records.
Review resolution: The current reviewers agree that law_governance is primary. For the reported differences (reported_ambiguity, alternate_origin_disagreement, origin_mode_disagreement, encyclopedia_synthesis_disagreement), the evidence supports cross_disciplinary_synthesis, multi_domain, and public_administration_policy; these choices preserve materially formative origins without conflating later domain reach.
Attribution caveat: The checklist is an operational synthesis of a legal equality principle.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Atul Gawande's The Checklist Manifesto (2009) argues that simple, fixed checklists cut error in complex, high-stakes work by guaranteeing the same essential steps are taken every time — the same forcing-function logic an equal-treatment checklist applies to the steps of a fair decision. registry ↩