A.1 Exact computational specification
The numerical graph example uses an ordered node set A, B, C, D. Its directed edges are A to B, A to C, B to C, C to A, and D to C. No edges are inferred or added. The adjacency matrix has rows (0, 1, 1, 0), (0, 0, 1, 0), (1, 0, 0, 0), and (0, 0, 1, 0). The transition matrix divides each row by its outdegree, so the first row becomes (0, 0.5, 0.5, 0), while the other rows remain unchanged.
With damping 0.85 and four equally likely teleportation destinations, each node receives a teleportation contribution of 0.0375. The linear system is solved without rounding the input fractions. The final decimal values in Chapter 7 are rounded only for presentation. Wolfram's LinearSolve verified the stationary equation, and its PageRank documentation provides the interpretation of damping and personalization [47, 48]. The report's build process checks the same solution numerically using the explicitly defined matrix, avoiding ambiguity about a software library's default graph orientation.
The square of the adjacency matrix has rows (1, 0, 1, 0), (1, 0, 0, 0), (0, 1, 1, 0), and (1, 0, 0, 0). These rows count two step walks. They are not a normalized probability matrix. A transition matrix squared would instead describe two step transition probabilities for the specified random walk without teleportation. Distinguishing the two matrices prevents a common mistake in which a walk count is presented as a probability merely because both calculations use matrix multiplication.
The undirected Jaccard example intentionally uses a different projection from PageRank. Arrow directions are removed, yielding the unique edges AB, AC, BC, and CD. Neighbor overlap is then computed on that undirected projection. The report explicitly changes the projection because comparing an undirected similarity score with a directed centrality score without explaining the change would obscure their meanings. Neither result is interpreted as a statistical estimate of a real world relationship.
A.2 Evidence selection and source status
The review selected sources to cover formal representation, extraction, storage, graph algorithms, reasoning, and language model integration. Foundational standards and primary research papers anchor specific technical claims. Broad surveys were used to orient the taxonomy and locate representative methods. Recent architecture papers were included when they illustrated a materially different approach, while numerical performance comparisons were omitted where this report did not reproduce or closely audit the experimental setup.
Consensus search results were followed by full record retrieval before citation. SciSpace identified additional graph retrieval and agent papers, and technical descriptions were checked against accessible original paper records. Wolfram supplied computational verification for the synthetic example. These tools supported discovery and checking; they are not substitutes for the cited publications. The bibliography distinguishes standards, published papers, preprints, and software documentation.
The date on a search index can refer to a preprint, an online publication, or a journal issue. Where versions differ, the reference identifies a usable publication record and may also link to an accessible preprint. A reader comparing results should consult the same version and experimental conditions. This report does not claim that its source list exhausts research available by the search date, and it does not rank methods as current state of the art.
A.3 A small design experiment for readers
A useful exercise is to represent the same fictional evaluation in two ways. First, create a direct edge from GraphLens to Dataset D labeled EVALUATED_ON. Second, create an Evaluation node linking the method, dataset version, metric, baseline, and source. Ask each model to answer which method had the higher score under a specified protocol. The direct edge is compact, but it lacks the context needed for the comparison unless that context is added elsewhere. The exercise reveals a modeling tradeoff through a concrete question.
Repeat the exercise after introducing a correction and a second evaluation. The better representation is the one that preserves both results and allows the affected context to change without rewriting unrelated history. RDF's introductory examples provide a useful starting point for expressing resources and statements, but the domain specific evaluation structure remains a design responsibility [51]. A property graph implementation should be tested against the same questions, so the comparison concerns preserved meaning rather than syntax preference.
A.4 Interpreting aggregate outcomes
Suppose a team evaluates two retrieval systems on 100 questions. System X answers 80 correctly and System Y answers 84 correctly. Those totals alone do not establish that Y is reliably better. The team needs to know which questions differ, whether the sample represents deployment, and whether both systems used the same evidence and budget. A paired analysis can use the per question outcomes because the systems were tested on the same items. Repeated questions derived from one document may also require grouping by source.
The same discipline applies to graph construction. A larger graph may contain more useful evidence, more duplicates, or more unsupported assertions. Counting nodes and edges cannot distinguish those outcomes. A meaningful experiment connects structural changes to task performance and review effort. For the Research Evidence Graph, a useful outcome is the proportion of answers with complete and correct supporting evidence, measured alongside the time required to maintain that quality. This turns graph development into a testable research and engineering process.