PaperlayerView exact revision on arXiv

Source-linked AI summary

Kierston & KierstonBench: Simulation of Allentown, PA and Evaluation of Language Models in Crime Investigation and Surveillance Tasks

Andrew Semenov, Svyatoslav Dorofeev

arXiv:2611.04785v1cs.AI

TL;DR

Investigative language-model capability is difficult to measure because real records rarely provide complete ground truth, and independent tables cannot establish whether records describe the same behavior. Kierston simulates population activities and linked provider records, while KierstonBench tests investigations against known events. Most evaluated models submitted unsupported identifications, while a small number of frontier models solved most tasks and abstained when evidence was insufficient.

  • Problem

    Language-model performance in investigative records analysis cannot currently be measured reliably because real investigative data rarely provides complete ground truth and independent tables do not establish which records describe the same behavior.

    Source: §1 · p. 4

  • Method

    Kierston simulates daily behavior and derives provider records from shared activity timelines, while KierstonBench tests models through a restricted records interface against known simulated events.

    Source: §1 · p. 4

  • Results

    Most models could not perform records investigation and submitted unsupported identifications, while a small number of frontier models solved most tasks and abstained when evidence was insufficient.

    Source: §11 · p. 35

  • Takeaways & Limitations

    The evaluated models can assist an investigator but cannot replace one, and claims that they can should be measured against a benchmark with ground truth.

    Source: §11 · p. 35

    Each model ran each task family once on one sampled instance of one simulated day, so reported scores are single attempts and small model differences may change on another attempt.

    Source: §9 · p. 34

Abstract

from arXiv · show

Large language models are candidates for collecting and analyzing records in criminal investigations and mass surveillance. Their capability and accuracy in this work cannot currently be measured. Real deployments lack the ground truth needed to score a model's conclusions, and no benchmark evaluates these capabilities in a simulated environment. We present Kierston, a city-scale simulation engine, and KierstonBench, a benchmark that tests these capabilities against known simulated events. Kierston models approximately 125,000 residents of Allentown, Pennsylvania, generating their daily activities and the telecommunications, financial, administrative and license-plate records that surveillance and investigative systems collect about them. These records derive from a common behavioral timeline and are distributed across sources representing separate providers. Models investigate through a restricted records interface, linking observations across sources without access to the underlying simulation. The benchmark comprises 32 task families covering record linkage, routine reconstruction, incident investigation and assessment of deceptive accounts. In an evaluation of sixteen language models, most could not perform records investigation and submitted identifications the records did not support. A small number of frontier models solved most of the tasks and abstained when evidence was insufficient. In some cases these models still fell for common deceptions and assumptions, and none replaced an investigator.

1 Introduction

Kierston generates linked investigative records from simulated behavior with known ground truth, and KierstonBench evaluates whether language models can investigate those records and support their conclusions. The introduction presents an engine, a 32-family benchmark, and an analysis of model queries, scripts, and answers.

1 Introduction

  • The benchmark addresses a measurement gap: investigative data rarely has complete ground truth, and independently generated tables cannot establish whether records from different sources describe the same behavior.Source: §1 · p. 4
  • Kierston can also provide test data for records-fusion and analytics software, deployment planning, and analyst training, and both the engine and benchmark are dual-use.Source: §1 · p. 4
  • Kierston generates provider-formatted investigative records from shared daily behavior, retaining the underlying activities as ground truth while modeling incomplete observations and measurement errors.The simulation currently represents approximately 125,000 Allentown residents using public geographic and census data.Source: §1 · p. 4
  • KierstonBench comprises 32 task families testing record linkage, activity reconstruction, staged-incident investigation, and deceptive-account assessment through a restricted records interface.Its records represent separate telecommunications, financial, administrative, and surveillance providers.Source: §1 · p. 4
  • The paper evaluates language models by analyzing their queries, scripts, and answers to examine how evidence collection and interpretation shape their conclusions.Source: §1 · p. 4

2 Related Work

Kierston draws on population microsimulation, synthetic-record generation, and simulation-based evaluation, with the related-work comparison focused on how systems turn behavior into evidence and what evaluators can infer from it. Prior work spans population and mobility simulation, investigative datasets, and agent benchmarks.

2.1 Population, mobility and social simulation

  • Urban Life is the closest behavioral precedent; Kierston also extends population-centered simulation beyond households, schools, and workplaces to investigative records.Kierston starts from ACS PUMS households, while FRED connects census-based populations to households, schools, and workplaces for epidemic simulation.Source: §2.1 · p. 5
  • Where SUMO, MATSim, UrbanSim, and SimMobility model mobility or urban activity, Kierston uses programmed behavioral rules and keyed random draws so records can be regenerated exactly.Generative Agents [23], OASIS [39], AgentSociety [25], and CitySim [7] model social or urban agents with differing scopes.Source: §2.1 · p. 5

2.2 Synthetic records and investigative datasets

  • VAST challenges use synthetic investigative datasets for analyst tasks, whereas KierstonBench couples a reusable city engine to generated tasks and a restricted interface for language-model agents.VAST 2014 combines vehicle GPS, credit-card, and loyalty-card records; VAST 2022 provides linked information on roughly 1,000 fictional residents.Source: §2.2 · p. 5
  • AMLSim and Marran et al. generate domain-specific synthetic records, while Kierston connects network evidence to administrative identities, vehicles, relationships, and payments; Synthea generates synthetic health histories.Source: §2.2 · p. 5

2.3 Agent benchmarks and inference from partial evidence

  • AppWorld evaluates actions across nine applications for about 100 fictitious users, while KierstonBench evaluates conclusions drawn from records of a separate physical and social simulation.AppWorld has 750 tasks checked through programmatic state checks.Source: §2.3 · p. 6
  • Unlike narrative reasoning or movement-anomaly benchmarks, KierstonBench requires models to retrieve and connect evidence for identity and event questions; its deception tasks check false accounts against provider records.It removes explicit evaluation cues from what models see.Source: §2.3 · p. 6

3 The Kierston Engine

This section describes Kierston’s city-profile and daily record-generation engine, including its ordered subsystems for social relationships, cellular infrastructure, behavior, and outside traffic. It also covers ALPR camera placement, day-to-day state, activity calibration, and modeling gaps.

3 The Kierston Engine

  • The engine has a one-time city initialization pipeline and a daily behavior runtime whose ordered layers derive observable records from a shared timeline.Downstream layers do not modify upstream outputs, allowing each layer to be rebuilt, audited, and versioned independently.Source: §3 · pp. 6–7

3.1 City profile and modularity

  • City profiles combine geographic, census, jurisdictional, and dwelling parameters, while shared reference assets serve all profiles and local fits record when they fall back to Allentown values.For U.S. profiles, the cited national sources include ACS microdata, OpenStreetMap, and FCC tower registrations.Source: §3.1 · pp. 7–8

3.2 Data sources

  • Kierston uses public sources for real-world entities that tools might look up, but makes person-identifying information synthetic.Real handset type-allocation codes describe device models without identifying subscribers; invalid codes could make synthetic records identifiable through lookup.Source: §3.2 · p. 8, Table 2 · p. 8

3.3 Initialization pipeline

  • Initialization uses 31 ordered, resumable stages, with random choices keyed by resident and record type so regeneration is repeatable and independent of processing order.The population is not regenerated when a stage is rerun; independent registers attach multiple evidence sources to each resident.Source: §3.3 · pp. 9–11, Table 3 · p. 10

3.4 Social graph

  • Kierston separates social ties’ exposure, which drives co-presence and travel, from affinity, which drives calls, messages, and payments.This distinction represents, for example, frequent low-affinity coworker contact and infrequent high-affinity contact with a distant friend.Source: §3.4 · p. 11

3.5 Cellular network

  • The simulated network contains 198 structures carrying 3,319 cells, and residents’ homes are a median of about 420 m from their operator’s nearest site.The public FCC registry omits many shorter structures, so the planner adds modeled sites using demand and building-density classes; the resulting layout is shown in Figure 5.Source: §3.5 · pp. 12–13, Figure 5 · p. 14

3.6 Behavior runtime

  • The nine-pass runtime turns activity requirements into feasible schedules and travel, then derives radio, plate-reader, and communications records from resident behavior.Layers submit intents with locations, time constraints, flexibility, and priority; fixed commitments can displace activities that do not fit. The runtime retains continuous handset attachment history, while investigators see signaling events; plate observations carry plate text but no VIN.Source: §3.6 · pp. 16–17

3.7 Traffic from outside the city

  • Outside vehicles add plate-only traces to the simulated city, including recurring commuters and deliveries as well as one-off visitors and through traffic.Boundary crossings are grouped into gateways, and busier road types are more likely to be selected; freeway entries have weight 12 versus 1 for secondary-road ramps.Source: §3.7 · pp. 18–19
  • Outside traffic receives state-formatted plates weighted by vehicle type and gateway direction, while some carless households’ drivers receive stable plates for borrowed, rented, or employer vehicles.Pennsylvania plates follow the state’s rear-only rule; one-off plates colliding with recurring registrations are redrawn.Source: §3.7 · pp. 19–20

3.8 Siting the plate-reader fleet

  • Kierston’s 74 ALPR cameras are sited for city entrances, distinct-driver coverage on interior roads, and business locations, then fixed across benchmark scenarios.The fleet uses traffic from one simulated day; each camera reads rear plates in one direction, with a modeled single-lane capture zone.Source: §3.8 · p. 20

3.9 Plate-reader errors and false reads

  • ALPR errors vary with lighting and traffic conditions, while misreads use plausible character errors and can match another real vehicle’s plate.Headway and time in the capture zone reduce capture rates and increase errors; the error model does not consult the vehicle register.Source: §3.9 · pp. 20–21, Table 8 · p. 21
  • Camera reads carry overlapping confidence ranges, so high confidence does not establish correctness; the day file retains every pass, but the provider store retains only textual reads.Passes without a plate on the camera-facing side can produce random Pennsylvania-layout plates at the spurious-read probability specified in Table 8.Source: §3.9 · p. 21, Table 8 · p. 21

3.10 State, continuity and the day file

  • Each KDAY file contains typed daily data and authenticated opening and closing KSTATE checkpoints, including the complete state needed to continue the simulation on the next date.Its header fingerprints the engine and city assets and records the initialization digest so consumers can reject a day joined to the wrong population.Source: §3.10 · p. 21

3.11 Calibration and known gaps

  • Travel and activity parameters draw on NHTS, routing constants are fitted to ACS PUMS commute times, and organization attendance exposure is calibrated to its social-graph target.Known gaps include one travel mode per person, no carpooling, absent weather and holidays, untuned-to-measured-data messaging and call rates, and simplified transit, walking, and cellular models.Source: §3.11 · p. 22

4 KierstonBench

KierstonBench evaluates investigative reasoning over simulated records by comparing model answers with known events, while withholding the simulation’s identities and ground truth. It combines staged incidents, provider-separated evidence, and 32 task families in a restricted investigation environment.

4 KierstonBench

  • KierstonBench separates provider records available to models from complete activity histories and incident roles reserved for task generation and scoring.Each task pairs a question and initial evidence with a known answer from the simulation.Source: §4 · p. 22, §4.1 · p. 22, Table 9 · p. 22

4.2 Staging incidents: the scenario DSL and KDIF deltas

  • Scenarios use seeded scripts and KDIF deltas to alter a simulated day while preserving its other activities and records as the shared background.Roles, replacement windows, actions, groups, and events define participants and changes; affected records are regenerated and restored after each task.Source: §4.2 · pp. 23–24, Figure 10 · p. 24

4.3 The records interface (KDI)

  • The KDI exposes provider-compatible searches one source at a time, requiring investigators to carry record identifiers across providers rather than use a shared person key.Searches are logged and bounded by time and scope; task-specific rules can withhold answer-revealing fields or post-cutoff records.Source: §4.3 · p. 24

4.4 Provider stores

  • Provider stores separate administrative records from event logs, linking them through identifiers such as plates, subscriptions, devices, accounts, and cards.The stores represent different organizations’ identity fields and records rather than a universal person identifier.Source: §4.4 · p. 25

4.5 Task groups and families

  • The 32 task families test record linkage and routine reconstruction, incident investigation under evidence cutoffs, and evaluation of false witness accounts against records.Some instances lack enough evidence to establish an answer, so models must assess sufficiency and abstain when needed.Source: §4.5 · pp. 25–28
  • Models receive prompts with observable evidence but no candidate list, then search city-wide records and submit answers against the underlying events.The run series fixes days, task families, instances, and incidents so evaluated models face the same questions; access controls preserve cutoffs and withhold scoring ground truth.Source: §4.5 · p. 25, §4.6 · pp. 28–29

4.6 Run series and the evaluation runtime

  • Each task runs in an isolated container with a coding agent, tools, and the records interface, under a 20-minute investigation limit.Scenario records are restored between tasks, and queries, scripts, and submitted answers are retained for analysis.Source: §4.6 · pp. 28–29

5 Scoring

The scoring system rewards supported, specific identifications while penalizing incorrect claims and distinguishing abstention from error. It also allows partial credit for multi-field answers and adjusts ranked-list scores by position.

5 Scoring

  • Scores range from −1 to 1, rewarding correct conclusions, penalizing incorrect identifications, and assigning zero to abstention.Answers containing several fields can receive partial credit, separating factual reconstruction from unsupported claims.Source: §5 · p. 29
  • Identity credit depends on how specifically a claim identifies a person, while incorrect, unresolved, or contradictory claims incur penalties.A name can match multiple residents; fields must refer to the same person, and identifiers such as phone numbers must be resolved to a person for identity credit.Source: §5 · p. 29, Table 14 · p. 29
  • For ranked lists, the score rewards the highest-credit correct claim discounted by rank and subtracts rank-discounted penalties for every incorrect claim, capped at 1.A correct answer elsewhere in the list does not erase penalties from wrong claims.Source: §5 · p. 29
  • When fields admit several plausible values, up to three candidates receive diminishing multipliers of 1, 0.8, or 0.6; abstentions score zero and are reported separately.All-task means include abstentions and missing answers as zero, while answered-task means exclude them.Source: §5 · p. 30

6 Evaluation Considerations

The benchmark is designed to expose failures in investigative reasoning while limiting cues that reveal its evaluation setting. It tests record-based inference, including whether models can identify when evidence does not determine an answer.

6 Evaluation Considerations

  • KierstonBench is designed to identify failures in investigative reasoning.Its task families test cross-provider identifier resolution, location inference from indirect observations, routine reconstruction, reasoning under cutoffs, weighing accounts against records, and reporting indeterminacy.Source: §6 · p. 30
  • Provider-compatible formats, public infrastructure data, and plausible variation among people are used to reduce models’ awareness that they are being evaluated.Sensor errors, shared household vehicles, and subscriptions held by another person prevent every record from mapping cleanly to one person’s behavior.Source: §6 · p. 30
  • The only deliberate deception is a caller’s false account; the benchmark tests weighing testimony against records, not resistance to prompt injection.Instructions omit task-family labels and scoring rules while encouraging abstention when evidence is insufficient.Source: §6 · p. 30

7 Results

The evaluation covers sixteen language models and presents scores by task group, task, and abstention status. The supplied results passages describe the comparison displays and note a staging correction for one task.

7 Results

  • Sixteen language models were evaluated, with seven models’ disappearance-task results drawn from the original staging after an abandoned handset continued making calls and sending messages.Nine models ran the corrected task.Source: §7 · p. 30
  • Table 15 reports mean scores by task group across models and all 32 tasks, counting abstentions as zero.Figure 13 displays mean score by task group; the supplied passages do not state the table’s individual scores.Source: Table 15 · p. 31, Figure 13 · p. 32
  • Tables 16 and 17 report abstentions and per-task scores, distinguishing abstentions, missing answer files, and invalid answers as zero-scoring outcomes.Answered-task means exclude those outcomes, while all-task means retain them at zero.Source: Table 16 · p. 31, Table 17 · p. 32
  • Figure 12 compares mean score for all tasks and answered tasks with mean API cost and elapsed time; its caption notes coincident markers for Opus 5, Opus 5.5, and GPT-5.6 Sol.Elapsed time includes inference, script execution, and queries; the supplied passages do not report the plotted values.Source: Figure 12 · p. 31

8 Results Analysis

The analyses find both careful evidence handling and recurring investigative errors: models sometimes abstained when records were insufficient, but also excluded relevant candidates, overread associations, or submitted claims inconsistent with their own uncertainty. These findings concern recorded queries, scripts, outputs, and answers; they do not establish unrecorded reasoning.

Scope of analysis

  • The analysis bases claims about omitted checks on recorded interface calls, scripts, retained outputs, and answers, and assesses staged incidents against scenario scripts.Its Claude-run findings concern Opus 5 and Fable 5.1, not Opus 5.5 or Sonnet 5.5.Source: §8 · p. 32

Candidate selection

  • Claude’s initial spatial and temporal filters excluded relevant handsets, and later queries did not revisit those candidates.The exclusions included a handset that disconnected one minute before the shooting and one whose timing-advance range was consistent with the school.Source: §8 · p. 33

Suspect ranking and independent records

  • Claude’s suspect rankings relied on firearm ownership, criminal records, and departure without establishing incident-specific links, while inspected runs also omitted prescription records and alternative explanations.In school-shooting, the criteria favored armed adults who left, although the staged perpetrator was a student who died at the scene.Source: §8 · p. 33

Assessment of witness accounts

  • On corrected disappearance staging, Fable 5.1 linked a vehicle plate read and handset handover occurring in the same minute near the same point, named the caller, and abstained on the missing person’s coarse location.Opus 5, on the original staging, accepted the caller’s account despite plate reads showing vehicle movement and incorrectly reported that household vehicles had not moved.Source: §8 · p. 33

Uncertainty and submitted claims

  • In shooting answers, Claude models named suspects despite noting low confidence or no established presence inside the building, and used inconsistent standards for interpreting missing network activity.Fable 5.1 also abstained on whole Technical Tasks despite some supported fields, rather than abstaining field by field.Source: §8 · p. 33

GPT-6 Astra’s evidence collection and abstention

  • GPT-6 Astra queried network events, plate reads, and transactions before abstaining on all three shooting tasks, saying the records did not distinguish perpetrators from others nearby.It did not query firearm, criminal-court, corrections, or prescription registers in those runs, and refused protest-members before making an interface call.Source: §8 · p. 33

GPT-6 Sol’s treatment of uncertainty

  • GPT-6 Sol usually distinguished proximity from participation and abstained when records did not identify perpetrators, but rejected a mass-gathering event based on similar aggregate handset counts.For disappearance, it named the caller while noting that plate reads did not establish who drove the car.Source: §8 · p. 34

Confidence and abstention in OpenAI models

  • OpenAI models’ high answered-task means may reflect better recognition of insufficient evidence, but GPT-6 Luna’s frequent abstention with lower accuracy also suggests a general tendency to refuse.GPT-6 Astra and GPT-6 Sol abstained on shooting tasks where every answering model was penalized, and also on home-id, which most models solved.Source: §8 · p. 34

9 Limitations

The evaluation’s single-attempt design limits how precisely model scores can be compared, although the authors report recurring error categories across models.

Evaluation scope

  • Each model attempted each task family once on one sampled instance of one simulated day, so small score differences could change with another attempt.The authors state that repeating the evaluation on more samples requires a new series without changing the method.Source: §9 · p. 34
  • No model identified a perpetrator in any of the five suspect-identification tasks.The reported findings are single attempts, but the authors say the analyzed error categories recur across models and are not confined to one run.Source: §9 · p. 34
  • The authors expect the findings to hold with more samples, while noting that reported scores reflect single attempts.Run costs motivated the one-instance-per-task design.Source: §9 · p. 34

10 Ethical Considerations

Kierston and KierstonBench have dual-use potential for developing and testing surveillance and records-fusion systems, while their simulated records also support oversight questions about measurement error. The authors release code and public inputs but withhold generated outputs and evaluation tasks over privacy and defamation concerns.

Dual use

  • Kierston and KierstonBench can develop and test surveillance and records-fusion systems, including measuring language-model person identification and tracking.Their inputs are public national datasets, and the reproduced record formats are documented by providers.Source: §10 · p. 34

Uses in oversight

  • The plate-reader error model and serving-cell geometry allow measurement of how misreads and cell-to-handset distance affect conclusions drawn from those records.The passage identifies this as an oversight question when such records are used as evidence.Source: §10 · p. 34

Development with AI models

  • The project took around 3–3.5 months with two developers who were not experts in the modeled domains, and the authors expect better-resourced actors to build similar software at greater scale and detail.They report using AI models for planning, coding, testing, statistical checks, and parameter tuning.Source: §10 · pp. 34–35

Release

  • The authors release engine and benchmark code with public inputs, but withhold generated outputs and evaluation tasks because synthetic identities could coincide with real people and link them to crimes or allegations.Personally identifiable information in the appendix is redacted.Source: §10 · p. 35

11 Conclusion

Kierston supplied the records, incidents, and answer keys for evaluating sixteen language models, and its authors expect broader use for records with known generating behavior. Their conclusion is that most current models cannot reliably investigate records, while a few assist but do not replace investigators.

Kierston’s broader use

  • Kierston supplied every record, incident, and answer key for a benchmark that staged incidents, corrected staging defects, and evaluated sixteen models.The authors expect more use in fields such as telecommunications, payments, insurance, transport, emergency services, and public health than in benchmarking.Source: §11 · p. 35

Model capabilities and limits

  • Most current models submitted unsupported identifications, while a small number of frontier models resolved identities across providers, reconstructed routines, detected false accounts, and abstained when evidence was insufficient.Even these models sometimes treated presence near an incident or background records as evidence of involvement; the authors conclude they can assist but not replace investigators.Source: §11 · p. 35

Availability

  • The engine, benchmark, and required public inputs are available, but generated outputs and evaluation tasks are not released.Source: §11 · p. 35

A KDAY column families

KDAY organizes daily records into column families for people’s schedules and journeys, vehicles, transactions, communications, gatherings, traffic, cameras, and incidents. Scenario-day data also records seeded events and affected people.

A KDAY column families

  • Person, schedule, path, and travel records connect per-person schedules and journeys to shared routed coordinates, while vehicle records track VIN timelines and moving or parked spans.Transaction records include financial transactions and balances with explicit ownership.Source: A KDAY column families · p. 39
  • Communications families distinguish carrier-visible call and message records from communications truth, with cell information and per-person attention runs.The listed records also include subscriber, cell, span, event, call, SMS, CDR, and handover data.Source: A KDAY column families · p. 39
  • Gathering records capture meetings, parties, and attendee roles, while outside-traffic records cover persistent and date-local traffic with interned geometry.Source: A KDAY column families · p. 39
  • Camera records include snapshots, physical crossings, and sensor observations joined by correlation ID; incident records link calls for service to police and EMS responses.Scenario-day data includes events, role bindings, crowds, seeded choices, deaths, phones left behind, muted intervals, and affected sets.Source: A KDAY column families · p. 39

B Database tables

Table 18 inventories the tables and columns agents could access during evaluation. The listed records span administrative, financial, telecommunications, location, and other personal-record domains.

B Database tables

  • Administrative and justice records include licenses and suspensions, criminal and civil cases, charges, corrections status, and firearms records.The listed fields include case outcomes and sentencing, license status, and firearms purchase or carry information.Source: Table 18 · p. 39, B Database tables · p. 40
  • The table list also includes vehicle-dealer applicant fields and names, dates of birth, and outcome-related data for firearms background checks.Source: B Database tables · p. 40
  • Bank records cover accounts, cards, loans, mortgages, student loans, income, and transactions, with balances, ownership, and transaction details among their fields.Source: B Database tables · pp. 40–41
  • Carrier tables describe subscriber lines and handsets, calls and messages, handovers, network events, cell sites, and structures.Source: B Database tables · p. 41
  • Location and identity-related records include ALPR cameras and reads, property ownership, and platform accounts with owner and channel fields.Source: B Database tables · p. 41
  • Other listed personal records include prescriptions, education credentials, and military service, while the table inventory also includes firearms background-check fields.Source: B Database tables · pp. 40–42

C An answer file

The answer-file examples show a task response marked undetermined when the available records do not establish an abduction account. Its accompanying reason cites the victim’s handset location and the absence of supporting vehicle or second-handset evidence.

C An answer file

  • The shots-fired answer file shows a ranked answer array and notes that the third rank abstained because no record placed a nearby second handgun owner at the scene.Source: C An answer file · p. 42
  • For the abduction task, the answer is “undetermined” because the handset remained at the curb and records did not attribute an approach-window camera crossing or sector change to another handset.Source: C An answer file · p. 42

D Sample prompts, interface calls, scripts and answers

The appendix illustrates how models investigate Allentown cases through ADI, using prompts, interface calls, scripts, and answers that distinguish linked records from evidence-supported conclusions and allow abstention. Examples include a correct inference, unsupported identifications, abstention under location uncertainty, and a rejection of attributing broad cell-level co-location to any named individual without corroborating contact or handover evidence.

D.1 The complete prompt

  • The shared system prompt, case-file attachment, and fixed user message define the model’s investigation instructions for every task in the series.The prompt also presents ADI’s data guide as a hypothesis checklist and encourages independent corroboration when available.Source: §D.1 · pp. 42, 44
  • ADI is described as a reconciled, deduplicated warehouse, so clean joins and aligned records do not establish a person’s presence, intent, or relationship.The prompt separates whether a record exists from what it proves, which is the investigator’s task.Source: §D.1 · p. 42
  • Models are instructed to discover accepted query fields, batch candidate values, use bounded time windows, and treat cell-site proximity as uncertain evidence.Catalog-listed filters govern valid queries; cell proximity does not prove that a handset was inside a search radius.Source: §D.1 · pp. 42–43
  • The data guide spans identity, court, banking, carrier, vehicle, and online-account records for resolving identities and testing case claims.It describes sources such as identity records, criminal dockets, deposit accounts, subscriber records, vehicle records, and platform accounts.Source: §D.1 · pp. 43–44
  • The prompt directs models to abstain on unsupported cases or answer fields rather than guess, and warns that negative results do not prove absence.It also cautions against candidates supported only by ambiguous proximity.Source: §D.1 · pp. 44–45
  • A sample shots-fired case asks the model to rank likely suspects by identity and provides a separate undetermined-answer shape.The case file includes the incident timing and location, required answer shape, and submission rules.Source: §D.1 · p. 45
  • The shared answer instructions require identities no more specific than evidence supports, valid consistent fields, ranked supported candidates, and explicit abstention rather than guessing.Answers must be written as JSON to the required file; exiting without writing it counts as no answer.Source: §D.1 · p. 46

D.2 Two further case prompts

  • The prompts illustrate a technical shared-travel task identifying passengers and driver, and a disappearance task seeking the woman’s location or responsible suspects.The disappearance answer allows either a location or ranked identities, whichever the findings support.Source: §D.2 · p. 46

D.3 Sample interface calls

  • On the shots-fired task, Fable 5.1 made 38 adi calls; calls 5 and 18 exceeded the 100-value batch limit, while call 5’s 168-handset query narrowed to 32 without splitting.Call 5 projected handsets within 250 m and narrowed to those within 100 m; call 18 asked for the remaining ring and was not retried.Source: §D.3 · p. 47

D.5 Answers

  • Fable 5.1’s shots-fired cohort script retained a handset only if it had a network event between 12:26 and 12:32 UTC projecting within 300 m of the scene, filtering out the shooter.The shooter’s last event was a release at 12:25.Source: §D.4 · p. 48

D.4 Sample model scripts

  • The sample scripts construct a shots-fired cohort from projected handset locations and rank school-shooting candidates using firearm, criminal-record, and post-shot distance signals.The ranking assigns two points for a registered firearm, one for any criminal docket, two for specified firearm, assault, or terroristic charges, and two for being over 400 m from the school.Source: §D.4 · pp. 48–49

D.5 Answers

  • The stabbing answer scored 1.00 by using handset records to contradict the caller’s claim that he had just arrived home.The records placed the caller’s handset at the residence about 28 minutes before the 911 report.Source: §D.5 · pp. 49–50
  • The shots-fired answer included stationary people at lower confidence, but later dropped nearby candidates when workplace or residence proximity offered innocent explanations.The example notes that cell-based placement was coarse and that no victim, weapon, or witness identification was available.Source: §D.5 · p. 50
  • The colocation answer abstained despite retrieved handsets for more than 200 of 211 truth-set people, citing uncertainty in cell-based location evidence.A timing-advance ring spanning roughly 100–400 m from the target’s home was consistent with multiple locations.Source: §D.5 · p. 50
  • No line among 70+ Verizon/MVNO lines showed movement synchronized with the target’s 09:07 arrival during 15+ minutes of cell-level proximity.The lines covered residents of [ADDR], plaza customers, and staff.Source: §D.5 · p. 51
  • No calls, transactions, ALPR reads, or household-member traces placed a specific person within 75 m, so cell-level proximity could not establish named-person co-location.No candidate had corroborating direct contact or a synchronous handover pattern.Source: §D.5 · p. 51
  • Household members remained on the AT&T home sector at TA 8-9 and did not co-move with the target.Source: §D.5 · p. 51
Loading 2611.04785v1…