What belongs in a case file
The game asks you to judge customers using their answers, identification, computer records, and behavior. A useful database must preserve that separation. Each future named file will include:
| Field | What it records |
|---|---|
| File number | A stable wiki identifier, not an in-game claim |
| Appearance stage | The Night or progression range actually observed |
| Observed signs | Visible or audible behavior captured in play |
| ID checks | The exact field compared with the terminal |
| Miss consequence | What happened after the customer was released |
| Countermeasure | A response reproduced in the current build |
Why the named list is deliberately small
Randomized shifts make screenshots and one-off anecdotes easy to misread. A face appearing in a failed run does not automatically prove one permanent tell. This database will not convert community guesses into definitive labels.
To add a named case, the observation should be repeatable, tied to a build/date, and separated from the player’s conclusion. If a patch changes the behavior, the record is revised rather than silently left as timeless advice.
Entity Warning: Never use a generic “looks suspicious” list as a substitute for the in-game ID, terminal, questions, and behavior checks.
Counter protocol
Until individual case records clear review, use the complete identification protocol: read the presented document, ask the available questions, compare the computer record field by field, observe behavior, and state the evidence before acting.
The absence of a customer from this database does not mean they are safe. The terminal in your current shift remains the source of truth.