What is a quiz-result override?
A quiz-result override changes the operational outcome for one completion after released quiz logic has produced its result. It can correct bad source data, resolve a declared exception, or incorporate relevant evidence the quiz was not designed to capture. It is not a silent score edit, a general rule change, or a substitute for fixing a repeatable defect.
If the same exception appears repeatedly, analyze and test a new rule version. A case-specific override should remain rare enough that its reasons can be reviewed individually.
Related: Decide when manual review is warranted · Change a general scoring rule safely
Allow only declared reasons
Each reason should name the evidence required and the role allowed to approve it. Free-text notes can explain context but should not replace a stable reason code.
| Reason | Appropriate use | Inappropriate use |
|---|---|---|
| Source correction | A participant or verified source corrects a material input | Changing an answer to reach a preferred result |
| Missing context | Relevant evidence was outside the quiz's declared scope | Adding undocumented intuition |
| Policy exception | A named policy permits a case-specific exception | Bypassing a rule because the outcome is inconvenient |
| System defect | The released implementation did not apply the approved rule | Hiding a broader defect instead of fixing it |
| Appeal or recourse | A participant supplies relevant information for review | Promising recourse no reviewer can grant |
Preserve both decisions
Store the original and replacement as linked, immutable records. Do not overwrite the original score field and rely on an unstructured note; that makes reports irreproducible and hides the difference between automated behavior and human exceptions.
- Completion, participant, quiz, and rule-version identifiers
- Original input snapshot, score components, result, route, and timestamp
- Request time, requester, reason code, and evidence reference
- Reviewer identity, authority, decision, and timestamp
- Replacement result, qualification state, and route
- Downstream actions, notification state, and delivery keys
- A correction or reversal link if the override later changes
Sources: NIST SP 800-128, Guide for Security-Focused Configuration Management · NIST SP 800-92, Guide to Computer Security Log Management
Use a seven-step override method
1. Verify identity and case scope: confirm the exact completion and decision under review. 2. Freeze the original record: capture inputs, rule version, score, result, route, and actions. 3. Classify the reason: select one declared reason and evidence set. 4. Check authority and conflict: assign a reviewer who can change the decision. 5. Record the replacement: create a linked decision with a new timestamp. 6. Propagate once: update CRM, queue, email, and reporting with idempotency keys. 7. Close and monitor: notify appropriately and review patterns for repeatable defects.
NIST configuration-management guidance addresses system baselines rather than marketing quizzes, but its emphasis on documented requests, impact analysis, approval, implementation evidence, and retained prior baselines is a useful transferable control model.
Related: Compare two rule versions
Sources: NIST SP 800-128, Guide for Security-Focused Configuration Management
Keep reporting honest
Report the original automated result, current operational result, and override reason separately. A metric labeled qualified leads needs a declared rule for whether it counts automated qualification, current qualification, or both as separate dimensions.
Google Analytics recommends lifecycle events including generate_lead, qualify_lead, and disqualify_lead. If an override creates a real operational transition, emit the corresponding event once and retain the authoritative prior and replacement decisions in the operational record. Do not delete or rename the earlier event to make a funnel report match the current state.
Sources: Google Analytics, Recommended events
Provide meaningful recourse where promised
If the experience offers review or appeal, the reviewer must be able to consider relevant evidence and change the decision. ICO guidance for significant automated decisions says human intervention should be meaningful and performed by someone with appropriate authority and capability. A typical marketing quiz may not be a significant automated decision, but the standard exposes a useful design check: do not call a workflow human review if it can only confirm the original output.
Collect only the evidence needed for the declared correction. An override log should not become a second profile containing speculative or unrelated personal details.
Sources: ICO, individual rights and meaningful human intervention · ICO, automated decision-making and profiling rights · ICO, Data minimisation principle
Worked example: corrected company size
A synthetic lead selects 1–10 employees, receives a self-service result, and is routed to nurture. The participant reports that they selected the wrong option and supplies the corrected band 51–200 employees through the declared correction path.
An authorized reviewer verifies the case, records source_correction, links the evidence, and creates a replacement sales_review decision. The original answer, score, result, and nurture route remain in history. The CRM changes the current route once, the nurture sequence is suppressed before the next send, and one review notification is issued. The example does not claim that company size should determine qualification or that these bands fit another business.
Override release checklist
Release only when the original and replacement decisions, authority, participant path, and downstream systems remain reconstructable.
- The policy distinguishes an override from a rule change and defect fix
- Reason codes, evidence requirements, and approving roles are declared
- Original inputs, rule version, result, route, and actions are immutable
- The replacement decision has its own identifier and timestamp
- A reviewer can reject as well as approve the request
- CRM, email, routing, analytics, and reporting update exactly once
- Participant notification and correction paths are defined
- Personal data is limited to what the review needs
- Override rates and recurring reasons are monitored by rule version
- Repeated exceptions trigger rule review rather than normalized workarounds
Related: Test the manual-review workflow · Review qualification boundaries
Evidence
How to reproduce the method
A reproducible reason taxonomy, immutable before-and-after record, seven-step control method, synthetic corrected-company-size example, and ten-point release checklist verified against the cited primary guidance on October 23, 2026.
Limitation
Where this conclusion stops
This method governs deterministic case-specific corrections. It does not establish that a quiz result is objectively true, prove human decisions are unbiased, choose a legal basis, or validate machine-learning models. Regulated or similarly significant decisions require specialist review. Product audit and permission capabilities vary and should be verified directly.
Sources and verification
What this guide relies on
- ICO, individual rights and meaningful human intervention
- NIST AI RMF Playbook, measure human oversight
- NIST SP 800-128, Guide for Security-Focused Configuration Management
- Google Analytics, Recommended events
- ICO, Data minimisation principle
- ICO, automated decision-making and profiling rights
Sources and method checked October 23, 2026. External standards are linked to their primary publishers. Request a factual correction.