← Research & preservation

DEPENDENCY GRAPHS & PORTABILITY

When a reference becomes a dependency.

Graph topology, omission tests, and the limits of portability evidence.

EverQuest: The Outer Brood · Release Client #630 · Sep 11 2025

9 minute readUpdated October 15, 2026No account required

Original analysis and research design · Measurements refer to the identified reference; compare its digest with the current ZIP. No peer review or independent replication is claimed.

ORIGINAL DERIVED-DATA STUDY / METHOD 1.0

Abstract

This paper studies the topology of a published include-reference graph associated with the TOB Research Project’s historical client reference. A deterministic analysis of that public record finds 180 vertices, 175 matched reference occurrences, and 5 weakly connected components. The recognized graph is shallow and acyclic. A systematic omission calculation and a comparison of exact versus case-only annotations expose how representation choices affect its reported connectivity. These are new analyses of existing measurements, not new reads of the client or experiments on its execution.

The central finding concerns the interpretation of dependency evidence. A prominent entry vertex can dominate a static graph because the parser recognizes its reference vocabulary. Removing that vertex from the representation changes many recorded relationships without establishing a corresponding application failure. Similarly, a case-only annotation identifies a question for portability investigation without diagnosing a filesystem defect.

1. An object of study with two boundaries.

The underlying installation is catalogued as EverQuest: The Outer Brood, Release Client #630 (Sep 11 2025). Its reference ZIP contains 15,476 file entries. This paper’s direct input is much smaller in scope: the published ui-relationships.json record, derived from five selected interface roots and two recognized forms of literal inclusion. Its reference identifier is 6cb5e3b52c27391051ddfe5f0896d05d6e240a87ec442269fdbe7739ec9397ab.

There are therefore two boundaries to preserve. The first separates the installation from an online service and its history. The second separates the measured graph from the installation. The graph does not describe every file, executable dependency, image, style, script, or dynamic resource. Its analytical usefulness comes from making a declared relationship inspectable, rather than representing the entire application.

The original inspection examined XML Include text and HTML include-body file attributes in declared directory scopes. This analysis consumes its resulting nodes, endpoint classifications, member sizes, and root identifiers. It cannot rediscover a reference the original parser ignored or verify source markup against the record. Reproducibility here means repeating calculations on an identified public input.

2. A bounded and repeatable transformation.

The published Python method reads JSON only. It rejects inputs larger than 2,097,152 bytes, more than 512 nodes, more than 2,048 edge occurrences, or more than 32 declared roots. Invalid identifiers, duplicate vertices, invalid sizes, unknown edge classifications, and matched edges with undeclared endpoints are rejected. Recorded unmatched annotations are excluded from topology rather than converted into invented vertices.

Identifiers remain case-preserved, relative graph names. These validation rules protect the analysis boundary; they do not certify that every name is valid on every operating system. No archive is extracted, no client file is opened, and no game engine is contacted. The output inherits the source inspection date and reference digest instead of inventing a new acquisition event.

Sorting governs component records, neighbor traversal, root summaries, and ranking ties. Output has fixed field ordering and contains no current execution timestamp. The same declared graph yields the same serialized result even if input arrays are reordered. This makes a disagreement about a count easier to localize to an input, definition, or implementation difference.

3. Occurrences, neighbors, and components.

A directed occurrence points from a referring member to its matched target. Multiple occurrences could connect the same ordered pair. Consequently, the analysis retains both occurrence degrees and distinct-neighbor degrees. Here, 175 matched occurrences correspond to 175 unique directed pairs; 0 repeated pairs occur. Equality is a finding about this input, not a rule built into the method.

Weak connectivity asks which vertices can be connected if direction is ignored. It is useful for distinguishing separate islands of recorded reference relationships. It does not show that their resources are independent at runtime. An executable or an unmodeled shared style could connect islands through relationships absent from this vocabulary.

Weak components · component identifiers follow lexical order, not importance
ComponentVerticesFirst recorded identifier, shortened
1171EQUI.xml
21CastingWindow.html
31ClaimWindow.html
46InventoryWindow.html
51RespawnWnd.html

Only 2 vertices emit recognized references. The EQUI.xml entry and the inventory entry account for the observed outgoing structure. There are 3 vertices with no incoming or outgoing recognized edge. Calling them isolated describes their position in this graph; it does not make their corresponding windows self-sufficient.

4. Depth and cycles describe the model.

For each declared root, breadth-first traversal records the minimum number of matched edges required to reach a vertex. Root depth is zero. Minimum distance is deliberately different from maximum path length, load order, or processing time. The calculation remains defined when a graph contains cycles because each reached vertex receives its first, shortest distance.

Root-specific minimum-distance distributions · histogram entries are depth: vertex count
RootReached verticesMaximum shortest distanceDepth histogram
EQUI.xml17110: 1; 1: 170
CastingWindow.html100: 1
ClaimWindow.html100: 1
InventoryWindow.html610: 1; 1: 5
RespawnWnd.html100: 1

The maximum reported shortest distance is 1. In the recognized vocabulary, the broad XML entry names its targets directly, while the inventory entry directly names a smaller set. This does not establish that the whole interface has a flat architecture. Relationships between named definitions, styles, executable behavior, and server state are outside the model.

Strong-component analysis finds 180 components and 0 cyclic components. A multi-vertex strong component or a self-loop would count as a directed cycle. The resulting acyclic graph permits a topological ordering, but the published lexical tie policy is an analytical convention. It cannot recover an execution order from documents that did not record one.

5. Systematic single-vertex omission.

For every vertex, the method removes that identifier and its incident matched occurrences from the recorded graph. It recounts weak components and root reachability. “Additional unreachable vertices” excludes the removed vertex itself: it measures surviving identifiers no longer reachable from a declared root. If the root is removed, reachability from that absent root is defined as empty.

Two entry-vertex omissions · structural calculations only
Omitted identifierLost occurrencesAdditional root-unreachable verticesRemaining weak components
EQUI.xml170170174
InventoryWindow.html559

Across the remaining cases, 175 removals lose one recorded occurrence and 3 lose none. The large XML-entry effect reflects its fan-out: deleting its only recognized links leaves many targets disconnected in the representation. This is a property of a star-shaped subgraph, not evidence that those targets disappear from storage or become unusable.

No file was deleted from the installation. No window was rendered, no service failed, and no performance was measured. The ranking preserves every tie instead of selecting a supposedly decisive member. Omission counts can guide questions about documentation coverage; they should not be renamed failure probabilities, runtime criticality, or preservation value.

6. What a case-only annotation establishes.

The upstream record contains 174 exact and 1 case-only matched occurrences. Its case-only relation runs from uifiles/default/EQUI.xml to uifiles/default/EQUI_PvPLeaderboardWnd.xml. The original resolver recorded a unique case-folded candidate after exact matching did not identify one. The new analysis preserves that annotation; it does not repeat the lookup against archive contents.

The record retains the resolved target, not the original reference spelling. It therefore cannot show which letters differed in the source attribute. There are 0 groups of distinct recorded vertex names that collapse under case folding. The lack of such a group is different from the absence of a case-only reference: one concerns stored identifiers, the other concerns an earlier comparison.

Microsoft documents default case behavior alongside filesystem-specific exceptions. This supports treating a name-comparison policy as an explicit condition, rather than assuming one policy from the platform’s name. Microsoft: naming files and paths ↗

Its WSL guidance also describes directory-level case sensitivity and differences in mixed Windows/Linux workflows. Those are environment considerations for a future experiment, not observations about the client’s own resolver. Microsoft: case sensitivity ↗

7. A sensitivity comparison, not a portability verdict.

A second view filters the existing annotations to exact matches only. It retains 174 occurrences and yields 6 weak components. The XML root reaches 170 vertices rather than 171. The changed result is precisely bounded: 1 previously reached identifier leaves that root’s closure under this stricter recorded-edge policy.

This comparison does not mean that a case-sensitive installation would necessarily fail. An application could implement its own lookup, normalize a reference, select another representation, or take a path not modeled here. Conversely, a filesystem’s permissive matching would not validate all application-level assumptions. Resolving that uncertainty requires observing an appropriate resolver in a specified, lawful environment.

URI comparison supplies another reason to separate naming layers. RFC 3986 distinguishes case normalization for schemes and hosts from the treatment of other URI components. It does not instruct this game engine how to resolve its custom include vocabulary. RFC 3986 §6.2.2.1 ↗

The HTML Standard makes a document’s base URL relevant to relative URL resolution. That illustrates why a relative string cannot be interpreted without context; it does not establish browser-standard semantics for an engine-specific include element. HTML Standard: document base URLs ↗

8. Authored tests and ways the method can fail.

The accompanying tests use small authored graphs rather than client material. They cover branching acyclic paths, a directed cycle, a self-loop, isolated vertices, duplicate edge occurrences, downstream omission effects, case-fold collisions, excluded unmatched annotations, invalid endpoints, bounded sizes, and tied rankings. A direct shortcut in a branching graph checks that reported depth is the shortest distance rather than an arbitrary traversal depth.

A repeated edge checks that occurrence degree can differ from distinct-neighbor degree. A self-loop checks that deleting its vertex loses one occurrence, without double counting it as both incoming and outgoing. A chain checks the distinction between the removed member and surviving downstream vertices that lose a route. Reordered fixture arrays check deterministic output rather than merely repeating one convenient input order.

Passing these tests supports the stated arithmetic on these cases. It does not independently validate the original parser, prove that all relevant includes were captured, or certify portability. A future counterexample could expose a boundary condition the authored cases missed. The expected response is to preserve that graph, identify the affected metric, and correct the method and result together.

9. Research value and a falsifiable next step.

Topology provides a compact way to compare representations without equating file count with architectural complexity. A future version could retain the same root closure size while introducing intermediate include layers, shared targets, or cycles. The present measurements establish a baseline against which those different changes could be distinguished. No second client or later graph has been analyzed in this paper.

A useful next investigation would first compare public graphs or locally generated records under the same definitions. It would declare naming policy, matching classifications, root selection, and parser scope before attributing a difference to software evolution. If a resolver experiment becomes necessary, it should isolate one condition and record both successful and unsuccessful observations. These proposed experiments remain separate from the completed derived-data calculation.

All calculations here can be repeated using the public JSON, without downloading the client. A contribution can recalculate a metric, supply a small counterexample, challenge a definition, or report an unsuccessful replication. Describe sufficient inputs and uncertainty; do not attach credentials, personal configurations, or protected asset collections. No affiliation, advance contact, or application is required by this paper.

Evidence and method: derived graph analysis · original relationship record · analysis script. The analysis retains 6cb5e3b52c27391051ddfe5f0896d05d6e240a87ec442269fdbe7739ec9397ab as its reference identifier. Reference ZIP and torrent downloads ↗.

CONTINUE READING

Other studies in this collection.

How an interface holds together.Composition, classification, and changing rules in a dated client.Identifying a historical copy.Digests, chronology, control experiments, and an evidence register.What should survive?A client artifact, its surrounding service, and testable preservation goals.What a software census can tell us.File labels, byte concentration, diversity, and evidence-led preservation.Preserving how an interface can be used.Accessibility evidence, historical context, and a reproducible study protocol.

Project register · Contribution guide · ZIP and torrent