Receiver Feedback Disposition Code¶
Feedback taxonomy — instantiates Signal Habituation Control
Gives receivers a small coded vocabulary — false positive, wrong recipient, no action needed, acted — to label each firing, turning lived experience into feedback the channel can learn from.
A Receiver Feedback Disposition Code is a small, fixed vocabulary a receiver applies to each firing at the moment they finish handling it — confirmed true, false positive, wrong recipient, no action needed, duplicate, acted and resolved. It is the atomic feedback input to the whole channel: each code is one receiver's coded judgment about one firing, captured at the point of use, giving the receiver a bounded and auditable voice while producing the labeled data every downstream metric and review depends on. Its defining boundary is that it captures structured feedback and nothing more — it does not aggregate the codes, plot them, or decide what to do about them.
Example¶
A bank's transaction-monitoring team works a queue of flagged payments. Today, analysts close each alert as "reviewed" with no reason recorded, so nobody can tell whether the detection rules are precise or the analysts are simply rubber-stamping to clear the backlog. The team adds a required disposition code at close: confirmed fraud, false positive, benign true positive (real but legitimate activity), insufficient information, wrong queue. Now every closed alert carries a labeled outcome. Over a month, the codes reveal that one rule generates about 3,000 alerts at roughly 1% confirmed fraud — a false-positive geyser — while another, quieter rule catches most of the actual losses. The codes themselves change nothing about which alerts fire; they convert analyst experience into ground-truth labels that the recalibration review and the dashboard can finally use. The taxonomy mirrors the disposition practice long used in security operations, where each alert is closed as a true positive, a false positive, or a benign positive.[n1]
How it works¶
- A small vocabulary. A handful of mutually distinct, decision-relevant codes — few enough to apply in seconds, distinct enough that the choice carries information.
- Mandatory at disposition. The code is required to close a firing, so feedback is captured at the moment of freshest knowledge rather than reconstructed later.
- Attributed and timestamped. Each code records who dispositioned what and when, so patterns can be traced to rules, roles, and shifts.
- Optional free text. A short note field captures the case the fixed codes miss, without forcing every disposition through prose.
Tuning parameters¶
- Code-set size — how many codes exist. More codes capture finer distinctions but slow disposition and blur the boundaries between them; fewer are fast but coarse.
- Mandatory vs optional — whether a code is required to close a firing. Mandatory coding guarantees coverage but invites reflexive clicking; optional coding yields cleaner labels from fewer firings.
- Free-text allowance — how much unstructured note is permitted alongside the code. Rich notes preserve nuance but resist aggregation.
- Retro-coding window — whether and how long a disposition can be revised after the fact as new information arrives.
When it helps, and when it misleads¶
Its strength is twofold: it creates the ground-truth labels without which no diagnostic profile or recalibration is trustworthy, and it gives receivers a legitimate voice — a coded way to say "wrong recipient" or "no action needed" instead of silently ignoring — which directly attacks the failure mode of blaming receivers for inattention the channel itself trained.
Its failure mode is label corruption: if the codes are coarse, ambiguous, or misused, the labels become garbage, and everyone selecting "false positive" to clear the queue fast poisons the very data the channel relies on. The classic misuse is turning disposition rate into a productivity KPI, which reliably corrupts the labels — analysts optimize for closing speed, not accuracy. The guarding discipline is to keep the code set few and decision-relevant, spot-check label quality against known cases, and never let a coding scheme double as a performance metric.
How it implements the components¶
action_outcome_feedback_loop— each code is the atomic outcome datum that closes the loop between a firing and what the receiver actually did about it; the loop is built from these labels.receiver_control_and_exception_path— the code set is the receiver's bounded, auditable channel to push back — "wrong recipient," "no action needed" — without resorting to silent disregard.
It does not aggregate the codes into exposure or diagnostic trends (exposure_volume_baseline, diagnostic_value_profile) — that's the Alert Fatigue Dashboard, its nearest consumer, which turns many atomic dispositions into a channel-health picture this mechanism only supplies the raw labels for.
Related¶
- Instantiates: Signal Habituation Control — the disposition code supplies the ground-truth feedback the pattern's whole governance loop is built on.
- Sibling mechanisms: Alert Fatigue Dashboard · Signal/Noise Review Board · Alert Threshold Recalibration Review · Actionable Alert Template · Tiered Notification Ladder · Alert Deduplication and Grouping Rule · Cooldown or Refractory Window · Channel Retirement and Relaunch Protocol · Watch Rotation and Delegation Lane
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Receiver Feedback Disposition Code operates by captures an attributable decision-relevant code when each disposition closes and preserves it for aggregation. That concrete deployed or enacted form is Record, Log & Register under the frozen taxonomy.
Nearest alternative: Interface, Display & Cue — Although Interface, Display & Cue can support this mechanism, the frozen evidence makes its operative form the act that captures an attributable decision-relevant code when each disposition closes and preserves it for aggregation; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Lightweight user feedback categories for alert systems are an interaction-design mechanism.
Related originating lineages:
- Aviation & Aeronautics — Human-factors and incident-reporting practice shaped operational dispositions for alerts.
Review resolution: Both blind reviewers agree that human_computer_interaction is the primary origin. Explicit reconciliation of alternate origin disagreement adopts reviewer_a's classification because lightweight user feedback categories for alert systems are an interaction-design mechanism. The resulting lineage records alternates=aviation_aeronautics, origin_mode=cross_disciplinary_synthesis, and domain_reach=multi_domain; these describe formative provenance separately from later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
The disposition code is the source of the governance loop, not its consumer: it feeds the Alert Fatigue Dashboard and the Signal/Noise Review Board, which aggregate and act. Its value is entirely downstream, which is why label quality — not label quantity — is the thing worth protecting.
[n1] In security operations, analysts close each alert with a disposition — commonly true positive, false positive, or benign positive — that records what the alert actually turned out to be. These dispositions are the ground truth used to measure detection precision and to tune the rules; the same practice generalizes to any attention-recruiting channel. ↩