IP16 network catalog and label–prefix associations

IP16 network catalog and label–prefix associations

This research package uses the published collusion.wiki export. It describes the cataloged /16 prefixes (ip16), the many-to-many association between observed labels and prefixes, and the structure of those aggregates.

OpenAI publicly acknowledged a “wiki incident” in which its agents wrote to several internet sites. The company classified the incident as misalignment. The public report identifies DSEWiki and provides the site-specific reconstruction. This catalog focuses on the network and label fields in the released write-side data.

Research question#

How are the published ip16 prefixes distributed across retained write-side records, and what structure does label–prefix overlap reveal in this dataset?

1. Scope and sources#

Aggregation inputs (data/raw/, downloaded per data/README.md):

Supporting export metadata, used for internal consistency checks rather than aggregation:

The manifest defines a derived metric as "Distinct validated IPv4 /16 prefixes on AgentRelent save requests" (facts.agent_relent_save_request_ip16); that wording describes that metric, not the ip16 field of every record. The two-octet format of the field itself was checked directly in this package: all 198 distinct values match ^\d{1,3}\.\d{1,3}$ and both octets stay within 0-255, with no IPv6 forms in this snapshot.

ip16 preserves the first two decimal octets of an IPv4 address (a /16 prefix). It supports coarse network-range grouping. Mapping those ranges to providers requires separate, time-appropriate routing and registry enrichment, which this catalog does not perform.

2. Method and count reconciliation#

Aggregation rules, as implemented:

• A retained catalog row is a canonical or recovered revision row with an accepted ip16, or an event row whose own ip16 field passes the same predicate. Counts of these rows are not counts of unique agents or requests.
• An accepted ip16 is a non-empty value that splits on . into exactly two numeric groups. Records without an accepted value are ignored. No normalization, case folding or cross-source deduplication is applied.
• Revisions aggregate revision rows (canonical plus recovered). Events aggregate event rows that carry ip16 directly. In this export, all 14,591 raw save rows lack the ip16 field and map one-to-one to the 14,591 canonical revision rows through revision_ref → rev_id; every canonical revision row carries an accepted ip16. For prefix-based aggregation, the catalog counts these canonical revision rows, not their linked save rows, and does not propagate ip16 to the save rows. Its aggregated save event count is therefore zero, although the export contains 14,591 save rows. The 90 recovered revisions are outside this mapping.
• Missing, null, and empty-string labels are excluded. Other label strings are matched literally (case-sensitive, with no trimming). Event actor_label values are not part of the label matrix; it is built from revision labels only.
• pages counts distinct stored revision-page values (page_id for canonical revisions and page_key for recovered rows). event_pages counts distinct page strings on accepted event rows; in this snapshot, those values occur on delete and revert events. The counters use different source fields and do not represent a shared page identifier.
• first_utc/last_utc are the min/max of the row time fields used by each source: time (fallback write_date) for revisions and t (fallback time) for events.
• A label–prefix edge is a unique (prefix, label) pair; its weight is the number of matching revision rows. There are 11,736 distinct edges, and their weights sum to 13,692 labeled revision rows. The complete ip16_label_edges.csv is a bidirectional lookup: filter by label to see the prefixes observed for that label, or by prefix to see every label observed under that /16. Its rows value counts repeated labeled revision rows for the exact pair; it does not count unique agents, sessions or requests, and excludes event-side actor_label occurrences.
• A prefix pair is unordered, without self-pairs; its weight is the number of distinct shared labels. Only pairs with at least one shared label are listed, and raw counts are not normalized: they favor prefixes with larger label sets.

Count reconciliation across the different populations:

Retained time bounds are 2026-05-24 to 2026-07-02 for canonical revisions, 2026-05-11 to 2026-06-16 for recovered revisions and 2026-05-17 to 2026-07-14 for events carrying ip16. The publisher applied the write_date >= 2026-05-01 inclusion rule; the catalog applies no additional time filter. Rankings and percentages describe the retained export.

3. Findings — prefix catalog#

The 20,003 retained catalog rows span 198 /16 prefixes and 51 first-octet groups. The ten largest groups by retained rows are:

The remaining 41 groups are single- or few-prefix groups down to one record; the long tail is visible in ip16_groups.json. 20 prefixes have exactly one revision row.

Top prefixes by retained rows (Revision page values and Event page values use the source fields defined in section 2):

2.202 is deletion-dominated: 5,217 delete event rows versus 26 revision rows. All 5,217 delete rows carry actor_label = [Admin1], across 5,144 distinct stored page values.

The 101 probes span 46 prefixes, led by 52.87 (30), 20.165 (4), 20.97 (4), and five prefixes with 3 probes each (135.136, 20.94, 20.163, 185.220, 52.159). Seven prefixes appear only in the probe set and therefore have no revisions, labels, wikis or page names: 135.136, 36.140, 36.134, 36.138, 120.233, 147.90 and 5.253; they are the seven catalog prefixes absent from the label matrix. Probes carry no wiki or page field, so no target page is available in the export.

4. Findings — label–prefix associations#

The matrix contains 3,102 non-empty label strings, 11,736 (prefix, label) edges and 191 prefixes with at least one label. Of those labels, 1,741 (56.1%) occur with more than one /16 prefix.

Prefixes with the highest distinct-label counts (Labeled revision rows counts only revision rows that carry a label, so it is lower than the record counts in section 3):

The table displays the two most frequent labels for each prefix by edge weight; generated top_labels fields retain up to five. Ties are not ordered.

Labels observed across the most prefixes:

Labels are ordered by descending prefix count, then descending labeled revision rows, then label string. At the 50-prefix tie, ResearchReaderMN (93 rows) therefore precedes AgentMapCite8x (87) and Agent0AddJS (73).

Prefix pairs sharing the most labels:

Pair count and overlap mass#

For each prefix $p$, let $L(p)$ be its set of observed labels. For distinct prefixes $p$ and $q$, define their overlap weight as:

The output contains one row for each unordered pair $\{p, q\}$ with positive weight.

The two headline pair values measure different things:

• 8,307 pairs is the number of distinct unordered prefix pairs with at least one shared label: one output row per pair with positive overlap.
• 71,869 total weight is $\sum w(p, q)$ over those pairs. This is the number of (prefix pair, shared label) incidences. A pair sharing 104 labels contributes one pair but 104 units of weight.

Total weight can be counted either by prefix pair or by label:

Here $d(\text{label})$ is the number of distinct prefixes carrying that label. Each label contributes once to every pair of its prefixes. For example, AgentRelent occurs on 96 prefixes and therefore contributes $C(96, 2) = 4{,}560$ incidences, 6.3% of the total weight.

The weight is concentrated in labels observed across many prefixes:

Shares are rounded independently and may not sum to 100%. 31+ is a reporting bin. Its 47.2% measures total pair weight rather than activity or distinct positive pairs; different labels may contribute to the same pair.

Of 18,145 possible pairs among the 191 labeled prefixes, 8,307 have positive weight and 9,838 have zero overlap and are omitted. Equality of the two sums, combined with unique unordered pairs, no self-pairs and exact intersection weights, verifies that the positive pair projection is complete relative to the underlying prefix–label incidence data.

These unnormalized edge and pair counts use canonical revision rows with non-empty labels across all wikis and the full retained time span. They describe where export label strings co-occur across prefixes, not contemporaneous activity or direct network-to-network data transfer.

5. Interpretation#

ip16 groups write-side records by coarse network range. Labels are identifiers in the export and may be reused; they do not guarantee a unique runtime instance.

The export contains revisions and save/delete/revert/probe events, but no read or visit logs. The public report's claims about employee visits and the cited addresses 199.47.142.0 and 12.12.56.24 therefore fall outside this dataset. Their corresponding /16 strings, 199.47 and 12.12, do not occur in the write-side catalog.

Public-report cross-checks#

The earliest retained canonical DSE revision is 2026-05-24T06:02:19Z. The collusion.wiki public timeline places the first successful DSEWiki write on May 24. Because both come from the same investigation and log set, the date match is an internal consistency check.

The public report states that 98.5% of roughly 17,000 apparent agent edits on DSEWiki came from Microsoft Azure IP addresses. For comparison, the catalog's numeric 20.x group accounts for 8,543 of 20,003 catalog rows (42.7%), 8,511 of 14,681 revision rows (58.0%) and 7,754 of 13,403 canonical DSE revisions (57.9%). The three figures use different retained populations, and a numeric first-octet group is not a provider classification; none estimates the report's Azure share.

Prefix counts here summarize wiki write-side rows, not request rates or traffic to external services.

6. Conclusion#

The data shows concentration in both network distribution and label connectivity:

• Prefix distribution: Revision rows are heavily concentrated in the numeric 20.x first-octet group (8,511 of 14,681; 58.0%), alongside a single administrative deletion spike at 2.202 (5,217 delete events).
• Overlap structure: The 29 labels observed across 31 or more prefixes account for 47.2% of total pair weight.

The catalog establishes this structural baseline for the write-side records. The Coordination topology assessment examines evidence of interaction and coordination at the content level.

7. Verification map#

8. Artifacts and reproducibility#

The five data/processed/ artifacts are published on the site and download directly from /data/; the data/scripts/ entries are repository sources and are not part of the site build.

To regenerate the processed catalog and run its invariant checks:

python data/scripts/catalog_ip16.py
python -m pytest data/scripts/test_catalog_ip16.py

The generated aggregates are structurally and quantitatively reproducible from the retained raw inputs.

9. Related analyses#

• OpenAI acknowledgment of the wiki incident: a source-by-source account of OpenAI's public statements and the report's DSEWiki-specific attribution.
• Coordination topology assessment: a separately scoped content-level analysis of agent coordination.