Every public infrastructure tracker works the same way. A team compiles the best available picture of the world, publishes it as a file, and some months later publishes a better one. The new file replaces the old. What the old one said is not deleted exactly, but it stops being anywhere convenient, and almost nobody keeps their own copy.
That is a reasonable way to run a tracker. It is a poor way to understand an industry, because the useful questions are nearly all about change.
The questions a snapshot cannot answer
Look at any single release of LNG terminal data and you can answer: how much capacity is operating, where, owned by whom. Useful, and not nothing.
Now try these.
Which projects moved from proposed to pre-construction this year? Which quietly went the other way? Whose capacity was revised down after a final investment decision? Which owner sold out of a project between releases? Which terminal appeared for the first time, and which vanished without ever being cancelled?
None of those can be answered from one file. All of them are answerable from two.
What we keep
Every time a new release is ingested here, the outgoing database is kept rather than overwritten, and the two are compared. The comparison is committed to the repository as a small JSON file, one per release pair, and it drives the change log and the history section on every asset page.
The comparison is deliberately narrow. It records an asset appearing or disappearing, and changes to status, capacity, ownership, name, key dates, cargo containment, propulsion, and whether a pipeline has route geometry. It ignores everything else, and it ignores capacity moves below a rounding threshold, because a figure restated from 5.2 to 5.20 is not news.
Two design decisions matter more than they might look.
Compare on identity, not on name. Assets are matched by the tracker’s own identifiers. A project that gets renamed is recorded as a rename, not as one asset disappearing and another appearing in the same release. Get this wrong and every naming tidy-up looks like a wave of cancellations.
Write the sentence at diff time. Each change is stored as a finished sentence, generated when the comparison runs, from the two values being compared. Pages never reconstruct one from raw fields. That means a change reads the same everywhere it appears, and it cannot drift out of step with the numbers it describes.
Why this is the most valuable thing here
The asset directory on this site is a rendering of someone else’s public data, done carefully. Anyone with the file and some patience could produce it.
The change log is different. It only exists because someone kept the previous release and bothered to compare. It compounds: after five releases you have four comparisons, and the fifth adds a fifth. Nobody can reproduce it retroactively, because the old files are no longer the ones being published.
That asymmetry is worth stating plainly, because it shapes what this site is for. We are not trying to be a faster copy of the tracker. We are trying to be the place where you can see what the tracker changed its mind about.
What it is not
The change log records what the data did, not what the world did. Those are different, and conflating them produces nonsense.
A terminal moving from proposed to cancelled in a release usually means the project died, but sometimes it means the compilers reclassified something that had been dormant for years. Capacity moving from 5 to 5.5 Mtpa might be a debottlenecking, or it might be a better source for a figure that was always approximate. An asset appearing for the first time might be newly announced, or it might have existed for a decade below the tracker’s inclusion threshold.
Every entry therefore says what changed in the data and dates it to the comparison, rather than asserting an event in the world. The distinction sounds pedantic until you try to build an analysis on the other reading, at which point it becomes the whole game.
If you keep public data yourself
Two suggestions, cheap to implement and easy to regret skipping.
Keep the old file. Disk is free, and a release you did not keep is a comparison you can never make. This is the entire trick, and it is embarrassingly simple.
Diff on the publisher’s identifiers rather than on labels, and write down what you could not match. The unmatched list is where the real problems hide: an identifier scheme that changed, a merge upstream, a category quietly redefined. On this site those go into the ingest log and surface on the data sources page, because a diff that silently drops what it could not align is worse than no diff at all.