One key, and a line-up.

A check needs two endpoints: the one you doubt and one you trust. Unmask needs only the first, because the second is replaced by a record.

§1The files

For every model on the atlas we keep its answers to the eight questions: which answers, how often. That record is the model's file.

§2The line-up

Your endpoint is asked the eight questions, like in a check.
Its answers are measured against every file, which gives a distance to each model.
The eight nearest are then put through the full test: the same reshuffling a check uses, with the file standing in for the trusted endpoint.

§3The four outcomes

Matches its claim: You named a model, and the endpoint's tells agree with that model's file.
Not what it claims: You named a model, and the tells do not agree with its file. The line-up shows who it does resemble.
Looks like …: You named nothing. This is the nearest model whose file it cannot be told apart from.
No match on file: It does not answer like any model we have recorded.

§4Why more than one name can match

Close relatives share tells. Two sizes of one model family, or one model on two hosts, can both pass the test against the same batch of answers. Unmask lists every name it cannot rule out instead of picking one and hoping.

§5Where it stops

A file is a moment. It was recorded on the dates shown in the atlas. A model that has changed since will stop matching its own file, which is exactly what the drift log watches for.
Only what is on file can be named. A model we never recorded shows up as no match, or as its nearest relative.
A record is weaker than a live reference. When it matters, run a check against the maker's own API.

→Keep reading

Next: What spec check tests · seven promises of the chat format, one small request each
Before this: How the arena works
All pages: The docs