Can a Finding Be Traced to Its Bytes? Lineage Coverage of a Phone-Forensic Reconstruction

1 Introduction

A forensic report states findings: a screen lock was set, automatic time was off, two accounts were signed in. A reader who has to rely on one of them asks the same question each time: where in the extraction does this come from, and does it still say that? The answer is the finding’s lineage. This report defines it for findings that a tool derives from a phone extraction, defines a coverage metric over it, and measures the metric on the output of a reference reconstruction.

A motivating example. Take a synthetic Android phone and three findings from a tool that reads its settings and account stores. The first says that automatic time is off. The second says that one Google account and three accounts in all are signed in. The third says that no hotspot setting is stored. All three are plain sentences, and the lineage of each is different (Table 1; the checker is described in Section 4). The first resolves: the record names a settings file, its digest, the setting and the value, and all four are found. The second cites the first of two account stores. That store holds no account; the larger count comes from the second store, which the record does not mention, so a reader who opens the cited file cannot reproduce the finding. The third is a finding of absence and records no store and no key, so a reader cannot tell whether the setting was absent from a store that was read or whether no store was searched. After the record cites both stores and names the probe, all three resolve.

The problem. Reports that give a finding with no checkable path to its source invite two errors. A reader may trust a finding whose source does not say what the finding says, and a reader may distrust a sound finding because no path is shown. The need for provenance is stated in the standards of the field [1], [2] and in recent models of analysis tools, which list improved artifact provenance as a direction [3]. What is missing is a measure: for the findings a tool produces, how many have a path that can be followed to the member, the digest, the locator and the value, and where do the others break? Without a measure, provenance remains a feature that a tool has or does not have.

Relation to our earlier reports. LAB-TR-0019 [4] describes a reference reconstruction that records for each established value its source, key path, content hash and method, and a digest over the sources a run read; it measured whether the reported values equal the stored values. LAB-TR-0020 [5] describes the provenance rules of a rule engine, which bind a run to a digest-verified rule pack. Neither asks whether a finding can be traced back, as a property of the report. LAB-TR-0034 [6] asks what an empty result licenses a reader to conclude; the present report asks what record would let a reader check that the search was made. The reference reconstruction of LAB-TR-0019 is the object of the measurement here; this report adds the lineage model, the metric, a resolver and its tests, and the measurement of the stored outputs against the extractions.

Scope. The measurement concerns one reference implementation at one source revision, applied to the Lab’s research corpus: 33 iOS and 14 Android full file system extractions and 7 Android bug reports. It measures whether the path from a finding to its source can be followed and replayed, not whether a finding is correct, the source complete, or the stored value what the device showed (Section 7). Results are given as shares of findings; counts of findings are withheld because the reference implementation is not public.

We ask four research questions.

• RQ1 (Model). Can the path from a finding to its bytes be defined so that every link is checkable and every failure has a name?
• RQ2 (Resolver). Does a resolver that checks the links detect injected breaks, and which breaks escape a given level?
• RQ3 (Coverage). What share of a real reconstruction’s findings has a complete chain, and where do the others break?
• RQ4 (Absence and fragility). Do findings of absence carry a lineage, how many findings fall with the loss of one member, and does a digest bind a finding to its extraction?

Contributions. This report makes four contributions.

• A lineage model for findings, with positive and negative (probe) chains, five checked levels and a sixth for container binding, nine named breaks, and a mapping to W3C PROV and CASE (Section 3).
• Lineage coverage, a metric defined on the levels, and a resolver that computes it, with its code and synthetic data released as an artifact (Sections 3.3 and 4).
• A test of the resolver by thirteen kinds of injected break on synthetic devices, with the limit that no check on the finding alone can detect a consistent rewrite (Section 5.1).
• A measurement of lineage coverage on the findings that a reference reconstruction made on 53 phones, with the breaks classified (Sections 5.2 to 5.6).

2 Background and Related Work

2.1 Provenance standards and ontologies

The W3C PROV family models provenance as entities, activities and agents, linked by generation, usage, derivation and attribution [1], [7]. PROV states constraints on these relations, such as the uniqueness and ordering of events [8]; in these three documents we found no construct for a statement that something did not occur. CASE describes cyber-investigations on top of the Unified Cyber Ontology [9]: its investigation ontology has provenance records and investigative actions, and re-implements the PROV derivation and informed-by properties [2]. UCO has hash objects, archive and file facets, and, for SQLite, a facet with table name, column name, row index and row condition [10]. A NIST implementation maps CASE graphs to PROV-O and ships a checker that reports chains of derivation that do not link back to the initial evidence submission [11]; its checks are structural and compare no digest and no value. Presentations on CASE state the aims of maintaining provenance and of testing tool results [12], and describe a provenance review of a dataset that found discrepancies such as a missing hash [13].

2.2 Provenance in forensic tools and interchange formats

DEX records the tools and transformations from raw acquired data to a result, gives every object a digest and a parent reference by digest, and lets a third party reproduce a result and compare two records; its evaluation compared eight tool chains for image metadata [14]. DFXML records byte runs, hash digests and the program and build environment that produced a result, so that a result can be regenerated [15]. An automated timeline approach keeps each high-level event linked to the low-level events and raw data it was inferred from [16] (abstract only). Good and Peterson rebuild the history of a file from existing artifacts [17] (abstract only). An abstract model of analysis tools, with standardised intermediate output demonstrated in CASE, names improved artifact provenance as a benefit and a direction, and uses the error classes of ASTM E3016-18, among them incompleteness, misinterpretation and inaccuracy by existence, alteration, association and corruption [3]. Validation frameworks ask that tool results can be traced and that errors are stated [18], [19] (neither read in full).

2.3 Data provenance in databases

Database research separates why provenance, the source data that influenced a result, from where provenance, the location a value was copied from [20], and adds how provenance as semiring annotations [21], [22]. The locator of an assertion in our model is where-provenance; a derivation from several assertions is why-provenance. Provenance of missing answers asks why an expected tuple is absent from a result [23], [24]; a probe in our model records a search and its outcome and does not explain a missing tuple.

2.4 Grounding of reports, traceability and supply chains

Khatiwala, Addai and Xu assign each artifact an identifier built from a hash of device, path and database name plus the table name and a row line number, and report a chain-of-custody adherence of 100% on one image [25] (the first author of the present report is a co-author). Adherence there means that the identifier is present; it does not test that the member exists, that its digest matches or that a locator reproduces the value. Das and others check 612 claims of language-model-drafted Android reports against human-reviewed reference findings, and report grounding and citation-validity rates [26]; their subject is report text, not tool findings, and their checks are by review. Requirements traceability measures the links between artifacts of software development [27], [28]. In the software supply chain, signed link metadata and build provenance with digests of resolved dependencies make a build checkable [29], [30].

Position of this work. Digest-based lineage of results is established in DEX and DFXML, the mapping of investigations to PROV in CASE and its PROV implementation, and where- and why-provenance in databases. We do not claim lineage or the mapping as new. We found no work that (1) defines a coverage metric for the share of a tool’s findings whose chain resolves to an existing member, an unchanged digest and a locator that reproduces the value; (2) gives findings of absence a recorded probe as their lineage; (3) reports resolvability measured on a tool’s own output over many extractions; or (4) tests a resolver by injected breaks. The search covered the arXiv, Zenodo and Crossref interfaces (OpenAlex and Semantic Scholar rate-limited, dblp blocked) and web search of the ACM, DFRWS and ScienceDirect domains on 29 October 2026; the private notes log the queries. Absence of a hit is not proof that no such work exists.

3 The Lineage Model

This section defines the objects of a lineage, the levels at which a chain can be checked, the lineage-coverage metric, the breaks, and the chain for findings of absence. Figure 1 shows the chain.

3.1 Objects

An extraction is a container X that maps member paths to byte strings; the digest d(m) of a member is its SHA-256. A locator ℓ identifies a position inside a member: a key path in a property list or a settings file, a table and a condition in a SQLite database, a line of a text, or a directory prefix. An assertion is a tuple (p, h, ℓ, v, r): a member path p, the digest h the tool recorded, a locator, the value v the tool read, and optionally the raw input r from which v was derived. A finding is (c, w, k, A): a claim c, the value w reported, a derivation class k and a non-empty set A of assertions. The classes are verbatim (w is the value read), interpreted (w is a function of the raw input), aggregate (w combines values of several members), default-from-absence (w is a documented default, taken because the key is absent), presence and structural (w follows from the layout of the container and no member has a digest). A finding of absence states that no value was established; it cites a probe (p, ℓ, o): a store searched, the locator looked for and the outcome o, either “store absent” or “key absent”.

3.2 Levels

A finding holds through level k if every assertion of it passes the checks up to k.

• L0, declared. The finding cites at least one assertion with a member path and a locator, or, for absence, a probe.
• L1, member found. Each cited path resolves to a member of X. A path may match several members (copies in a second file system root, a backup tree, or names that differ in letter case); the digest of L2 then decides which copy was read.
• L2, digest. The recorded digest equals the digest of a member that matches the path. If several members match and the digest identifies one that a reader taking the first match would not read, the finding is flagged ambiguous.
• L3, locator. The locator resolves inside the member (the key, the row, the line or the directory exists). For default-from-absence it holds when the key is absent.
• L4, replay. The member at the locator gives the reported value (verbatim), the recorded raw input (interpreted), or, when the value is recomputed from the container by an independent function, the same value (aggregate). A structural finding, whose value follows from the layout of the container, has no member to digest; it holds through L1 once the directory is found and stops at L2 with B9. All members the recomputation needs must be cited.
• L5, container binding. A digest of the container, or of a manifest of member digests, was recorded outside the finding and equals the digest of X.

3.3 Lineage coverage

For a set F of findings and an extraction X, the lineage coverage LC_k is the share of findings in F that hold through level k. By construction LC₀ ≥ LC₁ ≥ … ≥ LC₄. We report LC over all findings and over positive findings (those that state a value), because findings of absence enter the metric through their probe or not at all. A finding that breaks at level j counts at every level below j and at none from j; coverage at L4 is the share of findings with no break.

3.4 Breaks

A finding that fails to hold through some level has a first break, named by the link that failed (Table 3). The classes describe the chain, not the correctness of the value; the error classes of ASTM E3016-18, as quoted in [3], classify errors in results, and a break is a place where such an error would be hard to find.

A tenth label, U, is not a break but a limit of the checker: the record has a raw input but the checker has no replay for that store. It is reported separately so that a gap in the checker is not counted as a defect of the tool.

3.5 Findings of absence

A finding of absence has no member to cite: what it needs to record is what was looked for. The probe (p, ℓ, o) is resolved like an assertion. If the outcome is “store absent”, no member matches p (L1 holds when none is found). If it is “key absent”, a member matches, the digest identifies it, and the locator does not resolve (L3 holds when the key is missing); re-running the probe gives the same outcome (L4). A probe that finds the key refutes the finding (B8). This is the negative counterpart of where-provenance. We found no construct for it in PROV [1], [7], [8], nor in CASE and UCO (Table 4).

3.6 Mapping to PROV and CASE

Table 4 maps the model to PROV-O and to CASE and UCO as we read them. The mapping is a use of the standards and not a new one; we have not validated the generated graphs against the SHACL shapes of the CASE tooling. The artifact includes a small PROV-O export (to_prov_turtle).

3.7 Two limits

Proposition 1 (consistent rewrite). Suppose a party can change a member of X and, in the lineage record, the digest, the value read, the raw input and the finding value of every assertion and finding that depends on it. Then the changed pair (record, container) passes every check of L0 to L4 that the original passed. Proof. Each check is a function of the record and the container alone, and the changed pair is a valid pair for the changed container. ▫ Only information outside the finding, such as a digest of the container recorded earlier (L5), can tell the two apart; a party who can also change that digest defeats L5 as well. The proposition is elementary, but it states what the five checked levels cannot do, and Section 5.1 measures it.

Proposition 2 (path-only lineage is ambiguous). If two members of X match a cited path and differ in content, a lineage that records the path and the locator alone does not determine which was read, whereas the digest does. Proof. The path is a suffix match for both, and the locator resolves in both or in one of them. ▫ The case is not rare in practice (Section 5.3).

4 Resolver and Evaluation Design

4.1 The resolver

The resolver is a small program (about 300 lines of Python, standard library only) that takes a lineage file and a container directory. It finds the members that match each cited path (a path is a suffix match), checks the digest against each, resolves the locator in the member, and replays the value. Locator types are XML setting by name, key path in a property list or a JSON document, key in a property file, bracketed property text, line of a text, a SQLite cell or table, and a directory prefix. Replay of interpreted and aggregate derivations uses a function registered for the derivation by the code that produced the finding; the resolver reports B7 when none exists. It returns, for each finding, the highest level reached and the first break, and computes LC₀ to LC₄. A second function reports ambiguity when a path matches several members of different content.

4.2 Injected breaks on synthetic devices

A generator writes 60 synthetic containers (settings files, a SQLite lock store, a property file, two account stores, a property list, a text report and a directory layout) with seeded variation, including identical files across devices of one model group and a stale second copy of the settings file on some devices. A toy reconstruction, written for the study, derives 763 findings from them and records their lineage. With every contributor cited and a probe recorded, 711 of them hold through L4 and the 52 structural findings stop at B9. Thirteen injections then change the record or the container in memory and ask whether the resolver reports a break on the changed finding (Table 5): the member path, the digest, the locator or the value changed in the record; a member replaced by another device’s member; the cited value altered in the member with the digest corrected; a consistent rewrite; a removed member; a dropped contributor; a second copy; an altered raw input; a key written after an absence finding; and a probe removed. Only findings that resolved without a break before the injection are counted. The synthetic tables show the behaviour of the resolver, not the behaviour of any real tool.

4.3 The corpus run

Reference implementation. The reference reconstruction is the one of LAB-TR-0019 at the same source revision (commit 537ad858) [4]. For each platform it reads a fixed set of stores of an extraction or bug report and, for each fact it can establish, writes a record with a state, the value, and for each qualified observation the source path, the key path inside the source, the SHA-256 of the source member as staged, and the way the value was obtained (direct, interpreted, inferred) with a small structure of raw inputs. A fact it cannot establish ends in a record with a state and a reason and no source. A run also records one digest over the relative paths and content hashes of the sources it read, not over the extraction. We call a record with at least one qualified observation a positive finding and a record without one a finding of absence; the records marked as conflicting (under 2% of findings), in which qualified copies disagreed, are positive findings with several assertions. The stored outputs of the run of 28 October 2026 for LAB-TR-0019 were used unchanged; no reconstruction was repeated.

Frame. The frame is the 54 evidence items of LAB-TR-0029 [31]: 33 iPhone and 14 Android full file system extractions and 7 Android bug reports. Two extractions of one iPhone count once. One iPhone extraction ended without a run because the reconstruction needs the operating-system version and none could be determined, so 53 items yielded findings: 32 iPhones, 14 Android phones and 7 bug reports. The device counts rest on hash comparisons of device identifiers recorded in the Lab’s private notes.

Replay. For each assertion the resolver read the extraction’s central directory, took the members that match the cited path, hashed them, and read the locator with readers written for this study from the stored formats: settings files in text and binary XML (the binary-XML decoder is the one of the second reader of LAB-TR-0019), property lists, SQLite databases opened read-only from scratch copies, property text and the sections of a bug report. The levels were evaluated as in Section 3.2. Verbatim findings are replayed by comparing the value; interpreted findings by comparing the recorded raw input with what the member holds; one aggregate by recomputing it from the cited member; default-from-absence findings by checking that the key is absent; structural findings by checking that the directory exists. The replay of bug-report service dumps was not built; those findings are reported as U. For findings of absence the probe was reconstructed afterwards: for each fact, the stores and keys that positive findings of other devices of the same platform class cite were looked up in the extraction. Where no store is present the outcome is “store absent”; where a store is present and no candidate key is, “key absent”; where a key is present the finding is refuted. Where no other device established the fact, no probe is known. The run took about three minutes on one workstation, items processed one at a time.

5 Results

5.1 Injected breaks

Every single-link change to the record is detected by the level that checks that link, with one class of exception: on default-from-absence findings a changed locator still resolves, because the new key is also absent, and a changed value is compared with nothing, 21 findings each. A member replaced by another device’s member is detected unless the two files are identical, which happened for 103 of 624 swaps (17%): a digest alone cannot tell identical members of two devices apart. Altering the cited value and correcting the digest is detected only at L4, by the replay. A consistent rewrite of member, digest and value escapes all five levels (0 of 432) and is detected on all 432 when a container digest recorded outside the finding is checked, as Proposition 1 predicts. Two coverage effects follow from the way the toy reconstruction records lineage. Without probes, 10% of its findings break at B1; citing only the first of two contributors lowers LC₄ from 93.2% (the structural findings stop at B9) to 86.4%; both together give 76.1% (data/baseline_modes.json).

5.2 Coverage of the reference reconstruction

The reference reconstruction made findings on 53 items. 78% of them state a value (positive findings) and 22% state that no value was established (findings of absence); the share of absence findings is 31% on iPhones, 6% on Android phones and 18% on bug reports. 39% of the positive findings cite two or more assertions, up to 7, always on different members. Table 6 gives lineage coverage over positive findings and over all findings, and Figure 2 the composition of the breaks.

99% of the positive findings resolve to a member, 98% to a matching digest and 98% to a locator; 90.5% pass the replay. Over all findings the complete chain exists for 70%. By source the share of all findings with a complete chain is 68% on iPhones, 78% on Android phones and 64% on bug reports; over positive findings it is 98.6%, 82.7% and 77.3%. No device had a complete chain for all its findings; the share per device ranged from 50% to 88%, with a median of 69%. Findings that the checker cannot replay (the U findings of Section 5.3: 2% of all findings, 15% of the findings of bug reports) count as not complete. Left out of the denominator, the complete chain is 72% of the other findings and 93% of the other positive findings; for bug reports, 75% and 94%.

5.3 What breaks

No recorded digest failed and no value differed from its member: the checker found no B3, B4 or B5. All breaks are links that are missing or that cannot be followed (Table 7).

Absence without a probe (B1, 22% of findings). Every finding of absence is a record with a state and a reason and no store and no key (Section 5.5).

A contributor the lineage does not cite (B6, 2% of findings, 7% of Android findings). On 12 Android phones, findings about one setting depend on a file whose presence the record notes but which it does not cite. The cited member does not support these findings alone, and the member that does is not named. A second kind of uncited contributor is built into the reference: an aggregate over two stores of one kind that cites one of them. On all 14 Android phones the cited store alone reproduced the aggregate, so the break was not observed; the synthetic case (Table 1) shows that it would not have been seen.

Interpretation without a raw input (B7, 2%) and replay not built (U, 2%). B7 findings state a label with no recorded input from which the label could be checked: 5.5% of Android findings and 3.7% of bug-report findings. The U findings are service dumps of bug reports, whose records do carry raw counts; the limit is the checker’s.

Structure (B9, 1%). Some Android findings (4% of them) follow from the layout of the container and have no member to digest. They can be checked for the directory, not hashed.

An ambiguous copy (B2a, 8). On eight iPhones the cited path matched several members that differ in letter case only, and the recorded digest identified the lower-case-named copy, which a first match on name length would not read. This is the case LAB-TR-0019 found (a store under two names of which only one held the key) [4]: the digest alone shows which copy the tool read, and on six of the eight another copy held the key. In total about 1% of the assertions matched more than one member.

5.4 By derivation class

The classes that state a stored value, verbatim or presence, never broke. The weakest chains are those of derived and negative findings: they carry the interpretation that a reader most needs to check. A tool that records the raw input of every interpretation, the probe of every absence and every contributor of every aggregate would raise the complete chain from 70% to about 99%; only the structural findings (1%) have no member to hash. Of the complete chains, 76% replay the reported value and 24% replay the recorded raw input of an interpretation; for these the mapping from input to label is not tested (Section 7).

5.5 Findings of absence

None of the findings of absence names a store or a key. Reconstructing the probe from the extraction and from what other devices of the class established (Table 9) gives an outcome for 81% of them: “store absent” where the extraction holds no candidate store, “key absent” where a candidate store is present and holds no candidate key. No finding was refuted. For the other 19% no other device of the platform class established the fact, so no candidate store is known; most are on bug reports, which hold few of the stores.

5.6 Concentration and binding

A device’s findings rest on few members: the median is 7 cited members per device, and 61% of the positive findings cite exactly one member. The most-cited member supports a median 68% of a device’s positive findings (Figure 3): 72% on iPhones, 28% on Android phones (at most 32%) and 57% on bug reports (at most 62%); on 39 of 53 devices it is half or more, and on three iPhones every finding cites the same member. The loss or alteration of that one member would break that share of a phone’s findings at L1 or L2 at once.

A digest binds a finding to a file, not to a phone. 3.1% of the iPhone assertions cite a member whose digest also appears in the lineage of another iPhone (five digests are shared); none of the Android and bug-report assertions does. A finding from a default configuration file can therefore carry a lineage that is valid for a second phone; only a digest of the container (L5) ties it to its extraction. The outputs of the run record no such digest: the run digest covers the sources read, not the extraction.

6 Discussion

What a reader should ask for. The breaks suggest five questions. Does every finding name the member, its digest and the position of the value? Does every interpretation keep its raw input? Does every aggregate cite every member it used? Does every statement that nothing was found say what was searched? Is there a digest of the whole extraction that the findings can be tied to? The first question was answered yes by this reference for all positive findings that cite a member; the others are where the 70% falls short of 100%.

Design consequences. The cheapest repairs record what the tool already knew: the raw input beside the label, the second store beside the first, the store and key searched beside an absence. They change the record, not the analysis. The probe in particular costs a path and a key per absence and turns an unverifiable negative into one that a reader can re-run. The container digest is also cheap; its value is stated by Proposition 1 and by the share of iPhone assertions whose digest also occurs on another phone.

Relation to the standards. CASE and its PROV implementation can hold the chain from finding to member and digest; they need a locator type for key paths, lines and archive members, a derivation class, and a construct for a recorded search. The check in the PROV implementation is structural; the levels L2 to L4 add content.

Relation to earlier reports. LAB-TR-0019 measured whether reported values equal stored values and found no difference against a separately implemented extractor; this measurement finds the same on a different basis (no value mismatch at replay) and adds what that comparison could not show, that a correct value may lack a path to its source. LAB-TR-0034 and LAB-TR-0029 ask what an empty result licenses and whether a phone can answer a question; the probe makes the first check possible for a tool’s own absence findings [31], [6].

7 Threats to Validity and Limitations

Internal. The reference reconstruction, the second reader of LAB-TR-0019 and the readers of this study were written by the same team and read the same bytes. A misreading of a format that all of them share would not appear as a break. The digest check compares the digest the tool recorded with the digest of the member now in the container: it shows that the cited bytes are the bytes that were staged, not that the tool derived its value from them. The replay supplies that link only as far as a second reader gets the recorded value from the cited bytes, and for some presence findings it tests that a store or a type exists rather than a value. The replay of interpreted findings compares the recorded raw input with the member; it does not test the mapping from input to label, which a second implementation would test (LAB-TR-0019). The levels and break classes were defined by the authors before the corpus run, but the classification of derivation classes and the treatment of two cases (the uncited contributor, the case-variant copies) were made after the first results and are stated here as such. All numbers of the report come from one run of the checker.

Construct. Lineage coverage measures whether a path can be followed and replayed. It is not accuracy, completeness or weight. The probe reconstructed for findings of absence is learned from other devices and so tests consistency, not the tool’s own search. Treating a recorded path as a suffix match is a choice; a tool that records the full in-container path would have fewer ambiguous cases. The U findings count as not complete, which lowers coverage; Section 5.2 gives the figures without them.

External. One reference implementation, one catalogue of facts, one source revision, and 53 devices from one research corpus (most iPhones run iOS 26, 12 of 14 Android phones are Samsung). The shares describe this implementation; another tool would differ, and its breaks may be of other kinds. The findings are settings and presence facts; a tool that emits event timelines has records of another shape (a line number in a log, a row identifier in a database). The artifact’s locator types cover these, but they were not measured on real data.

Limitations. The extraction was assumed unchanged since the run of 28 October; the matching digests of every cited member that resolved support that assumption but do not prove it for members the run did not cite. The synthetic injections test the resolver on one toy reconstruction. The figure of three minutes is the time of the resolver on stored output, not the cost of building lineage into a tool. We did not compare tools.

8 Conclusion

A finding is as good as the path from it to its bytes. We defined that path as a lineage with five checked levels and a sixth that needs a record outside the finding, named nine ways it breaks, gave absence findings a probe in place of a member, and defined lineage coverage as the share of findings whose chain holds. On the findings of a reference reconstruction run on 53 phones the chain was complete for 70% and no recorded digest or value failed; the missing links were the probes of the findings of absence, the raw inputs of interpretations, contributors that were read but not cited, and a digest of the extraction. A consistent rewrite of a member and its record is beyond any check on the finding alone. We suggest that tools report their lineage coverage beside their findings, and that readers ask for it.