Case-Intake Script¶
Assessment protocol — instantiates Event-Script Structuring
A structured front-door protocol that classifies an incoming case into the right situation class, confirms its activating cues, and assigns the roles before the encounter proper begins.
A Case-Intake Script is the disciplined front door: it takes an arriving, still-ambiguous case and decides which script this situation belongs to before anyone starts running one. Its defining question is not "is the script still holding?" but "is this even the situation we think it is, and who is playing which part?" It works by matching the presenting facts against the boundaries of known situation classes, checking that the activating cues are genuinely present (and not merely superficially similar), and slotting the people involved into defined roles. It is entirely a step that happens at the threshold — its whole job is to route the case correctly so the right script, and only the right script, gets picked up.
Example¶
A walk-in legal-aid clinic sees a stream of people whose problems arrive as tangled stories, not tidy categories. The intake script is what a paralegal runs first. A visitor describes a landlord who changed the locks. The script tests the class boundary: is this an unlawful eviction matter (locks changed while tenancy is live), a lease-termination matter, or a code-enforcement matter? It confirms the activating cues that separate them — was written notice served, is rent current, did the tenant still have possessions inside — rather than routing on the word "landlord" alone. Then it assigns roles: this person is the tenant-of-record, the absent party is the landlord, and a named housing attorney is the responsible advisor. The output is a routed, role-tagged case: "emergency unlawful-lockout, tenant-of-record, escalate to housing duty attorney today." Because the routing was deliberate, the case reaches the right script instead of being force-fit into whichever category the front-desk volunteer happened to know best.
How it works¶
Intake runs in a fixed order that mirrors the archetype's opening moves. First it establishes the situation-class boundary: a short discriminating test that says what the case is and, just as importantly, what neighboring class it is not. Then it verifies the activation cues — including the cues that are necessary but not sufficient, so that a superficial resemblance ("sounds like fraud") is not mistaken for a real match. Finally it fills the role slots, recording who occupies each defined part, what they are permitted to do, and which roles are still unfilled. The product is a classified, role-populated case handed off to whatever downstream script the class calls for; intake itself never runs that script.
Tuning parameters¶
- Class granularity — how finely the intake tree splits. Fine categories route precisely but slow the door and strand ambiguous cases; coarse categories are fast but under-route.
- Cue strictness — how much confirming evidence a cue needs before the class is accepted. Strict cues resist misclassification but reject genuine cases that present atypically.
- Role-completeness gate — whether a case may proceed with roles unassigned. A hard gate prevents orphaned responsibilities; a soft gate keeps the queue moving.
- Fallback path — where a case goes when it fits no class cleanly. A wide "other / needs human" lane protects against forced fits at the cost of a growing unrouted pile.
When it helps, and when it misleads¶
Its strength is catching misclassification before effort is committed — the point of maximum leverage, since every later step inherits the class chosen here. A good intake script is the direct guard against the representativeness heuristic, the tendency to sort a case by how much it superficially resembles a familiar type while ignoring the discriminating facts.[n1]
Its failure mode is the mirror image of its purpose: a rigid intake tree manufactures the very misclassification it was built to prevent, funneling odd cases into the nearest familiar box because the tree has no branch for "none of these." It also drifts, as front-line users learn which category yields the fastest handoff and steer cases there. The discipline is a real fallback lane for cases that fit nothing cleanly, and periodic review of what landed in "other" — those are where new situation classes are hiding.
How it implements the components¶
situation_class_boundary— the discriminating test at intake is exactly the boundary between one situation class and its neighbors.activation_cue_set— it verifies the entry cues that justify claiming a class, refusing surface-level matches.role_slot_map— it assigns arriving parties to the script's defined role slots and records which remain open.
It does not watch a running encounter for departures — the breach_detector is the work of Breach Checklist — and it does not challenge whether the chosen class is itself a stereotype; that counter_script_library guard belongs to Counter-Script Review. Intake classifies at the threshold; those siblings act during and against the encounter.
Related¶
- Instantiates: Event-Script Structuring — supplies the recognition-and-routing front door for the pattern.
- Consumes: Script-Card Template — the class definitions and role slots it matches incoming cases against.
- Sibling mechanisms: Breach Checklist · Counter-Script Review · Expectation-Violation Review · Interface-Flow Script · Role-Play Rehearsal · Scenario Walkthrough · Script-Card Template · Script-Revision Workshop · Service-Blueprint Script
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: A structured front-door protocol that classifies an incoming case into the right situation class, confirms its activating cues, and assigns the roles before the encounter proper begins, making its operative form a case-specific gate, selection, routing, prioritization, or disposition decision.
Independent corroboration: The frozen evidence defines Case-Intake Script as 'A structured front-door protocol that classifies an incoming case into the right situation class, confirms its activating cues, and assigns the roles before the encounter proper begins', so its operative form is Decision, Gate & Allocation.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Medicine & Healthcare
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Clinical and social-service intake developed structured front-door questioning that classifies a case, detects activating cues, and routes it to the right service.
Related originating lineages:
- Psychology — Diagnostic interviewing and representativeness-bias research shape cue checks that resist prototype-only classification.
- Public Administration & Policy — Administrative casework supplies eligibility, role assignment, and standardized routing across service tracks.
Review resolution: Clinical intake supplies the recognizable structured elicitation sequence, while public-administration casework and psychological interviewing contribute triage, eligibility, risk, and sensitive disclosure practices. The generalized script is therefore a cross-disciplinary synthesis with multi-domain reach.
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¶
[n1] The representativeness heuristic — described by Amos Tversky and Daniel Kahneman — is the tendency to judge how likely something belongs to a category by how closely it resembles a prototype of that category, often at the expense of more diagnostic information such as base rates. ↩