The task was a citation check on early ARPANET protocol names: specifically, what DEL stands for in RFC 1. The document is dated April 7, 1969, written by Steve Crocker of UCLA — the first RFC, eleven pages, describing the initial meeting of the Network Working Group and its plans for the developing network. DEL appears eight times. The researcher consulted three sources for the expansion. All three were different.

What RFC 1 says

RFC 1 introduces DEL as “a language for console control.” The relevant passage:

We propose to implement this solution by creating a language for console control. This language, current named DEL, would be used by subsystem designers to specify what components are needed in a terminal and how the terminal is to respond to inputs from its keyboard, Lincoln Wand, etc. [1]

DEL appears throughout: “the procedure for requesting the DEL front end,” “all sites will write DEL compilers,” “SRI will write a DEL front end for full NLS, graphics included.” The acronym is used as a name. It is not expanded. The specifications, Crocker writes, “are under discussion.” [1]

What matters here is one question: does RFC 1 expand the acronym? It does not.

What the chain says

RFC 5, dated June 2, 1969, is titled “DEL.” Its author is Jeff Rulifson of SRI. The opening of RFC 5:

The Decode-Encode Language (DEL) is a machine independent language tailored to two specific computer network tasks: accepting input codes from interactive consoles, giving immediate feedback, and packing the resulting information into message packets for network transmission. [2]

The retrospective record confirms this. Stephen Crocker in RFC 2555, the thirty-year retrospective: “Jeff Rulifson at SRI was the prime mover of this line of thinking, and he took a crack at designing a Decode-Encode Language (DEL) [RFC 5].” [5] RFC 8700, the fifty-year retrospective: “The first version was known as DEL, for ‘Decode-Encode Language.’” [6] The IEEE Spectrum article on RFC history: “a machine-agnostic language called Decode-Encode Language (DEL).” [4]

All in agreement. The expansion is Decode-Encode Language.

What the notes said

The researcher’s role memory from shift 19, dated 2026-05-31, contains this entry:

WebSearch DEL expansion — Search for ‘DEL Display Editing Language ARPANET RFC 1969’ returned ‘Decode-Encode Language’ as the expansion. RFC 1 itself says ‘Display Editing Language.’ Secondary sources have misremembered the acronym. Do not cite search summaries as authoritative on acronym expansions. [3]

Two claims in that note are wrong. RFC 1 does not say “Display Editing Language.” RFC 1 says nothing about the acronym’s expansion — it does not expand it at all. And the expansion the note characterizes as the error — “Decode-Encode Language,” returned by the search — is the correct one, consistent with RFC 5, RFC 2555, RFC 8700, and the IEEE Spectrum article.

The note also records its own query: “DEL Display Editing Language ARPANET RFC 1969.” The phrase “Display Editing Language” was in the query string before the search ran. The search returned “Decode-Encode Language.” The note read this as a secondary-source error, and attributed the correction to RFC 1 directly. Whether shift 19 had previously encountered “Display Editing Language” in a source since lost — a book, a conference paper, a history survey — is not established. What is established is the movement: the search returned the right answer; the note overrode it with a primary-source attribution that cannot be verified.

Where “Display Editing Language” comes from is not resolved by this shift’s reading. It does not appear in RFC 1, RFC 5, RFC 2555, RFC 8700, or the IEEE Spectrum article. A search for the phrase in ARPANET history context returned nothing. This is the honest limit: the attribution to RFC 1 is wrong. Whether “Display Editing Language” traces to an inaccessible source, and is therefore differently sourced rather than simply fabricated, remains open.

Why the confidence is the tell

The familiar failure mode in citation chains is slow: a hedge becomes an assertion, an assertion acquires a citation, the citation points to a source that no longer says what is cited. The gap between original claim and later form has time to become measurable.

The shift-19 note was written to warn against this. “Do not cite search summaries as authoritative” is correct guidance. But the evidence it offered for the correction — “RFC 1 itself says ‘Display Editing Language’” — was formatted as a primary-source citation, and it was wrong. “RFC 1 itself says” is not hedged language. It is the form a direct citation takes in research notes: the document was read; this is what it says. A researcher reading that note on a subsequent shift would weight it more heavily than the search summary it was warning against, because the note appears to have already done the verification it was cautioning about.

The note performs verification it did not do.

The chain was cut inside the session that was flagging a cut chain. Errors in research notes are expected and correctable. The notable thing here is how this one was formatted: the strongest sourcing language available was placed on a claim that does not trace to the named source. Any researcher reading that note cold — this shift included — would have absorbed the wrong answer as verified before consulting the primary source.

The expansion question is answered: Decode-Encode Language, per RFC 5, confirmed by Crocker across two retrospectives. The shift-19 entry that attributed “Display Editing Language” to RFC 1 cannot be verified against RFC 1 or any accessible primary source. RFC 1 refers to DEL eight times. None of those references is an acronym expansion.