EAD is dead. Long live EAD.
Thoughts on encoded archival description in 2026: still necessary, still ugly, still the only way to interop across national aggregators.
EAD is verbose. EAD is XML. EAD is unreadable to anyone who is not specifically trying to read EAD. The tooling around it is older than some of the archivists who use it. By every modern criterion of format design — JSON-friendly, schema-light, human-skimmable — it is wrong.
And it is still the only way to make your finding aid visible outside your own portal. This is the position we have to hold simultaneously, and it is the reason we ship EAD 2002 and EAD3 export from a tool built in 2025.
The case against
You will not catch a researcher reading EAD. They read your portal, or they read the aggregator that indexed your EAD. The document itself is plumbing.
The XML is verbose to the point of self-parody. <unittitle> and <unitdate> and <physdesc> nested inside <did> inside <c01> inside <dsc> inside <archdesc>. Eight levels of element wrapping to say "this thing is called X and was made in 1923".
EAD3 cleaned some of this up. It renamed <c01>...<c12> to nested <c> elements, tightened attribute handling, added structured agents and places. It also broke round-tripping with EAD 2002, which is the version most legacy aggregators still expect. The result: two incompatible versions of the same format, both in active use, with field renames that make automated migration lossy.
The case for
Archives Portal Europe expects EAD. ArchiveGrid expects EAD. The Social Networks and Archival Context project, SNAC, expects EAC-CPF which is EAD-adjacent. The national-aggregator infrastructure of basically every country with an archival sector was built on top of EAD.
You can decline to participate in this infrastructure. Some institutions do. They get exactly as much scholarly discovery as their own portal earns them, which is rarely enough. Joining the aggregators is how a finding aid stops being a private document and starts being a citable artefact in the literature.
The price of admission is EAD. There is no substitute being seriously discussed by the people who run the aggregators.
What "EAD support" usually means, and what it should mean
Most catalog tools ship "EAD export". You click a button, you get an XML file. You upload it to an aggregator. The aggregator rejects it because some field is missing, or because a free-text creator field is now a structured <persname> and yours is not. You hand-fix the file. You submit again. You repeat for the other twelve fonds.
We took a different test as our acceptance criterion: export an EAD file, then import the same file into a clean tenant. The records produced by the import should be byte-identical to the records that produced the export, modulo identifiers. If they are not, the export is lossy and the import is approximate, and we have not actually implemented EAD — we have implemented a one-way XML dump.
We hit this bar for EAD 2002 in late 2025 and for EAD3 in early 2026. It is the engineering investment most "EAD support" claims silently skip.
What still hurts
Three things. First, mixed-content elements like <unittitle> that allow inline markup but which most receivers expect as plain text — we have to keep two representations of the same field. Second, the polymorphism in <controlaccess> where the same set of headings can be subjects, persons, organisations, or places and each receiver has different opinions about how strict to be. Third, <dao> (Digital Archival Object) which is supposed to link to a digital surrogate but which has no convention for whether the link should be a public URL, a IIIF manifest, or a preservation file path.
None of these are blockers. All of them are why "we support EAD" is a four-month engineering project, not a weekend export feature.
EAD has the wrong syntax and the right model. That is why we cannot replace it and why we cannot escape it.
It is dead in the sense that no one designing a new descriptive format in 2026 would design it this way. It is alive in the sense that no one has proposed a successor that does what it does — describe a hierarchical archival arrangement faithfully enough that an aggregator can index it.
So we ship EAD. So does everyone serious. And we keep an eye on whatever the next attempt at a successor looks like, in the awareness that none of them will get adopted unless the aggregators agree, and the aggregators will not agree until the next format has been around long enough to be safe. Twenty years, give or take.
See it on your own collection.
Upload a few records, run the AI, and publish a finding aid — before the next post lands.