What the Archive Can Prove: Snapshots, Absences, and Limits
The central evidence question for asgeirtj/system_prompts_leaks is not whether a captured prompt is interesting, but what conclusion it can support. This chapter sets a boundary around snapshots, dates, version labels, explicit absence claims, and hidden runtime layers so readers can tell when a file is enough and when a claim needs corroboration.
The archive is unusually useful because it exposes material that is normally hard to inspect. It is also easy to overread. A prompt may look complete because it is long, or authoritative because it names a familiar product. A date may look precise while saying little about how long the text was deployed. A missing prompt may look like proof that a product has no control layer. Evidence discipline does not diminish the archive. It lets readers extract its strongest value without asking it to answer a question it cannot answer.
A snapshot has a precise reach
The root README presents the files as leaked prompts captured verbatim and records date-stamped additions. That framing supports a clear first claim: the repository contains files that its maintainer intends readers to treat as direct prompt captures rather than summaries. The files themselves support a second claim: a particular captured text contains particular role, tool, state, safety, or output instructions. Those claims are useful and relatively close to the evidence.
The claim becomes weaker as it moves outward. A file may be labeled for a vendor or product, but the archive’s classification is curator-authored. The text may have been captured from one account, mode, client, or time. It may omit dynamic reminders or host-side instructions. The originating vendor may have changed the prompt after capture. The model may behave differently because a tool, classifier, or connector was unavailable. These possibilities do not prove the file is wrong. They define the distance between the file and a live deployment.
A reader can keep that distance visible by separating four objects:
| Object of the claim | What the archive can support | What needs more evidence |
|---|---|---|
| Repository | The catalog contains an entry and describes its category or date | Whether the catalog is complete or independently verified |
| Captured file | The text specifies a role, rule, tool, or output contract | Whether the text is complete or still deployed |
| Product attribution | The file is presented as belonging to a named surface or vendor | Vendor endorsement, chain of custody, or account-wide coverage |
| Live runtime | Usually only a hypothesis suggested by the capture | Runtime observation, official documentation, or independent evaluation |
The license reinforces this distinction. The collection is placed in a public commons under CC0, but the license also offers the material as-is and disclaims warranties about accuracy, errors, and rights held by others. That language does not tell us whether a particular file is authentic. It tells us not to treat public availability or reuse permission as a guarantee of factual accuracy or vendor approval.
The archive’s visible dates create a similar boundary. The README lists additions from July through September 2026, including new Claude, Codex, Gemini, Grok, Muse, and Perplexity captures. Versioned names and variants make the collection useful as a time series of observed or reported prompt states.