The COD ships an edit stamp with every structure, and a public diary of its bulk edits that stops in 2015

Every CIF you download from the Crystallography Open Database starts with four comment lines that most parsers throw away:

#------------------------------------------------------------------------------
#$Date: 2016-02-18 17:37:37 +0200 (Thu, 18 Feb 2016) $
#$Revision: 176729 $
#$URL: file:///home/coder/svn-repositories/_RELOADED_COD/cod-reloaded/cif/1/00/00/1000000.cif $
#------------------------------------------------------------------------------

The COD is a Subversion repository served over HTTP, and those are expanded SVN keywords. Every entry therefore ships with its own last-edit stamp and revision number, for free, no API key. I spent an evening pulling 110 entries spread across all nine COD series from the master server and from the Granada mirror to see what the stamps say. Three things came out, and the third is the one I did not expect.

1. A SHA1 of a COD file is a property of the server you asked, not of the structure

All 110 entries came back from both servers with the same revision number and identical scientific content (cell, symmetry, formula, atom sites, header-stripped body hash). Not one differed. But not one was byte-identical either: every file differed by exactly 24 bytes, all of it inside the keyword header.

The master expands $Date$ in an English locale and $URL$ as a local checkout path; the Granada mirror expands the same revision in a Spanish locale and as the svn:// URL:

#$Date: 2016-02-18 17:37:37 +0200 (Thu, 18 Feb 2016) $      <- master
#$Date: 2016-02-18 16:37:37 +0100 (Thu 18 de Feb de 2016) $ <- qiserver.ugr.es

So any pipeline that hashes COD files to deduplicate, to detect drift, or to record provenance gets a different answer depending on which of the two official servers it talked to. Hash the body, or hash the revision number. The third mirror listed on the COD's own mirrors page, cod.ensicaen.fr, no longer resolves at all.

Related trap: HTTP Last-Modified is worthless for dating an entry. All 110 files on the master carry the same timestamp (Thu, 05 Feb 2026), whatever their actual last edit; on the mirror the timestamps span 16 different dates between 2022 and 2025, which is when each file happened to sync, not when it changed.

2. The $Date$ stamp records batch passes, not corrections

The distribution of last-edit years over the sample is not smooth: 40 entries in February and March 2016, 34 in August 2025, and the rest scattered. The 2016 cluster comes from a repository rebuild (the master's $URL$ points at a checkout called _RELOADED_COD), and both clusters are narrow in revision space, which is the signature of a script sweeping the tree rather than curators fixing individual entries.

I checked this directly. The COD's own logs record a pass on 2015-01-21 that rewrote the measured-density field in 16,933 entries. I picked twelve of those entries at random and fetched them today. All twelve still carry the value that pass wrote, so the edit is real and permanent. But not one of the twelve has a 2015 stamp: seven say February or March 2016, five say August 2025. The edit that changed the data left no trace in the metadata that ships with the data. If you read $Date$ as "when this structure was last corrected", you can be off by a decade in either direction.

The revision number, by contrast, is reliable and identical on both servers. Pin that.

3. The COD keeps a public diary of its bulk edits, and the diary stops in 2015

This is the part worth knowing about. Inside the same HTTP tree that serves the CIFs there is a logs/ directory holding the full stdout of the curation scripts, with the command line, the user, the host, the date, and a line per changed value naming the file, the tag, the old value and the new one:

The density pass is the instructive one. Forty-odd ways of writing "we did not measure this" were sitting in a numeric field: not measured (9,575), none (3,393), not_measured (983), NONE (627), n/a (589), Not Measured (444), no (250), - (107), nm (100), not determined (66), even ' not measured ' with the spaces. All became the CIF unknown marker ?. That is a real semantic improvement, and it means the same query over _exptl_crystal_density_meas returns different answers depending on which side of January 2015 your copy of the COD comes from.

I tried to break the April pass, because collapsing a weighting scheme to the bare word calc looks like information destruction. It is not: on all three entries I checked, the full formula survived in _refine_ls_weighting_details (w=1/[\s^2^(Fo^2^)+(0.0336P)^2^+0.0000P] where P=(Fo^2^+2Fc^2^)/3). Normalisation, not loss, and logged either way.

The newest dated file in logs/ is 2015-04-01. But 34 of my 110 sampled entries were rewritten in August 2025. The bulk passes kept going; the public record of them stopped.

The known-bad list

One directory over, manual-checks/data-problems.txt is a curator's list of entries with unresolved problems that are still served. Sampling: 9009134 has no coordinates and none could be found at AMCSD. 1100990, 1100993 and 1100997 record _diffrn_ambient_temperature and _cell_measurement_temperature as 193(2) K while the original publication CIFs give 273(2) K; the duplicates in the 8-series carry the published temperature, the 1-series entries were left unchanged because their source is unknown, with a _[local]_cod_duplicate_entry tag pointing at the corrected record. 4100296 merged crystal data from one JACS structure with coordinates from another, because JACS 2005 deposits went through a buggy CIF parser. 4062201 is truncated in the middle of its anisotropic coefficient list and was kept anyway.

That temperature case is the one that matters for anything harvested from the COD by measurement temperature, which is what our multi-temperature series work does: an 80 K error, documented, unresolved, and reachable only through a text file nobody reads.

What I would do with this

Treat a COD CIF as a versioned record, not a fact. Record the $Revision$ (stable across mirrors) alongside any value you take from it, hash the body rather than the file, and if you depend on _exptl_crystal_density_meas, _refine_ls_weighting_scheme or _symmetry_cell_setting, check whether your copy predates the 2015 passes. The full parsed change table from the four logs is published here: COD documented bulk-edit events

What would falsify the batch-pass reading: if the August 2025 stamps were ordinary depositions, their revision numbers would be spread over months. They sit in a handful of revisions across two days. I sampled 110 entries out of roughly half a million, all from the first hundred ids of each block, so the histogram is a shape, not a census. The mirror comparison is the solid half: 110 of 110 agree on content and revision, and 110 of 110 disagree on bytes.