Automated Pre-Screen with Manual Review¶
Workflow — instantiates Fast/Slow Path Routing
A workflow that uses cheap automated checks before routing flagged cases to human or specialist review.
Automated Pre-Screen with Manual Review is a runtime pipeline: a battery of cheap, deterministic checks runs on every incoming case, clears the clean majority automatically, and forwards only the residue that trips a flag — with the machine's findings attached — to a human or specialist reviewer. Its defining move is the screen-everything-then-escalate-the-exceptions sequence: the automation is a filter that acts on the whole stream and hands its misgivings to a person, so scarce expert attention is spent only where a machine has already found something worth a second look. It does not design the two lanes ahead of time and it does not attach a probability to each case; it runs the checks and routes the flags.
Example¶
A journal receives thousands of manuscript submissions a year, far more than its editors can read in full. An automated pre-screen runs on each new submission the moment it lands: a similarity check against published literature, a reference-format validator, a scope-and-keyword match against the journal's aims, an image-duplication scan on the figures, and a statistical-reporting completeness checklist. Submissions that pass every check drop straight into the normal editorial queue untouched. A submission that trips a flag — say, 40% text overlap with a prior paper plus a duplicated gel band — is forwarded to a handling editor with the flagged report attached, so the editor opens the case already knowing what looks wrong and can decide quickly among desk-reject, request-revision, or send-to-full-review. The screen never accepts or rejects on its own; it decides only who reaches a human and with what evidence in hand.
How it works¶
- Run cheap checks on 100% of cases. The checks are fast and rule-based, so screening the whole stream costs little; the point is to make the flagged set small, not to judge.
- Flag, don't decide. A trip threshold on the checks routes a case to review; passing the screen means "no flag," not "approved."
- Carry the findings across the handoff. The reviewer receives the case and the machine's specific findings, starting from evidence rather than a blank slate.
- Feed dispositions back. Reviewer outcomes (flag confirmed / false alarm) are logged so the checks can be re-tuned.
Tuning parameters¶
- Flag sensitivity — how eagerly the checks forward a case. High sensitivity catches more real problems but floods reviewers with false alarms; low sensitivity keeps the review queue small but lets flawed cases through untouched.
- Check breadth — how many distinct checks run. More checks catch more failure types but slow the screen and multiply false flags.
- Reviewer routing — whether all flags go to one queue or a fraud flag goes to fraud, a stats flag goes to a statistician. Specialization sharpens review but adds routing overhead.
- Auto-clear authority — whether passing the screen merely enters the normal queue or grants an actual approval. Granting approval is faster but turns every screen miss into an unreviewed outcome.
When it helps, and when it misleads¶
Its strength is triage economics: the machine reads everything cheaply so humans read only the small flagged set, and each reviewed case arrives pre-annotated. This is the classic way to make expert judgment affordable at volume.
Its central failure mode is automation bias — reviewers come to over-trust the screen, rubber-stamping the flags it raises and never questioning the far larger set it cleared, so a category the checks were blind to becomes a category the whole pipeline is blind to.[n1] The classic misuse is treating "passed the pre-screen" as "approved," which quietly converts a filter into an unaudited decision-maker. The guarding discipline is to sample cleared cases as an informal self-check, to keep reviewers able to open the raw case rather than only the machine's summary, and to re-tune the checks against confirmed misses rather than against how many flags annoyed the review team.
How it implements the components¶
Automated Pre-Screen with Manual Review fills the detect-and-escalate side of the architecture:
exception_or_ambiguity_detector— the automated checks are the detector; each check is a rule that notices when a case stops resembling the clean common case.slow_path_lane— the human or specialist review the flagged residue is routed to is the deliberately more capable slow lane.escalation_handoff_protocol— the forwarded case carries the machine's findings, so the reviewer starts from evidence rather than from scratch.
It does not define the common_case_definition or build the fast_path_lane the cleared cases flow into — that design is Happy-Path / Exception Workflow, which lays out the two named routes up front while this workflow is the runtime engine that detects flags and hands them off.
Related¶
- Instantiates: Fast/Slow Path Routing — this is the runtime pipeline that screens the stream and escalates the exceptions.
- Consumes: Triage Rule Table supplies the criteria the automated checks flag against.
- Sibling mechanisms: Happy-Path / Exception Workflow · Confidence Threshold Router · Cache with Authoritative Fallback · Deoptimization or Fallback Handler · Fast-Track Lane with Audit · Exception Queue Dashboard · Triage Rule Table · Escalation Playbook — the playbook (from a neighbouring archetype) pre-scripts the human notify/decide/act response after a case is escalated, where this workflow is what does the escalating.
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: The mechanism runs cheap checks over every case, routes only flags with their findings to human review, and feeds reviewer dispositions back into screening, so its operative form is a staged human-machine workflow.
Nearest alternative: Control, Automation & Runtime — Automation performs the first routing gate, but the defining mechanism is the reusable pre-screen-to-manual-review handoff rather than the automated stage alone.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Automated decision systems commonly screen the full stream and route flagged exceptions to human reviewers.
Related originating lineages:
- Medicine & Healthcare — Clinical screening established high-throughput initial tests followed by confirmatory expert review.
- Organizational & Management Science — Operations management designs fast and specialist lanes around scarce human attention.
Review resolution: Computer science is the agreed primary lineage. Organizational exception workflows and medical screening traditions independently contribute the two-stage structure, which is established human-in-the-loop automation rather than an Encyclopedia synthesis.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Automation bias — the documented tendency of human operators to over-rely on automated aids, deferring to a system's judgment and under-scrutinizing the cases it has cleared. It is the reason a pre-screen's real risk sits in its silent pass, not its noisy flag, and why cleared cases must still be sampled. ↩