What should survive?

What should survive?

Consider a researcher asking how an established application carried familiar interfaces through technical change. A screenshot can preserve appearance. An interface definition can preserve structure. A set of related files can reveal how a window was assembled. A working installation might expose behavior under specified conditions. Each preserves something useful, yet the research questions differ. Treating these records as interchangeable would hide precisely the development decisions a history of maintenance should investigate.

This collection is catalogued as EverQuest: The Outer Brood, Release Client #630 (Sep 11 2025). The current reference inventory records 15,476 files and 15,870,202,692 uncompressed bytes. Its embedded executable date corroborates a date string, while publisher origin, the catalogue number, and release coherence need separate evidence. The research object is therefore a specifically identified copy, with a bounded claim about its identity.

The studies already published supply observations of that copy and tests of selected methods. This paper develops the next questions they make possible. Its project designs are proposals; their measurements and participant outcomes have not occurred.

An evidence model with six layers

A useful preservation plan separates layers before deciding whether an observation is adequate. This analytical model is proposed here to make missing evidence visible. It does not claim that the collection has recovered every layer.

For example, a locally represented button supplies evidence about an available interface description. Its presence alone cannot show which account could use it, which server rule answered its request, or what a community understood it to mean. Conversely, an oral account of a remembered interface does not identify the bytes that produced it. Combining sources can strengthen an explanation while preserving these differences.

The publisher itself describes software, an account, hardware, and connectivity as separate conditions of play. That supports distinguishing a retained client from access to a hosted service. Publisher agreement, §1.3.1 ↗

The exact version as an experimental variable

Version identification matters because historical comparisons need a stable object. If one researcher counts an older interface and another inspects an updated installation, disagreement could reflect different materials rather than a defective method. Recording the archive digest, selected member digests, tool version, and observation date helps separate those possibilities. It also enables a correction to target the affected measurements instead of discrediting an entire collection.

A useful citation should state whether it identifies a container, a member, or an interpretation. Repacking unchanged members can alter a ZIP digest. Our 3 synthetic comparisons examine that distinction using original authored XML, including changed-payload and missing-member controls. All recorded predicted outcomes were observed. They validate specific measurement expectations, without authenticating any commercial release.

The scientific value lies in controlling uncertainty: a later investigator can distinguish a changed input from a changed explanation. Retaining exact bytes helps support that discipline, but an exact-copy label cannot supply missing acquisition history or explain every file’s place in a release.

What the completed studies contribute

The include study reaches 180 files totaling 3,982,412 uncompressed bytes and records 175 include occurrences across its selected roots. Shared files appear once in the union; occurrences and unique targets answer different questions. The inventory-window root reaches 6 files totaling 159,775 bytes. These are measurements of a scoped static representation.

That representation contributes to maintenance history by exposing boundaries between entry points and included components. A historian can ask where a revision would require coordinated changes, which windows share material, and whether a later package reorganizes those boundaries. These questions are more specific than saying an interface became modern. They can produce comparable, revisable descriptions of development choices.

For human–computer interaction, the category studies connect names and organization to possible tasks. A category can remain recognizable while documented membership rules change. The historical question concerns how designers organized choices; a usability question concerns how people performed. The former can be investigated through definitions and dated records. The latter needs observed users and an appropriate study design.

The graph and published counts also permit teaching without a complete installation. A student can identify shared targets, question a resolution rule, or reproduce a graph mask from the data. Inspecting original member contents would answer a different question.

Proposed investigation: release coherence

Question: does the reference resemble a coherent installation, or does comparison reveal components associated with different acquisition histories? Begin with independently and lawfully obtained comparison materials whose origins can be documented. Collect local member manifests containing relative names, lengths, and digests. Compare manifests before exchanging payloads, since many agreement and difference questions need only those records.

Record candidate release identifiers as verified, reported, or inferred. The independent variable is the comparison source; measured outcomes are matched, missing, added, and changed members within declared scopes. Packaging differences should be analyzed separately from member differences. Preserve the original manifest when normalizing case or path separators, and disclose the normalization rules.

Separate known-change controls should alter one authored fixture member and omit another, demonstrating detection of each condition. A repackaging invariance control should compare identical fixture contents packaged differently. A real difference becomes a finding only after checking the relevant scope and repeatability. Even broad agreement would not authenticate publisher origin unless a reliable comparison source supports that conclusion. No independent comparison installation has been established here.

Proposed investigation: interface maintenance

Question: how do component boundaries change between identified versions? Apply the same include parser to comparable roots in two lawfully held copies. Declare which reference forms it recognizes, which it ignores, and how it treats ambiguity. Compare reachable members, repeated references, shared targets, unresolved paths, and bytes read. Keep each version’s raw result alongside any comparative table.

A useful outcome would be a documented change such as an entry gaining a shared fragment or a reference moving between files. That would support a narrow account of representation and reuse. It would not establish that maintenance became cheaper or the interface became faster. Those interpretations would need additional evidence.

Controls should include a known omitted target, duplicate candidates, a case-only match, and a reference outside the declared scope. The decision criterion is whether the method classifies these conditions as specified and gives stable results on unchanged inputs. If a version uses an unmodeled reference form, report reduced comparability. A smaller matched subset may suffice for this investigation; its sufficiency ends at the declared static questions.

Proposed investigation: runtime selection

Question: which of several packaged interface representations is actually selected in a specified, authorized environment? This requires an execution study; none is reported by the static record. Before any experiment, establish the relevant rights, an isolated test environment, a reproducible installation, and a task that can be observed without affecting other users or an operating service.

Record the client identity, operating environment, display settings, permitted account conditions if applicable, and the exact action being observed. Change one declared variable at a time. Separate a successful launch, an observed window, and a completed task into distinct outcomes. An account refusal or an unavailable service is evidence of an environmental condition, rather than proof that an interface definition is invalid.

A suitable baseline repeats the same task with unchanged inputs. An observation-method control uses a harmless authored test interface in an authorized harness, where available, to test the observation method. No successful harness is claimed here. A broader installation could be needed for execution, but its required resources must be investigated; a static include set cannot establish functional completeness or justify every packaged asset.

Proposed investigation: preservation adequacy

Question: can a retained record support the research task it was intended to preserve? Define success before testing. For a composition study, success might mean regenerating the same census. For interface history, it might mean recovering the same scoped relationships and explaining their limitations. For behavior, it would require a specified task in a documented environment. These are different preservation targets.

Use authored fixtures to test accidental change, missing members, unreadable containers, and recovery from a separate known-good fixture copy. Record the expected outcome and the actual result. A checksum comparison tests byte identity; a recovery test asks whether a usable object can be obtained after a defined failure. Neither alone demonstrates that a historical online experience has survived.

For any later real custody arrangement, document who actually retains which copy, the transfer basis, verification schedule, recovery responsibilities, and known dependencies. This collection does not claim such collaborators. Independent storage can reduce one kind of loss while leaving provenance, legal authority, and environmental dependence unresolved. A plan becomes evidence when its checks and recovery attempts are performed and recorded.

Matching inputs to questions

Research should explain what an input enables. Published aggregate data supports inspection of reported patterns. A manifest supports comparison of member identities. Selected definitions support source-level examination of the represented interface. Related components support the scoped relationship study. An execution experiment may need a suitable installation and dependencies. Each request for broader material should identify the uncertainty narrower inputs leave unresolved.

Recomputing a complete ZIP digest requires its bytes, but defining a whole-file task does not demonstrate why every investigation needs the whole package. Likewise, retaining material for unforeseen questions has preservation value without establishing that unrestricted distribution is necessary. These distinctions improve research design: they make an unsupported assumption available for correction rather than hiding it inside an expansive claim of necessity.

Independent participation and useful contributions

Independent developers, historians, students, and preservation volunteers are welcome. This collection keeps its existing general access to ZIP and torrent downloads. Researchers are asked to make a good-faith effort to contribute methods, findings, corrections, or unsuccessful attempts after their work, when reasonably possible. Careful methods and useful corrections matter, including negative findings.

A useful contribution states the question, input identifiers, method, observations, uncertainty, and a repeatable check. An unsuccessful attempt can identify a missing dependency or a method’s boundary. Keep credentials, account details, personal configurations, and participant information out of public research outputs. Community testimony needs an appropriate consent process; no participant study is claimed by this paper.

No contribution submission channel is currently published. A prepared report remains with its researcher until they choose an appropriate way to share it. Existing downloads do not depend on submitting a report.

Availability, service context, and rights

A public-page availability review can establish what the inspected channels described on its review date. It cannot establish every historical branch, account entitlement, or support option. A retained client also does not supply the server’s persistent world or establish current service compatibility. Whether access substitutes for an authorized product or affects a market remains a separate evidentiary question.

U.S. fair use considers the actual research use; archive exceptions have conditions. An educational purpose alone establishes no blanket right to distribute complete software. Fair use and archival provisions ↗

Game-preservation circumvention rules also contain eligibility and premises conditions; they provide no general distribution license. Current preservation exemption ↗

The contribution of this work is a more inspectable historical record: named questions, identified inputs, measured relationships, and tests that expose uncertainty. Study data and methods ↗ Reference downloads ↗