When timing becomes evidence: why technical documents need a verifiable point in time
· Dipl.-Ing. Andreas May
Technical documentation records what was planned, checked or decided. In a dispute the content alone is often not enough. Whether a particular version already existed at a particular point in time counts just as much. A proof of time gives that an independently verifiable basis, for design states, risk assessments, test records and other technical documents.
The question comes years later
Engineers and technical staff document their decisions traceably. Design states are versioned, risk assessments updated, tests recorded, approvals archived. What belongs to a project is easy to follow.
Another question is harder to answer: when did exactly this version actually exist?
During the project the question looks secondary. It usually comes up much later, after an incident, in a warranty claim, during an inspection by the authorities, or when the parties remember an earlier technical state differently.
Producing a document may then not be enough. What counts can be showing that exactly this content existed before a particular event.
File dates and version numbers are not a proof of time
Technical documents usually carry version numbers, revision states and file dates. A project needs that information. It does not replace an independently verifiable proof of time.
A file date is a property of the file system and can be changed. A version label such as “Rev. 3”, “as of 12 March” or “released” only records what the author entered into the document.
Placing a document in time reliably therefore needs an additional piece of information, anchored outside the document and impossible to set back to an earlier point afterwards.
What StampIt does
With Probavis StampIt you add a proof of time to individual files or to a whole set of related documents. That can be a risk assessment together with its report, and equally design documents, test records, acceptance papers or quotations.
The documents themselves are neither published nor placed in a public register. StampIt calculates cryptographic checksums from the selected data, unique digital fingerprints, put simply.
Those values become a timestamp that OpenTimestamps anchors in a public register. That register is the publicly verifiable time anchor.
The point of it: the register only grows forward, and an entry that is already closed cannot be added to afterwards. A proof created today therefore cannot be backdated to look as though it had existed yesterday.
A successfully verified proof thus carries the statement: this set of data existed at the confirmed point in time at the latest.
Changes do not go unnoticed
Cryptographic checksums react to the smallest change in the data.
If a file covered by a proof is changed later, recalculating gives a different checksum. The original proof no longer matches that file.
StampIt therefore answers two questions that belong together in technical documentation: is this the same state of the data, and did it already exist at the point in time covered by the proof?
The documents stay in the company
With design data, risk assessments and other confidential material, what leaves the company is what counts.
StampIt transmits neither the files nor their names or storage paths. Only a checksum derived from the data goes out for the timestamp. The technical content stays on your own computer or in your own network.
A proof of time is created without handing the documents you want to protect to an external timestamping service.
The proof should stand without StampIt
A proof that only one particular piece of software, or only the original vendor, can check creates a new dependency.
StampIt therefore builds on the open OpenTimestamps standard. Once the timestamp is finally confirmed, a PROOF_ file holds everything needed to trace the proof back to the register entry.
Verification does not hang on StampIt. A finished proof can be checked with other suitable tools, or, with the corresponding effort, directly against the register. Where retention periods run for many years or decades, that is what counts.
Proofs of time in engineering documentation
A proof of time replaces neither version control nor a document management system. It says nothing about whether a technical decision was right. It adds the independently verifiable time reference of a specific state of the data.
For most engineering processes it is therefore not worth covering every interim version, but the milestones that matter: the released risk assessment, an important design state, the state at acceptance, the documentation at the time of delivery. In StampIt that is three steps: select the files, create the proof, archive it together with the technical documentation.
Whether a document exists is easy to answer years later. Whether exactly this document already existed back then in exactly this form is not. That answer should not have to come from memory or file attributes.