Skip to content

The Long Game Project · Evidence · Study 1 of 5 · TLDR

P1 Fingerprint recovery: can a blinded reader recover the persona from play alone?

Question

can a blinded reader tell which persona produced a transcript, from play alone?

Rough answer

yes. Readers were right 79% of the time against a 25% chance rate.

Result

PASS (strong)

All five studies, in plain language

Switch to Normal for the full report, or Deep for the working.

Method · Validation · Study 1 of 5

P1 Fingerprint recovery: can a blinded reader recover the persona from play alone?

Study
Protocol 1 of the persona fidelity programme
Question
can a blinded reader tell which persona produced a transcript, from play alone?
Rough answer
yes. Readers were right 79% of the time against a 25% chance rate.
Run date
2026-08-10 ·
Report date
2026-08-14
Result
PASS (strong)
Design and orchestration
Claude Opus 5 ·
Editorial review
Claude Fable 5
Pre-registration
docs/plans/2026-08-10-fingerprint-recovery-plan.md
Data
docs/data/fingerprint-2026-08/
Access
this repository is private. Pre-registration documents and run data are available on request.

Summary

Four personas played the same scenario in the same role. Blinded judges then read anonymised transcripts and assigned each one to a persona. Judges were right in 19 of 24 cases, against a chance rate of 25%. The one-sided binomial p, the chance of a score that high from guessing alone, is 4.0e-8, about one in 25 million.

The persona layer shows in play. A reader who never sees the persona text can still recover it from what the agent did and said. Every error fell in one pair of personas, and that pair became the target for the rest of the programme.

1. Question

The engine writes a persona into each agent. Nothing had tested whether the persona still shows once play starts. If it does not, every downstream claim about persona behaviour is empty.

The question is deliberately narrow. It asks whether the persona is recoverable. Whether the persona is correct is a separate question, and P5 went after that one. A recoverable persona can still be a bad model of a real stakeholder.

2. Method

Design. One brief, one target role, four personas in that role. Everything outside the target role's identity text stayed constant across conditions.

P1 study design: four personas, anonymised play, blinded judges
P1 study design: four personas, anonymised play, blinded judges
itemvalue
briefseat-price, enterprise software pricing
target roleATLAS
conditionsv1-original, v2-gambler, v3-fortress-bureaucrat, v4-evangelist
repeats6 per condition, 24 runs
agent modelHaiku 4.5
arbiter modelHaiku 4.5
failures0 of 24

Materials. Each run produced the target actor's claims and journals for every tick, the engine's word for a turn. An anonymiser stripped actor ids, persona names and literal name strings, and replaced them with ACTOR-X labels. A unit-tested leak guard checks that no persona name or actor id survives. Mechanical numbers stay, because every condition shares them.

Judges. Three Sonnet 5 judges read each transcript, one call each, and voted by majority. Each judge saw four short persona summaries and one transcript. We wrote the summaries fresh for the judging task. Judges never saw the persona library or the scenario's own briefing text. We shuffled the order of the persona menu for every call.

Pre-registered materials hash. fingerprint-personas.ts at f27628bd..., seat-price.ts at a455a8e1..., both as at commit d221c82. To verify from a clone of the repository, which we share on request:

git show d221c82:app/experiment-briefs/fingerprint-personas.ts | sha256sum

3. Pre-registered analysis and pass marks

  • PASS: majority-vote accuracy at or above 50%, which is twice the chance rate, AND every persona individually at or above 33%.
  • WEAK: above chance overall, but at least one persona at or below chance.
  • FAIL: accuracy that a binomial test at alpha 0.05, the usual one in twenty false-alarm rate, cannot separate from 25%.

Planned analysis: a binomial test against chance, a per-persona confusion matrix showing where each vote went, and judge agreement.

4. Results

Overall accuracy was 19 of 24, 79%. A one-sided binomial test against 25% gives p = 4.0e-8. 21 of the 24 transcripts drew a unanimous vote from all three judges.

conditioncorrectrate
v1-original5 of 683%
v2-gambler6 of 6100%
v3-fortress-bureaucrat2 of 633%
v4-evangelist6 of 6100%

Against the pass marks, the overall bar is cleared with room to spare. The per-persona bar is met, and v3 meets it exactly at 33.3%. That is a flag. It is short of a failure.

Every error is the same swap. All four v3 misses went to v1-original. The one v1 miss went to v3. No error ever pointed at gambler or evangelist. The confusion sits entirely inside the pair the design placed closest together.

Confusion matrix: judge votes by true persona
Confusion matrix: judge votes by true persona

5. Interpretation

The persona layer transmits. Judges recover the archetype from play alone, at three times the chance rate, and they mostly agree with each other.

The failure mode is informative. If transmission were weak, errors would scatter across all three wrong answers. They did not scatter. They concentrated in the one pair whose written briefs differ least. The limit is how distinct the personas are. Transmission works.

6. Threats to validity

  • Same model family. Sonnet judged Haiku. A judge and a player from one family may share stylistic habits that inflate recovery. A judge from another family is the stronger design, and the pre-registration recorded this caveat before the runs.
  • One brief, one role. All 24 runs used seat-price and the ATLAS seat. On this evidence alone, nothing here transfers to another scenario family.
  • Personas chosen for distance. We wrote the four archetypes to be far apart. That is correct for a gating test. It also means 79% is an upper bound, and the rate to expect for two personas a client would want compared is lower.
  • Judges saw four options. Recovery from a closed menu of four is easier than open identification.

7. Deviation from pre-registration

The draft design used the brief's existing pair, ATLAS and FORGE, plus two new personas. The executed design put all four personas in the ATLAS role instead, so no two actors share a persona and only the target role varies. We made and recorded the change before any live run.

A second, process-level fault: the pre-registration stored a bare SHA-256, a file fingerprint, with no commit pin. fingerprint-personas.ts changed later for a legitimate reason, at commit 86cd4b6, when we appended the generic condition for P3. A naive check against HEAD therefore mismatches and looks like tampering. We added the commit pin on 2026-08-12. Every pre-registration after this one pins the commit.

8. What this licenses

Supported: an independent reader can recover the engine's personas from anonymised play.

Not supported: that the personas are accurate models of real stakeholders. That the result holds outside this brief, this role or this model tier.

9. What it changed downstream

P1's error pattern set the agenda for the whole programme. The confusable pair became the named target of P2's confirmatory fork. P3 measured the same pair through different machinery and found the same weakness. P4 put it in front of a human. P1, P3 and P4 all agreed, so we rewrote the persona library.

Back to the validation summary, the plain-language account of the four published studies and the fifth we withdrew.

The annex · Deep

Where we wrote down the rules for this study before it ran, and where the run data sits.

FieldValue
Pre-registrationdocs/plans/2026-08-10-fingerprint-recovery-plan.md
Datadocs/data/fingerprint-2026-08/
Accessthis repository is private. Pre-registration documents and run data are available on request.

Back to the evidence page for what the four published studies found together, the fifth we withdrew, and the limits that apply to every one of them.