AllSignal Book a scoping call

Verification

Anyone holding the file can check it. Here is how, and where it stops.

For every sealed entry, including Seal 00, I prepare a verification pack. The file, and that it existed by the sealed time, can be checked without me. The calculation can be re-run where access to my engine is agreed.

Sample

An excerpt from a Sealed Schedule Record.

Three monthly entries for three facilities, anchored on the sealed baseline. In the third month the driving path to Facility B changes, and the record shows when and why.

Illustrative example — not a real project. Names, dates and hashes are made up. Hashes are shown truncated.
Project: Example LNG Expansion Anchor: Seal 00, accepted baseline, data date 31 Jan 2027, sha256 3b7e…c210
Record entries, Updates 07 to 09
Entry Data date Sealed (UTC) SHA-256 of .xer Facility A finish Facility B finish Facility C finish Excluded records Driving path note
Update 07 31 Aug 2027 02 Sep 2027 08:41 9f2c…41ab 22 Mar 2029 09 Nov 2028 14 Aug 2029 3 All three paths as at baseline.
Update 08 30 Sep 2027 04 Oct 2027 10:12 e71d…0c93 29 Mar 2029 16 Nov 2028 14 Aug 2029 2 Paths unchanged. A and B each 1 week later.
Update 09 31 Oct 2027 02 Nov 2027 09:05 5a08…d7e2 29 Mar 2029 21 Dec 2028 21 Aug 2029 4 Facility B path changedPATH CHANGE from gas turbine generator work to substation 2 cabling. B 5 weeks later; C 1 week later.

My engine calculates the finish dates, driving paths and excluded-record counts for each sealed file. I do the hashing, timestamps, path notes and change log myself.

Driving path, Facility B, Update 08

  1. Main pipe rack steel erection Sharedfinishes 18 Jan 2028
  2. Gas turbine generator deliveryfinishes 12 May 2028
  3. Gas turbine generator installationfinishes 25 Aug 2028
  4. Commissioning, Facility Bfinishes 16 Nov 2028

Driving path, Facility B, Update 09

  1. Main pipe rack steel erection Sharedfinishes 18 Jan 2028
  2. Substation 2 cable pullingfinishes 04 Aug 2028
  3. Substation 2 terminations and testingfinishes 29 Sep 2028
  4. Commissioning, Facility Bfinishes 21 Dec 2028

Change log, Update 08 to Update 09, on or near the Facility B path

  • 2 relationships removed between gas turbine generator installation and Facility B commissioning.
  • 1 start-no-earlier-than constraint added on substation 2 cable pulling.
  • Substation 2 cable pulling duration changed from 35 to 60 working days.
  • Calendar on substation 2 cabling activities changed from a 6-day to a 5-day week.

Recorded as fact. Whether a change was justified, or who is responsible for it, is not judged in the record.

Verification pack

What comes with every sealed entry, and how to check it.

What is in the pack

File
Name, size, P6 project ID and data date
Hash
SHA-256 of the .xer exactly as received, which I compute with standard tools
Timestamp
Time of receipt as I logged it, and a timestamp token showing the hash existed by that time (it does not show who sent the file or when), and the transmittal that returned the hash to you
Engine
The engine version used, which I record, so the same version can be re-run
Output
Each facility’s finish and driving path, shared upstream work, ranking and excluded records, with a hash of the output, which I compute with standard tools
Re-run
Instructions to repeat the calculation and the output hash to expect
Limits
The plain statement below

How a third party re-verifies

  1. The file. Hash their own copy of the .xer, for example from the document control system. If it matches the sealed hash, it is the same file, byte for byte. Any standard tool does this, for example shasum -a 256 update_09.xer.
  2. The time. Check the timestamp token against the authority’s public certificate with standard tools, or check the dated transmittal that quoted the hash.
  3. The calculation. Re-run the named engine version on the verified file and compare the output hash. How a third party gets access to the engine is agreed per engagement. A manual cross-check in P6 of the listed path activities and links is always possible, though weaker.

Limits

What a seal proves, and what it does not.

  • A hash proves a file is unchanged since it was sealed. It does not prove the file is right. It does not show that the update reflects site progress, that its logic is sound, or that it was the programme both parties accepted.
  • A seal on receipt shows what was received and when. It is not acceptance by the other party. A counter-seal shared with the counterparty comes closer to a jointly held record.
  • US Federal Rule of Evidence 902(14) treats hash-authenticated electronic copies as self-authenticating when a qualified person certifies them. I cite it only as a reference point that hash authentication is a recognised idea. It does not apply automatically in arbitration, outside US federal courts, or under your contract.
  • Commentary suggests arbitral rules can accommodate hash and timestamp evidence, but treatment varies and I know of no construction-delay decision on it. Admissibility and weight are for the tribunal.
  • The record and the pack are factual. They are not an expert-witness opinion unless separately agreed, and they do not decide entitlement, causation or any claim.

Start the record at the baseline.

Seal 00 comes with every Baseline Review.

Book a scoping call

I reply within two working days. How I handle your files.