1. The document survived, but did its evidence survive with it?
An archive opens a signed document years after it was deposited. The text is readable, the date on the first page looks plausible and a current application displays a warning. It is tempting to choose between two simple stories: the document is now invalid, or the warning is irrelevant because the document is old. Neither story can be justified without examining what the warning concerns and what evidence the archive retained.
Long-term verification is not merely the act of opening an old file with new software. The relevant packet may include the original object, a signature, certificates, dated status information, time evidence, a past validation report and the rules under which that report was produced. Some of those items describe the document; others describe an assessment of it. Losing the distinction can turn a missing supporting record into an accusation that the document was fabricated.
Current source status matters as well. NIST withdrew Special Publication 800-102, Recommendation for Digital Signature Timeliness, on July 1, 2025. A saved copy of the 2009 publication should therefore not be presented as current NIST guidance. The withdrawal notice is a record about the publication's status, not a technical finding that every historical signature discussed under it has become false. NIST's withdrawal notice
This article uses a fictional Willow archive to make the evidence problems concrete. Its documents, dates, certificates, reports, policies and institutional decisions are invented. A small local program actually checked a custom three-file inventory and performed date arithmetic. It did not generate or validate a trusted timestamp, contact a certification authority or authenticate a real public record. There are no production keys, private credentials or third-party identities in the exercise.
The central public-interest question is historical: what can the retained material establish about a particular object at a particular time? That is different from asking whether a file can be downloaded today, whether its text is accurate or whether a modern application accepts it under today's settings. Those questions can be related without being interchangeable.
For a researcher examining a permit, procurement record or public decision, the useful outcome is an evidence map. It should identify the object under discussion, the event each date represents, the supporting material available and the conclusions that remain unresolved. A broad label such as verified is less helpful than a precise account of which historical proposition was actually examined. The archive's job is to preserve the possibility of that examination, not merely the appearance of a dated document.
2. A time token concerns a particular object, not every event in its story
RFC 3161 describes a service supporting evidence that data existed before a particular time. Its authority timestamps a data imprint rather than examining the underlying document's assertions. The August 2001 protocol was updated by RFC 5816 in March 2010 to permit an additional signer-certificate identifier using hash functions other than SHA-1. These documents describe technical evidence and its checks, not a universal finding about legal filing dates or the truth of a document's narrative. RFC 3161, RFC 5816
For fictional Willow, assume properly assessed time evidence supports a specified object's existence by June 3, 2020. Its first page describes a May 20 meeting. That evidence concerns the object's existence by the stated boundary; it does not independently establish the meeting, approval of the minutes or creation on May 20.
Now imagine three candidate objects: an unsigned draft, a signed version and a later archive package containing both. A catalog entry says only timestamp present. Without identifying the covered object, that entry is inadequate for a claim about when the signature existed. Evidence associated with the draft cannot silently be reassigned to the signed version, and evidence associated with a later package needs its own scope explained.
The fictional packet can make that relationship explicit without requiring the reader to decode a protocol. Call the draft W17-D, the signed object W17-S and the archive package W17-A. The inspection note should identify which item was compared with which retained evidence. These are invented identifiers, not cryptographic hashes. Their purpose is to expose a documentary association that must be established with the real identifiers in an actual investigation.
Suppose a researcher discovers that the catalog attached the time-evidence entry for W17-D to the description of W17-S. Correcting the catalog association does not, by itself, prove the signed object was created late or improperly. It removes an unsupported connection. The next step is to determine whether separate evidence for W17-S exists, not to preserve the incorrect connection because it makes the timeline simpler.
3. Normalize the time representation before arguing about the sequence
RFC 3339 describes numeric offsets as local time minus UTC. The offset therefore matters when two written timestamps are compared. The July 2002 specification supplies a representation convention; a correctly formatted timestamp does not, by its syntax alone, authenticate the clock or the event attributed to it. RFC 3339
The actual local arithmetic checked two invented values: 09:30:00 with an offset of minus five hours, and 14:30:00 UTC on June 3, 2020. They represent the same instant. Their difference is zero seconds, not five hours. A timeline that sorted the visible hour fields without accounting for the offsets would create a sequence that the supplied values do not support.
For a separate fictional deadline exercise, stipulate a deadline at 14:30:00 UTC. A claimed receipt time is 14:29:40, twenty seconds earlier; a recorded arrival time is 14:30:10, ten seconds later. The two values differ by thirty seconds. That arithmetic does not determine whether a real filing was timely. The fictional rule would still need to specify which event controls, and the packet would need evidence connecting each field to the relevant event.
The terminology can be the source of the dispute. Sent, received by a gateway, accepted by an application and entered in a public register can describe separate stages. A system could record all four without contradiction. A report that calls each field the filing time hides the very distinction that might explain the apparent delay. The reader needs the event definition alongside the date.
Precision introduces another trap. Suppose an invented record gives a time to six decimal places, while its accompanying measurement note stipulates uncertainty of two seconds in either direction. The extra digits do not erase the uncertainty. If one event is recorded at noon with that range and another at one second after noon with the same range, their possible intervals overlap. This is ordinary interval reasoning, not a claim that a particular timestamp protocol or service behaved that way.
A date-only catalog field creates a different limit. It can be useful for grouping records by day while supplying no basis for ordering two events within that day. An editor should not invent a midnight time merely to make a plotting tool accept the data and then treat that invented value as an observation. A clearly labeled display convention is acceptable; an unlabeled chronological claim is not.
The result of this work can be a modest but important correction: two reports describe the same instant, or two different events have been confused, or the available precision cannot settle their order. Those findings improve a historical account without pretending that date formatting itself supplies trusted time evidence.
4. A certificate's expiration date is not a complete history of a signature
RFC 5280 defines a certificate's validity interval from notBefore through notAfter, inclusive. Its base specification also distinguishes validation with respect to current time from implementations that support a past-time assessment. These are bounded technical definitions from the May 2008 document, not a complete modern archival-validation procedure. RFC 5280
Take an invented certificate record with an interval beginning January 1, 2019 and ending December 31, 2021. Willow reviews an associated file in 2026, while the file claims a 2020 signing date. The review date is outside the recorded interval, and the claimed date is inside it. Those calendar relationships alone do not establish when the signature was actually created or whether the relevant historical validation requirements are satisfied.
The useful next question is what evidence supports the claimed signing period. A printed date in the document, a separately retained time record and a historical validation report are not interchangeable items. The archive should identify what it has rather than substitute the easiest-to-read date for the missing evidence. A claim that the signature must be unacceptable solely because the certificate is expired today omits the historical question; a claim that the printed old date automatically resolves it omits the evidentiary question.
Now change the fictional packet so that the certificate identifier in the past report does not match the certificate retained beside the document. Both certificates might name the same office. That similarity does not establish that the report assessed the retained certificate. The archive needs to reconcile the exact objects before drawing conclusions about the past result. The mismatch could be a packaging error, but that explanation should be documented rather than assumed.
A second useful distinction is between a certificate's stated period and a later report about its status. An expiration date is a scheduled boundary in one record. A status record describes something else under its own definitions. Combining all time fields into one column called invalid since can conceal differences that matter to historical interpretation. The proper comparison uses the actual field names and their meanings.
The purpose of this example is not to teach readers to override a warning or to select an old date until software produces a favorable result. No application setting was changed here, and no historical validation was performed. It is to show why an archival conclusion needs more than a current warning screenshot. The supporting objects, their associations and the question being asked must survive with the document.
5. A certificate-status response contains more than one clock
RFC 6960 gives distinct meanings to OCSP time fields. ThisUpdate is the latest time the responder knew the indicated status to be correct; nextUpdate concerns when newer information will be available; producedAt records when the responder signed its response; revocationTime identifies revocation or placement on hold. The June 2013 specification does not make these fields synonyms for the date a document was signed. RFC 6960, section 2.4
For a fictional status-response worksheet, stipulate thisUpdate at 10:00, producedAt at 10:02 and nextUpdate at 11:00 on the same UTC day. The response-signing event is two minutes after the status reference time, and the next-information boundary is one hour after that reference time. These calculations translate the stipulated fields; they do not authenticate a response, establish its acceptability or determine the validity of an associated signature.
Suppose Willow's catalog has copied producedAt into a field labeled document signed. That mapping is wrong under the stated definitions. Correcting it can move an apparent event in the public timeline without changing any underlying signature. A reporter should say that a catalog field was misclassified, rather than say that the document's signing date was secretly altered.
A different packet might contain two status records collected on different days. Their mere presence does not establish that either record was available to the original reviewer. An investigation of what a past reviewer knew needs the retained review inputs or another reliable record of availability. A modern retrieval can be useful to a new assessment without proving the contents of an older assessment.
The distinction matters when an archive reports that all necessary information is stored locally. Necessary for which assessment? A current inquiry and an attempt to reconstruct a historical result can require different comparisons. The archive should specify the purpose of the retained record rather than attach an undated assurance to every status file in the collection.
There is also a simple association problem. A file named status-response may concern a different certificate from the one used in the document's signature. A plausible filename or matching office name does not resolve that mismatch. The record should connect the status information to the intended certificate using the actual identifiers. If the connection is unavailable, the limitation should be reported before the status text is promoted into a conclusion about the document.
A good historical account keeps the response's event times, its collection time and the review's execution time separate. The differences among those dates can explain a change in an assessment. They can also expose an incomplete packet. Neither possibility should be replaced with a more dramatic story before the evidence has been reconciled.
6. An unresolved validation result is not a finding of fabrication
ETSI EN 319 102-1 V1.4.1, the June 2024 final PDF consulted here, distinguishes passed, failed and indeterminate validation outcomes. Its treatment makes the validation time, constraints and available evidence consequential inputs, and its long-term procedures consider proofs of existence. That does not mean every later warning is curable or every old report can be reconstructed from a date on the page. ETSI EN 319 102-1 V1.4.1
Consider an invented Willow review folder containing a document, two certificates and a screenshot that says validation incomplete. It lacks the detailed report and does not identify the input files used for the screenshot. The most immediate limitation is documentary: the folder does not explain what the application assessed or why it stopped. Calling the document forged would invent a finding not contained in the retained material.
Now suppose the detailed report is recovered. It names a missing supporting object and records the policy version used. That discovery narrows the inquiry. The archive can search for the specified object and establish whether the report's inputs match the archived document. It should not promise in advance that locating one file will produce a successful assessment. The actual process could reveal another unresolved requirement or a substantive failure.
A second fictional report may have used a different policy version. If its outcome differs, the first question is whether the comparison holds all other inputs constant. Did the document change? Did the collected evidence change? Was the assessment date different? A discrepancy among reports can be a useful lead without being proof that one application is dishonest or that the original document changed.
For an audit of the archive's own work, record those differences as separate fields rather than a single free-text explanation. A case can then be classified as an input mismatch, an evidence addition, a policy change or an unresolved difference. These are proposed editorial categories for the fictional exercise, not ETSI result codes and not outputs from a validation tool run for this article.
The distinction protects both accountability and restraint. An archive should not conceal an unresolved outcome behind a success label. A critic should not convert an unresolved outcome into a positive finding of forgery. The useful public statement names the limitation and the evidence needed to investigate it. That gives another reader a concrete way to check the claim without asking them to trust either side's interpretation of a warning icon.
7. Renewal preserves a relationship only if the earlier evidence is connected
RFC 4998's Evidence Record Syntax addresses long-term preservation evidence and periodic timestamp renewal before the mechanisms supporting earlier evidence become compromised. Its August 2007 specification allows evidence records to be stored separately from the archived data. It is not a promise that adding a new timestamp today can reconstruct an undocumented historical chain. No ERS structure or renewal procedure was implemented for this article. RFC 4998
Imagine a fictional Willow archive with three preservation events labeled R1, R2 and R3. A summary says that the collection was renewed at each event. The actual packets identify different object sets: R1 names twenty documents, R2 names nineteen and R3 names twenty again. The changing counts do not establish continuity for the missing document. The archive must identify which item was omitted and what evidence, if any, supports its history across the gap.
Suppose the twentieth item in R3 is a corrected document rather than the same object that appeared in R1. The count returned to twenty, but the membership did not. A report that compares only the totals would miss that distinction. An object-level mapping can state that nineteen items continued unchanged and one later item has a different history. That is more informative than describing the whole collection as uniformly renewed.
A different fictional packet could have all twenty original objects but omit the record connecting R2 to its predecessor. The archive then faces a missing association, not necessarily missing document bytes. A successful modern inventory check would answer whether the current files match the current manifest. It would not supply the absent relationship between historical preservation events. Those are separate checks with separate evidence.
Consider how the correction should be recorded. If the missing connection is found in an older export, the archive can add it with a note identifying its source and association. If it cannot be found, the public description should retain the gap. Creating a new summary that simply repeats continuous since R1 would not establish the history. Neither would deleting R2 from the narrative so that no gap appears on the chart.
The practical question is not whether an archive contains a large number of time records. It is whether the particular document's preservation history can be followed through the records actually retained. A collection may contain extensive evidence for most items and a limited history for one. Reporting that difference preserves the value of the evidence without pretending that the strongest item's history automatically belongs to every other item in the same storage system.
8. The local inventory experiment distinguishes missing, changed and renamed
RFC 8493, the October 2018 informational BagIt specification, distinguishes a complete package from a valid one: the required and listed material must be present, and the manifest checksums must verify against the corresponding files. That is a packaging distinction, not a historical authenticity judgment. The local exercise below uses a custom path manifest, not a conforming BagIt implementation. RFC 8493
The executed fixture contained three freshly authored byte strings. A forty-nine-byte text record referred to fictional item W17. An eighty-byte catalog record included an asserted record date of June 3, 2018 and an explicit fictional flag. A fifty-eight-byte note said the material was a demonstration, not timestamp or validation evidence. The program computed SHA-256 values for those exact inputs and compared four candidate inventories with its saved path-and-hash manifest.
The original candidate matched all three expected paths and byte values. In the second candidate, the note was omitted: two paths matched and one was missing. In the third, the record's identifier changed from W17 to W18: all expected paths were present, but only two matched their saved byte values. The remaining path was reported as a mismatch. These are actual local outputs, not findings about a public archive.
The fourth candidate renamed record.txt to renamed-record.txt without changing its contents. Under the original path mapping, the program reported the old path missing and the new path extra. A separate comparison found that the renamed file's bytes matched the original record's digest. That result distinguishes a naming change from a content change in this fixture. It does not justify silently relabeling arbitrary files in a real archive until a check passes.
The catalog's 2018 date is especially useful. It remained present in a file authored for this 2026 exercise. Matching that file's current checksum did not establish that the file existed in 2018. The field was an explicitly invented assertion in the content. The local program checked byte relationships, not the historical event described by the field. No system clock or file timestamp was altered to create this demonstration.
These distinctions can improve a public preservation report. Missing means the expected object was not supplied to this check. Mismatched means a supplied object's bytes did not match the stated reference in this check. Renamed with matching bytes is a particular relationship that was separately demonstrated. None of those labels automatically identifies who made a change, why it occurred or whether a historical claim is true. The report should preserve the observed result and investigate its cause separately.
9. A readable migration can lose a feature that the research question needs
An archive may preserve an original object while also producing a new representation for access. For a fictional Willow case, imagine an old document that is difficult to render in a current viewer. The archive creates a readable derivative and retains the original. The derivative can be useful without being the same object. Its relationship to the original should be documented, especially when a researcher relies on features that may not survive conversion.
Suppose the original contains twelve pages, while the derivative contains eleven because a blank-looking page was omitted. A visual inspection later finds a faint docket mark on that page. The missing page does not necessarily change the main narrative, but it matters to a question about the record's filing history. A page-count difference becomes a concrete preservation issue once the research purpose is specified.
An optical-character-recognition layer can create a different problem. In another invented example, the image shows a case number ending in 017, while searchable text reads 170. A search for the correct number might fail even though the page image remains available. A report should distinguish failure to find the item through the text index from absence of the item in the image collection. The remedy may involve correcting an access derivative rather than altering the preserved source object.
Now add an annotation that was stored separately from the main document. The original export may have included the annotation, while the later migration copied only the main file. The main text can remain readable and unchanged even though the record set is incomplete for a particular question. A byte comparison of the main file would not reveal an omitted object that the comparison never expected to inspect.
These examples do not establish defects in any real format or archive. They show why acceptance criteria for a migration should be tied to the intended use. If the purpose is reading the text, text legibility is relevant. If the purpose is reconstructing annotations, page order or associations with signature evidence, those properties require their own comparisons. One successful task should not be advertised as proof that every other task remains possible.
A useful migration note can identify the source object, the derivative, the transformation performed, the features checked and any known omissions. It should also explain which object a later verification report used. That record allows a future researcher to distinguish a changed representation from a changed historical source. Without it, a helpful access copy can gradually become mistaken for the only original, and its limitations can disappear from the public account.
10. A restored backup can reproduce an incomplete packet perfectly
Suppose Willow stores three copies of a preservation packet. After a storage failure, the restored copy matches the packet's saved inventory. That is a valuable recovery result. It does not establish that the original packet contained every piece of historical evidence needed for a later inquiry. Replication can preserve an omission as faithfully as it preserves an included file.
For a fictional example, the packet contains a document, its signature and a past report, but the report refers to supporting status information that was never exported. All three copies share the same omission. Restoring any one of them reproduces the available files without supplying the absent status record. Calling the restore unsuccessful would ignore the task it performed; calling the historical evidence complete would claim a task it did not perform.
This distinction becomes visible when recovery tests specify an actual research question. Can the archive recover the document bytes? Can it recover the particular report named in the catalog? Can it identify the inputs that produced that report? Can an appropriately configured assessment be attempted with the retained material? These are different outcomes. The first can succeed while a later one remains blocked.
Now imagine the three copies were created from different exports. One includes the missing status record, another includes a newer report, and a third has the original document plus an incorrect catalog association. The archive should not assemble a preferred-looking packet by selecting files solely because their names are familiar. It needs the relationships among the objects and the provenance of the export that supplied each one.
A reconstruction note can make those choices explicit. It might state that the document came from export A, the supporting record from export B and the association was confirmed by a retained transfer list. If the association cannot be confirmed, that uncertainty belongs in the reconstruction record. The goal is not to make every recovered folder appear identical; it is to explain what the recovery established and what remains unresolved.
There is also a difference between recovery and availability to the public. An archive may have a complete internal packet while its public download contains only the readable document. A researcher should ask what the public package includes before interpreting missing downloadable evidence as proof that the archive never retained it. Conversely, an archive should not claim that a public download is independently verifiable if essential inputs are unavailable to the intended verifier. The access boundary needs to be stated, not inferred from a successful backup test.
11. Preservation cost estimates should count the evidence, not only the document
Long-term verification has a practical resource dimension: the archive must retain the material its future claims depend on. A procurement estimate that counts only readable documents can omit the supporting objects, associations and reports that make historical review possible. The appropriate size depends on the actual collection and purpose; the following figures are an original arithmetic exercise, not a market price or storage recommendation.
Stipulate three hundred thousand fictional records, each averaging two megabytes of document data and fifty kilobytes of supporting evidence. Use decimal units throughout: one megabyte is one thousand kilobytes, and one gigabyte is one thousand megabytes. The documents total six hundred gigabytes. The supporting evidence totals fifteen gigabytes. One complete copy of the stipulated collection therefore contains six hundred fifteen gigabytes, before any additional overhead.
Three complete copies total 1,845 gigabytes under those assumptions. Three copies of the document data alone total 1,800 gigabytes. The difference is forty-five gigabytes across the three copies. That number is not a full preservation budget: it excludes indexes, software, management records, redundancy internal to a storage system and the labor of checking associations. It simply exposes a component that a document-only estimate would leave out.
The fifty-kilobyte average also needs to be treated as an assumption, not a universal property of signed records. Some fictional items could share supporting material; others could require larger packets. Deduplicating identical objects might reduce stored bytes, but the archive would still need to preserve each record's association with the shared object. A smaller byte count does not automatically mean a less complete evidentiary record, just as a larger folder does not automatically mean a more complete one.
A useful purchasing question is therefore specific: does the quoted export include the original objects, the defined supporting material and the mapping needed to associate them? A vendor's count of downloadable files may answer only part of that question. For example, one container file could hold several evidence objects, while many loose files could lack the necessary relationships. File count, storage size and evidentiary usability are different measures.
The test should use an agreed sample packet and a stated task rather than a promise that everything is preserved. A reviewer can inspect whether the exported objects are present, whether their stated relationships can be followed and whether a documented historical assessment can be attempted. The exercise does not require declaring every record valid in advance. It requires making the service's actual preservation boundary visible before a future researcher depends on it.
12. Report the historical conclusion at the strength of the retained evidence
Return to the opening warning. Willow has an old readable document, a certificate whose stated period has ended and several archival records. A useful report does not begin by selecting a favorable label. It begins by identifying the object and the historical question: whether a particular signed version existed by a stated time, whether a past assessment can be reconstructed, or whether the currently supplied file matches a retained reference.
Those questions lead to different evidence. A current inventory comparison can establish a relationship among supplied bytes and reference values. A retained time record requires its own appropriate assessment and association with the intended object. A historical validation report describes a result obtained with particular inputs and constraints. An access derivative may help readers understand the document while requiring a separate connection to the preserved source. The public account should not collapse those records into one undifferentiated proof.
Consider three possible conclusions for an invented case. First, the current download matches the archive's retained reference, but the packet does not establish its history before the reference was created. Second, historical supporting material exists, but its association with the signed object remains unresolved. Third, a documented assessment was completed using identified inputs and a stated policy. These conclusions differ in substance, not merely in confidence or tone.
The third should still describe what was assessed. It is not automatically a finding that the document's narrative is accurate, that a legal deadline was satisfied or that every earlier version has the same history. Those claims would require the relevant factual or legal inquiry. An archive can provide strong technical evidence while leaving those other questions open. Doing so makes the evidence more usable because the next reader can see its scope.
Corrections should preserve the same distinctions. If a catalog associated the wrong time record, correct the association. If an export omitted supporting material, identify the omission and the source of any recovered object. If a readable derivative lost a page, preserve that finding with the migration record. A correction to the archive's description need not be represented as a change to the underlying historical event.
The actual local fixture in this article supplies a deliberately smaller result. It demonstrated matching, missing, changed and renamed files against a custom manifest, and it checked offset arithmetic. It did not create trusted time, validate a signature or recover a historical certificate assessment. Its 2018 date field was visibly fictional content authored in 2026. That bounded result is useful precisely because it does not claim to have performed the harder archival work.
A timestamp can be an important part of a historical evidence packet. It remains an assertion whose meaning depends on the object, time, issuer, policy and retained supporting material. Long-term verification succeeds as a public practice when those relationships remain inspectable after software, certificates, storage arrangements and staff have changed. Saving the document is necessary. Saving the evidence needed to ask the historical question is the separate task that makes the archive worth relying on.