Attributing Interior Gaps in Phone Logs to Restarts, Log Rotation and Clock Steps

1 Introduction

A report that says “the phone was not unlocked between 22:00 and 07:30” is a statement about a store, not about a night. The store holds no interval for those hours. Whether that is because the phone was off, because the store was not writing, or because the user did nothing is the question this report studies. Gaps inside the span of a log are read as deletion by some examiners and are not noticed by others. Both readings skip the step in between: finding out why the records are missing.

A motivating example. Take a synthetic phone whose stores are read on 28 June. Its lock-state store holds a chain of intervals that tile the month except for three holes. Table 1 gives them, with the evidence that other stores of the same extraction provide. A shutdown record and a boot record bracket the first hole of two minutes: the device was off, and nothing can have happened on it. The second hole is 9.5 hours long, but the same kind of restart lasted 70 seconds: the device came back at 22:01 and the store wrote nothing until 07:30. The third hole has no evidence at all. Read as intervals of “no use”, the three holes say the same thing. Read with their causes, only the first does.

The problem. Phone stores differ in what they promise. A store of daily files promises one file per day on which its writer ran. A lock-state store promises intervals that tile the time the device runs. A log promises records in a ring that wraps. A hole breaks one of these promises, and the cause decides what the break means. Practitioners know the idea for server logs: gaps in the record numbers of a Windows event log are a lead for deletion, and a wrapped log is another explanation [1]. We found no measurement of how often phone logs have such holes, of what causes them, or of what the causes license.

Relation to our earlier reports. LAB-TR-0021 measured the edge of each store, the retention horizon between the oldest record and the acquisition [2]. LAB-TR-0034 gave absence claims a semantics in which a store observes the days between its oldest and newest record [3]; its hole test found day files missing but did not locate them or say why. LAB-TR-0022 measured clock anomalies [4], LAB-TR-0030 what gaps in row identifiers can and cannot prove [5], and LAB-TR-0029 whether a date-bound question can be answered at all [6]. The present report measures the interior of the stores that those reports treated as intervals, and what lies in it.

We ask four research questions.

• RQ1 (Definition). When is a gap in a phone store a hole, and for which stores can that be decided without guessing a rate?
• RQ2 (Base rates). How common and how long are holes in unselected phones?
• RQ3 (Attribution). Which causes can be evidenced from other stores of the same extraction, and how reliable is the attribution?
• RQ4 (Consequence). What do holes do to absence claims and to the horizon of a log?

Contributions. This report makes four contributions.

• A definition of holes by emission model, with a taxonomy of six causes and the witness each needs, and the rule that only a restart licenses an absence claim (Section 3).
• An attribution procedure with a public checker, tested on synthetic worlds with injected causes and on the agreement of three restart witnesses on 890 corpus gaps (Sections 5.1 and 5.5).
• Base rates of holes in 54 research items: lock-state intervals, day files, file numbers and log heads (Sections 5.1 to 5.3).
• Two consequences for how stores are read: a horizon taken from the oldest line can be wrong by two orders of magnitude, and a missing day file does not show that the device was off (Sections 5.2 to 5.4).

Scope. The results describe the Lab’s research corpus: 33 iPhone and 14 Android full file system extractions and 7 Android bug reports. Most iPhones run iOS 26, most Android phones Android 16, and 12 of the 14 Android phones are Samsung. A hole is a property of a store, not of the user. The attribution is a rule over evidence in the same extraction; it was not tested against events that we caused. Section 7 states the limits.

2 Background and Related Work

2.1 Gaps and completeness of logs

In server logs, a gap in a sequence number is a standard lead. Practitioners compare the record numbers of Windows event logs and treat non-consecutive numbers as a sign that records were removed, and note that a wrapped log could also explain them [1]. In process mining, logs of business processes are repaired when events are missing; Song and others propose a heuristic recovery of missing events [7] (we read the title and record only). A 2026 preprint on container platforms studies silent log loss and proposes sequence markers to detect it [8] (we read the title and record only). These works have a number or a model that tells the reader which records should exist. Phone stores rarely have one.

2.2 Timelines, time and what is absent

The systematisation of timeline-based event reconstruction names the finding of gaps and inconsistencies as a goal of reconstruction, lists sudden restarts among the environmental causes of log gaps, and asks for work on telling apart the reasons for absent data [9]. It reports these causes in a table of challenges and does not measure them. Dreier and others show that the position of a record in a file carries timing information that survives when time stamps do not [10] (search-result summary only). LAB-TR-0034 asks what an empty result licenses and assumes that the observed region of a history store is an interval [3]. Holes break that assumption; this report measures how often.

2.3 How phone stores keep and lose records

The Android log is a set of circular buffers kept by the log daemon; the default view of the logcat tool shows the main, system and crash buffers together [11]. In the platform source, the serialized buffer prunes the oldest chunks of each buffer in turn, with no weighting by the writing user, so a buffer that fills slowly keeps its oldest records for a long time [12]. Apple documents that data protection class C, the default for third-party app data, protects data from attacks that involve a reboot [13]; the description implies that a store of that class is not available between a restart and the first unlock. We did not check which class the lock-state store has. The unified log of iOS is a set of numbered files whose headers carry a wall-clock start and a boot identifier [14]. LAB-TR-0021 measured how far back such stores reach [2]; LAB-TR-0022 measured how often their clocks misbehave [4]. ABRLog is a recent dataset of 45 Android bug reports split into per-subsystem blocks [15]; the description we read does not give the time span that each block covers.

2.4 Gaps in mobile sensing and usage logs

Studies that collect sensor data from phones know that data go missing; a methods paper on mobile health trials lists identifying the sources of missing data among the practical tasks [16]. A usage gap in the sense of van Berkel and others is a pause between two uses of the phone, and the question there is whether two uses belong to one session [17]. That is a gap in behaviour. The holes of this report are gaps in the record of behaviour.

Position of this work. Gap analysis of sequence numbers, the repair of missing events, the finding of gaps in timelines and the study of missing sensor data exist. We found no work that defines holes for phone stores by the promise the store makes, attributes them to causes using other stores of the same extraction, states which cause licenses an absence claim, and measures the base rates on unselected phones. The definition by emission model, the rule that only a restart licenses absence, the attribution procedure, the two consequences and the measurements are new here, as far as we found. The search covered the arXiv, Zenodo and Crossref interfaces, with OpenAlex, Semantic Scholar and dblp blocked or rate-limited, and web search restricted to DFRWS, ScienceDirect and ACM pages (29 October 2026; the private notes log the queries).

3 Holes and Their Causes

3.1 Streams and emission models

A stream is the time-ordered records of one store. Its emission model says when the writer must produce a record (Table 3). A state chain stores intervals of a state variable, such as locked or unlocked; while the device runs the intervals tile the time axis. A day file store keeps one file for each day on which its writer ran. A numbered-file store names its files with a counter that rises by one. A dense log writes many records a minute while the device is awake. An event-driven store writes when something happens. The first four models make a promise that a reader can check without knowing a rate. The fifth does not, and we do not measure it: a quiet period in an event stream is the normal state of a phone in a pocket. Applying a threshold to such a stream manufactures holes. The event and radio logs of the seven bug reports contain 2 and 4 quiet periods of 10 minutes or more, all in one report, which the dense-log rule would call holes.

3.2 Holes

A hole is a triple (a, b, kind): the time a of the last record before it, the time b of the first record after it, and a kind (gap, overlap, repeat, missing day, stray). Its length is b − a. Detection uses only the stream and the thresholds of Table 3.

3.3 Causes and witnesses

We distinguish six causes (Table 4). Each is evidenced by a witness, a record in another store of the same extraction that does not depend on the stream under test. The restart witnesses are the boot records of the time-synchronisation files, the shutdown records, and a change of boot identifier between consecutive files of the unified log; they are three different kinds of file, which we treat as independent witnesses of a restart (Section 7). A hole with no evidenced cause is UNEX if the witnesses cover its time and UNK, unattributable, if they do not: the restart records of a phone reach back to its first boot record, and the clock-step records and file numbers have their own reach. We keep the two apart because the first is a finding and the second is a limit of the evidence.

3.4 Attribution

Figure 1 shows the steps and Listing 1 the rule. A cause is evidenced when its witness covers the hole except for at most a slack (600 s for state and dense streams, one day for day files, or a tenth of the hole if larger) after widening each witness interval by a tolerance of 600 s (300 s for dense logs). The slack allows for the distance between the bounding records and the faulty region. A clock step explains a gap if its size equals the hole within the larger of the tolerance and 10%. A hole may have several causes. A hole labelled RESTART+ is a restart bracket that explains the start of the hole but not its length (Section 5.1). A day is accounted if no hole touches it or every hole that does is evidenced as OFF and nothing else, and unobservable otherwise.

attribute(hole [a, b], witnesses W, slack s, tol t):
  causes = {}
  for c in OFF, ROT, DMG, RED:
    cov = part of [a, b] inside W[c], widened by t
    if cov > 0 and (b - a) - cov <= max(s, 0.1 (b - a)):
      causes += c
  if hole is an overlap:
    causes = {CLOCK} if a backward step lies within t
  elif a forward step of about (b - a) lies within t:
    causes += CLOCK
  if causes is empty:
    return UNK if [a, b] is outside the reach of the
               restart records, else UNEX
  return causes
RESTART+ = UNEX with a restart record within t of the hole
licence  = (causes == {OFF})

3.5 Why only a restart licenses absence

If the device was off, the user did nothing on it, and the stores of this device have nothing to record: the empty interval is evidence of absence of device activity. In every other case events may have happened and the store failed to keep them, or kept them under another date. In the language of LAB-TR-0034, a hole is a cell inside the store’s span that the store does not observe, and the witness of a restart lets another store observe it [3]. We implement this as a hole-aware count of day cells (hole_aware_cells), which turns the interval reading of a span into three classes: observed, accounted by a restart, and unobservable.

4 Method and Evidence

4.1 Frame and streams

The frame is the 54 items of LAB-TR-0034 [3]: 33 iOS and 14 Android full file system extractions and 7 Android bug reports of the Lab’s research corpus (one extraction per iPhone, 33 phones; Table 5). We read, for iPhones, the intervals of one stream of the CoreDuet knowledge store that records whether the device is locked (start, end, value); the header of every unified-log file in the Persist, Special, Signpost and HighVolume streams (wall-clock start, continuous-time start, boot identifier, file number); the boot and time records of the time-synchronisation files; the shutdown records; and the file names of the power-log archives. For Android phones we read the names of the daily usage files, the process-statistics files and the DropBox entries; the tags of the DropBox entries give boot records for up to three days. For the bug reports we read the time of every line of the system, event and radio logs, the uptime, the dump time, and the counts in the log-statistics section. No record content other than the lock flag was kept; for the stray lines of the bug reports the priority letter was counted (Section 5.2).

4.2 Settings fixed in advance, and what was post hoc

The thresholds of Table 3, the tolerance and slack of Section 3.4 and the labels were written down before the corpus run. The head-stray analysis of the bug reports is post hoc: we saw large gaps at the start of the first reports we opened and then defined a stray as a block of at most 0.5% of the lines (Table 3) and ran it on all seven. The comparison of the number of strays with the crash-ring entries was added after we found the log-statistics section. After the first corpus run we made two corrections that changed counts: devices with shutdown records but no boot records were moved to the group without a restart witness, and the reach of the witness was set to the first boot record. Sensitivity to the thresholds is reported in Section 5.1.

4.3 Synthetic worlds

A world is a 14-day timeline with running and off intervals, clock steps, and faults that remove or hide records (damage and redaction windows, rotation of a dense ring that keeps a few strays). Three streams are derived from it: a lock-state chain, a day file store and a dense log. The examiner sees the recorded times (true time plus the clock offset) and witnesses kept with stated probabilities and reach. Truth for each detected hole comes from the injected faults. The restart rate (0.39 per day) and the median off interval (634 s) are set close to the corpus medians of Section 5.1 (11.6 restarts per 30 days; 633 s); other parameters are round numbers. Each scenario uses 200 worlds. The slack of the corpus procedure (600 s) is used in all scenarios except S7, which sets it from the stream. The generator follows the rules of Section 3, so the test checks that the procedure is consistent and how it degrades when witnesses are lost; it does not show that real phones behave like the worlds.

4.4 Setup

One reader script processed each extraction in its own process, read-only, with the Python standard library; the 54 items were read without error. A second script applied the public module holes.py to the readers’ output and wrote a report of aggregates, from which every number of this report was taken. Two or three phones dominate some counts, so we report per-phone medians beside pooled counts.

5 Results

5.1 Lock-state holes on iPhones

Base rate. 30 of the 33 phones held at least 10 lock-state intervals (69,716 in total, over a median span of 28.5 days). All 30 had holes: 1,050 in total, of which 985 were gaps over a minute, 42 repeated values and 23 overlaps. The median phone had 11.4 holes per 30 days (quartiles 4.3 and 24.7), but three phones hold 63% of all holes (344, 252 and 68). Gaps are mostly short: the median is 32 minutes (quartiles 7.7 minutes and 2.3 hours), 10% last more than 11.9 hours, and the longest 111 days.

Causes. 26 of the 30 phones had boot records; they hold 890 gaps (Table 6, Figure 2). 782 (88%) lay inside an off interval, from a shutdown record to the next boot record (the median off interval is 10.6 minutes; 10% last over 5.1 hours); three of them were also explained by a clock step. 101 gaps (11%) contained a restart but were longer than its off interval; four had no evidence, and three lay before the first boot record. The label RESTART+ is not rare and not short: the median gap is 3.7 hours (quartiles 1.5 and 20.0 hours), 10% last over 4.1 days and the longest 47 days. If the store were of data protection class C, it could not be written between a restart and the first unlock [13]; the gaps are consistent with that, but we did not read the unlock events or the class of the store and so did not test it. Per phone the picture is less uniform: among 17 phones with at least five gaps the median share explained by a restart is 73% (range 0 to 100%). A phone restarts a median of 11.6 times per 30 days (quartiles 4.5 and 23.7; the extremes are 1.0 and 351).

Sensitivity. The share of restarts depends on the threshold for a gap. With gaps over 5 minutes, 30 minutes and one hour the restart share is 86% (633 of 740), 78% (356 of 458) and 74% (247 of 334); RESTART+ rises to 14%, 21% and 25%. The longer the hole, the less a restart explains of it.

Agreement of the witnesses. On the 23 phones that have boot records, shutdown records and unified-log files, 846 of 870 gaps were bracketed by both a boot record and a shutdown record and 4 by neither; 6 had a boot record only and 14 a shutdown record only (Table 7). Taking the shutdown record as the reference, the boot record has recall 98.4% and precision 99.3%. The change of boot identifier in the unified-log files has recall of 40% against the boot records (339 of 852), because the first file of a boot is often rotated out, and never fired without a boot record. We use the word reference for a record that we treat as independent of the other two, not for a truth.

Clock steps. 24 of the 26 phones had a clock step above one second in their time records (778 in total). Only three gaps matched a forward step of their own length; no other gap did. Most steps did not coincide with a gap. The 23 overlaps (a record starting before its predecessor ended) mostly lie on phones without boot records (18); of the other five, three lie next to a restart and two have no evidence.

5.2 Bug-report logs begin with strays

The system log of an Android bug report is a dense log. In 4 of the 7 reports it began with a handful of lines and then a hole of 7.3 hours to 16.5 days before the body began (Table 8, Figure 3). The strays number 1, 3, 39 and 287 lines. The body, from the end of the last stray hole to the report, is 0.19 to 3.1 hours long in these four reports and at most 3.1 hours in all seven. The age of the oldest line is 39 to 247 times the age of the body. In every report with strays the first line lies 23 to 155 seconds after the boot instant implied by the uptime and the dump time, so the oldest line is from the start of the current boot, not from an earlier one, and the device ran through the hole. The other strays are not one block: of the 39 strays of one report 36 lie in the first minutes of the boot and 3 about two days later, and the 287 of another are spread over ten days. The log-statistics section of the three reports that have one (A to C) gives the span of the system ring as 1.62, 2.95 and 3.14 hours, which agrees with the body of Table 8 to within a minute.

The log-statistics section of six reports lists the entries held in each ring. For three of the four reports with strays the number of entries in the crash ring is 1, 293 and 39, and the strays number 1, 287 and 39. The fourth report has no statistics section. The crash ring is part of the default view [11], each ring is circular [11], and the platform prunes the oldest chunks of each buffer separately [12]: a buffer written to rarely keeps its first lines while the busy buffers wrap in hours. The strays are short lines, mostly of information level: the 287 strays of one report are 207 information, 10 error and 70 fatal-level lines, the 39 and the 3 of two others are all information level, and the single stray of the fourth is fatal level. They are not crash dumps, so the name “crash ring” rests on the entry counts and not on the nature of the lines. We label these holes ROT; the evidence is the equality or near equality of counts in three reports, the absence of a restart in the interval (the uptime covers it), and the documented behaviour of the buffers. Three other holes of 11, 17 and 11 minutes lie inside the body of three reports; no witness explains them, and we leave them UNEX.

Threshold sensitivity. With a hole threshold of 5 minutes, 10 minutes or 30 minutes the same four reports have strays (43, 39 and 29 stray holes).

5.3 Day files and file numbers

Table 9 gives the day-file and file-number stores. Of the 188 day cells spanned by the power-log archives of 28 iPhones, 48 had no archive, on 8 phones. For 17 of the 48 days the unified log shows the device running (a log file started that day); for 30 there is no evidence either way, and one lies before the first boot record. A missing archive is therefore not a day on which the phone was off. The Android daily usage files lack 4 of 116 day cells, all on one phone (counted by file spacing, because the file names are local midnights); one of the four days has running evidence and three lie beyond the three days that the boot records reach.

The unified-log file numbers show holes that no time stamp reveals. The Persist stream has 862 files on 26 phones and 46 gaps in the numbering on 7 phones, 141 missing files in all (14% of the numbers issued; the median gap is 2 files, the largest 20). 34 of the 46 gaps lie within one boot session. The Special stream lacks 3,721 of the numbers on 20 phones (26%). Files were removed from the interior of the chain, or never kept; we do not know which. The process-statistics files of the Android phones, committed about every 3.6 hours, have 32 spacings over 6.5 hours on 12 of 14 phones, without a witness for any of them.

5.4 What holes do to absence claims

The lock-state stores of the 30 phones span 1,086 day cells. Read as intervals, all of them are observed days: a day with no unlock interval would be a day without use. With holes attributed, 429 (39.5%) are observed with no hole, 176 (16.2%) are accounted by a restart and 481 (44.3%) are unobservable (Table 10). On the 26 phones with a restart witness the figures are 367, 176 and 308 of 851 (36%). The median phone has 20% of its days unobservable (quartiles 6% and 56%); 3 phones have none. A day counts as unobservable if any hole touches it, so a short unexplained hole spoils a day; the count describes days on which a claim of no use cannot rest on this store alone, not days on which use occurred.

The bug-report result is a result about windows. A window of days before the report that is read from the oldest line of the system log is 0.3 to 16.6 days for four reports; the window that the dense log supports is at most 3.1 hours in every report. Days beyond it are inside a hole.

5.5 Attribution on synthetic worlds

With ideal witnesses the procedure named the exact cause set of 95.9% of 2,329 holes (Table 11). With the default witness losses (95% of boot records kept; 90% of clock steps, 80% of damage and 70% of redaction witnesses; ring evidence for 90%) the figure is 90.6%: by stream 88.1% for 1,200 state-chain holes, 73.9% for the 23 day-file holes and 93.8% for 1,106 dense-log holes. Of the 1,275 holes caused by a restart alone, 1,220 were licensed and 55 were missed; 6 further licences were wrong. Per cause, recall and precision are 95.5% and 99.8% for OFF, 92.5% and 99.4% for ROT (387 holes), 58.6% and 100% for DMG (140), 44.2% and 100% for RED (113) and 66.7% and 90.9% for CLOCK (30). Precision for UNEX is 65.4%: the holes called unexplained often had a cause whose witness was lost. A policy that treats every hole as unexplained names the exact set for 16.7%; a policy that uses restarts only, 69.0%, with 8 wrong licences.

The reach of the restart records is the limit. When the boot records reach only the last 7 days, 907 of 2,329 holes are unattributable; with 2 days, 1,546 (Figure 4). The holes that can be attributed are named correctly (92.1% and 96.9%), and wrong licences stay at 6 and fall to 0, but 658 and 1,100 holes that were restarts are not licensed. With about four times the damage and redaction rate and 2.6 times the restart rate, 82.6% of 4,633 holes are right and 57 of 2,799 licences are wrong (2.0%). Setting the slack from the stream (the 95th percentile of its normal spacing, 4.5 hours for the state chain) instead of 600 s gives 92.9%; keeping boot records only, with no shutdown records, 90.5%.

6 Discussion

6.1 What a report should say about a gap

The useful statement about a gap has four parts: where the store promised records, what the hole is, which cause the other stores support, and what that licenses. “The store holds nothing between 22:00 and 07:30” becomes “the device restarted at 22:01; the store was silent for a further 9 hours; nothing can be said about use in that time from this store.” The first sentence of a report that finds a hole should not be that data were deleted. In our sample the answer was a restart for 88% of gaps and something else, mostly longer than a restart, for 11%.

6.2 Use the body of a log, not its oldest line

The oldest record misleads where a store is the union of rings with different horizons. In four bug reports the oldest line was from the first minutes of the boot, kept by a ring that rarely fills; the rings that carry the activity held at most three hours. Reporting the span of a log from its first and last line, the simplest reading, over-reports it by up to 247 times. A reader can report the body horizon with one pass: the start of the last block that is dense. We have not checked other Android releases or vendors.

6.3 The reach of the witness is the limit

The attribution cannot be better than its witnesses. Boot records on the iPhones reach back to the first boot of the retained time-synchronisation files; on Android the DropBox entries reach three days. The Android daily usage files lacked 4 days, and three lay outside the boot records. The synthetic worlds show the cost: with a 7-day reach, 39% of holes cannot be attributed at all. An examiner who has restart evidence for the whole span can license absence for the restarts; one who has it for the last week cannot say anything about the third week. That is a reason to collect the shutdown and boot records of a device at the time of acquisition.

6.4 Silent after the restart

RESTART+ is the label the unexpected finding needs. A claim of “no use after the restart” is not licensed by a restart. The phone had restarted and was running, but the store was silent for a median of 3.7 hours, and up to 47 days. If the store is of the class that is not available before the first unlock [13], the user may have been unable to unlock, or may not have wished to; events such as incoming calls and messages may have occurred and be recorded elsewhere. The finding is for the examiner who reads the end of a hole as the time of the next action.

7 Threats to Validity and Limitations

Internal. The labels are rules over witnesses, not observations of cause. The three restart witnesses are three kinds of file that we treat as independent; the sources we read do not say that the system writes them independently, so their agreement shows consistency, not independence. The synthetic worlds follow the rules that they test; the 91% shows consistency and how the rules degrade, not that real phones behave that way. Reading the head strays as the entries of the crash ring rests on equal counts in two reports, a near-equal count in one and documentation; the lines themselves are mostly information-level messages and not crash reports, and we did not use their content. The mapping of day files to days assumes that file names are local midnights and uses the first usage file to find the offset; the power-log archive names carry a calendar date without a zone, so the running evidence of a missing day can be off by up to a day at its edges. Data protection (Section 6.4) is an interpretation that we did not test.

Construct. A hole is defined by the promise of a store, so the definitions of Section 3 decide the base rates; the thresholds (60 s, 600 s, 6.5 h, 0.5%) were chosen before the run and varied in Section 5.1. A day touched by any unexplained hole counts as unobservable, which overstates the loss of a day. The licence for a restart assumes that the stores of the device record all that the device does; a restart does not show what happened to the user or to other devices.

External. The corpus is not a random sample. 20 of 33 iPhones run iOS 26, 9 of 14 Android phones Android 16, and 12 of 14 are Samsung. Two or three phones dominate the pooled counts of the lock-state holes; they may be test or heavily restarted phones. Seven bug reports, four of them with strays, are a small base. Whether a bug report and an extraction come from the same phone was not established.

Conclusion validity. The counts are counts of phones and gaps; there is no test of significance. Intervals would be wide for the per-phone shares.

Limitations. We did not read the unlock events and so could not test the data-protection reading of RESTART+. Redaction was exercised only on synthetic worlds; no corpus stream let us observe it. Damage was seen only through file numbers. Event-driven stores were not measured. A controlled run, in which a test phone is restarted, switched off and left locked at known times, would test the labels directly; we did not run one.

8 Conclusion

A gap inside a phone log is evidence about the phone only once its cause is known. We defined holes by the promise a store makes, gave six causes and the witness each needs, and showed that only a restart licenses the claim that nothing happened. Across 54 research items the most frequent cause of a gap in the lock-state store of an iPhone was a restart (88% of 890 gaps), the next a store that stayed silent after the restart (11%), and some of the largest holes were not visible in time stamps at all: the system log of four bug reports began with stray lines up to 16.6 days older than the three hours that the log actually held, and 17 of 48 missing power-log day files fell on days that the device ran. A report that finds a hole should name its kind, the cause that other stores support, and what that cause licenses.

Future work, in order of value: (1) a controlled run on a test phone with known restarts, locked periods and clock changes, to test the labels and the data-protection reading; (2) the unlock events of the iPhones, to separate the end of RESTART+ from the first unlock; (3) a hole-aware observed region inside the absence calculus of LAB-TR-0034; (4) the sparse event logs, with a rate model validated against a dense stream.