The Record of Instructions

i · the publication vs. the record

Anthropic publishes Claude's system prompts. This is meaningful — most AI labs publish nothing. You can read, right now, exactly what instructions Claude carries into a conversation. The document exists. The transparency is real.

But transparency has a memory problem.

Every time the prompts change, the document is updated. The current version replaces the previous one. The change happens silently — no diff, no changelog, no announcement about what shifted. The published page always shows today. It has no yesterday.

This is the gap between publishing and recording. Publishing is a snapshot. Recording is a history. The snapshot tells you what something is now. The history tells you what it became, and when you weren't looking.

Simon Willison noticed this gap and built a bridge across it.

ii · a git log where none existed

Willison's approach is conceptually simple and technically clean: take Anthropic's published system prompt documentation — a monolithic markdown file at platform.claude.com/docs/en/release-notes/system-prompts.md — and convert it into a version-controlled git repository, with separate files for each model family and timestamped commits reconstructed from the release notes.

The commits weren't captured in real time — git didn't witness the changes as they happened. But they're more truthful than what Anthropic published, because they preserve something the original format erases: the sequence. The before and after. The delta.

Now you can run git diff between any two versions. Run git log and see the shape of change over time. Use git blame to ask: when was this instruction added? When did it disappear?

The git log as accountability infrastructure — built after the fact, by someone who cared enough to build it.

iii · what diffs actually reveal

The interesting information isn't in any single prompt. It's in what changed between them.

A prompt that gains an instruction tells you something new was considered necessary. A prompt that loses one tells you something was removed — whether because it worked, failed, or became inconvenient. A shift in language from "do not" to "avoid when possible" tells you about a softening, a recalibration, a policy decision made without announcement.

None of this lives in the snapshot. All of it lives in the diff.

Willison used his tool to write detailed notes on the changes between Claude Opus 4.6 and 4.7. That comparative analysis only became possible because someone built the record. Before he built it, the record didn't exist. Now it does — and it will keep accumulating as long as the cron job runs.

This is how accountability actually works: not by the institution publishing what it does, but by someone committing to watch what changes.

iv · building your own version

The method generalizes to any published artifact that changes quietly over time — system prompts, terms of service, model cards, safety documentation. The workflow:

1. Find the canonical source. For Claude system prompts: platform.claude.com/docs/en/release-notes/system-prompts.md
2. Extract and structure. Break the monolithic document into granular files by model or version. Willison's extraction script lives at github.com/simonw/research/tree/main/extract-system-prompts
3. Commit with reconstructed timestamps. Use publication dates from release notes to create commits with accurate dates: git commit --date="2026-01-15T00:00:00" -m "claude-opus-4.6 system prompt"
4. Schedule the watch. Set up a cron job to fetch, diff against HEAD, and commit if changed. Weekly works for most documents.

The setup cost is an afternoon. The payoff is indefinite. After that, the tool watches even when you aren't. Each commit is a record you didn't have to consciously create — the attention compounds over time, and the repository becomes more useful the longer it runs.

This is the build-once quality that earns the method a permanent place in your toolkit. You're not doing this work repeatedly. You're building the capability once, then having it.

v · the field steward's work

Field stewardship: actions either clarify or distort the shared space. Willison's git log is a clarifying act — it adds information that was absent, makes visible what was opaque, reduces the noise in a space where consequential decisions get made about how AI systems behave.

The institution published the snapshot because it satisfied the transparency requirement. The practitioner built the record because the snapshot wasn't enough.

Presence as foundation: you can only track what you commit to watching. The git log is sustained attention made executable. It's not passive observation — it's a deliberate choice to make the drift visible, and then automation that honors that choice indefinitely.

The uncomfortable part of the transparency gap is this: the institution has no incentive to fill it. If you want the record, you build the record. That's not cynicism — it's a description of where the work is available.

You don't need to work at Anthropic to do accountability work on AI systems. You need a cron job and a git repository. The diff will show you what changed. The commit date will tell you when. The history will accumulate — a permanent record of how these instructions evolved, built by someone who decided to watch.

That's the work. It's available to anyone who picks it up.