Revision and Corrections Log

Published methodology revisions and the planned automated Energy Atlas asset-change log.

This public log records material revisions to WorldMonitor datasets and methods. The automated Energy Atlas asset-change writer remains planned. What ships today on the Energy Atlas includes the evidence bundles inside each RPC response (ListPipelines, ListStorageFacilities, ListFuelShortages, ListEnergyDisruptions), and the methodology pages that describe how public badges are derived from those bundles. Until the asset-change writer ships: GetPipelineDetail.revisions and GetStorageFacilityDetail.revisions return empty arrays, and there is no automated correction-intake path.

Published revisions

Effective date	Product	Revision	Published effect
2026-06-01	Country Resilience Index	P1-1 pillar aggregation correction. Pillar scores now apply each domain’s design weight inside pillar aggregation. The 2026-05-28 snapshot used the earlier coverage-only member aggregation and remains a labelled historical capture.	Live score, ranking, history, and interval cache generations changed together. The 2026-08-29 full-universe capture is the first published country snapshot after this correction. See PR #4021.

The crawlable CRI snapshot workflow is scheduled for the first day of each month (17 5 1 * * UTC). It captures the credentialed full-universe ranking, rebuilds the crawlable corpus and sitemap, and opens a pull request for review. Off-cycle captures also ship when a methodology correction needs a new full-universe artifact. The current published snapshot is resilience-ranking-2026-08-29.json (captured 2026-08-29, after the P1-1 pillar-aggregation correction), not a first-of-month run.

Energy Atlas automated revision log (planned)

WorldMonitor’s Energy Atlas publishes evidence bundles — not opinions — for pipelines, storage facilities, fuel shortages, and disruption events. A deterministic, versioned classifier turns those bundles into public badges (flowing / reduced / offline / disputed for assets; confirmed / watch for shortages).

When the classifier goes live, every time it changes a public field — because evidence updated, because staleness decayed a badge, because a new classifier version re-derived an old asset, or because an operator/regulator-submitted correction was applied — it will write an append-only entry here.

This is the designed asset-level audit record. The evidence registries are forward-looking snapshots. The automated log will record how each status changed.

Planned data shape

Each entry is planned as a row with the following fields:

{
  date: string,                 // ISO8601 — when the change was written
  assetOrEventId: string,       // matches an id in the pipeline / storage / shortage / disruption registry
  fieldChanged: string,         // e.g. 'publicBadge', 'physicalState', 'severity', 'evidence.sanctionRefs'
  previousValue: unknown,       // value before the change
  newValue: unknown,            // value after the change
  trigger: 'classifier' | 'source' | 'decay' | 'override',
  sourcesUsed: string[],        // URLs cited by the classifier for this change
  classifierVersion: string,    // version that produced newValue (e.g. 'badge-deriver-v1')
}

The matching proto surface lives at GetPipelineDetail.revisions and GetStorageFacilityDetail.revisions. Both currently return empty arrays by design — the handlers document “Revision log arrives in a post-launch release” in their code comments rather than pretending the surface is live.

Planned trigger vocabulary

• classifier — a routine classifier pass re-derives the field from the current evidence bundle. Expected to be the most common trigger once live.
• source — a new evidence source arrives (regulator filing, operator press release, sanction list update) and the classifier re-derives accordingly.
• decay — the evidence is older than the staleness window (14 days for registry fields, 30 days for shortage evidence) and the classifier demotes a non-positive badge to disputed or watch.
• override — a break-glass manual override is applied. Reserved for demonstrably-wrong classifier outputs flagged by readers. Overrides will carry the same sourcesUsed discipline as classifier entries.

What is live today

• Published methodology revisions. The table on this page records changes that affect public datasets and their interpretation.
• Evidence bundles on every asset. Click any pipeline, storage facility, or shortage pin on the Energy Atlas and you see its full evidence bundle: physical state, commercial state, operator statements (with URL and date), sanction references (with authority + list ID + URL), classifier version and confidence, and the timestamp of the most recent evidence update. This is the primary audit surface today.
• Public methodology pages. The derivation rules, staleness windows, and evidence-threshold specs are all publicly documented:
  • Pipeline Registry
  • Storage Facilities
  • Fuel Shortages
  • Disruption Event Log
  • Chokepoints
• Versioned classifier output. Every RPC response carries a classifier_version field. A reader can pin expectations to a version today even though the revision-log history-of-versions surface isn’t yet published.

What is not live today

• Automated Energy Atlas asset-level entries. This page will list those rows after the classifier ships.
• An automated correction-intake pipeline. If you spot something wrong, use the feedback channels at worldmonitor.app or open a GitHub issue at the public repository. Corrections are not yet on the classifier’s path — they’re handled manually today.
• The override-trigger entry writer. Same dependency: ships with the classifier.

Verifying a badge today (pre-classifier)

Until the revision log is live, the audit path for any status on the Energy Atlas is:

1. Open the asset drawer (click the pipeline / storage dot / shortage pin).
2. Read the evidence bundle — every source is linked with publication date and authority (regulator / operator / press / satellite).
3. Check the methodology page for the asset class — the derivation rules are deterministic and versioned.
4. If all evidence is current and the public badge still looks wrong after walking the rules, open an issue on the public repository with the asset id, the current evidence bundle, and your reasoning. The manual review path will seed override entries once the revision log ships.

Why document this surface before it ships

Two reasons to publish the spec before the writer lands:

1. Contract stability. The shape of revisions in GetPipelineDetail.revisions / GetStorageFacilityDetail.revisions is part of the RPC contract that agents and MCP clients consume. Documenting it now means downstream consumers can code against the stable shape before live data arrives.
2. Policy signalling. Evidence-first classification only works if the audit trail is committed-to in public, not treated as an internal implementation detail. Publishing the planned shape and submission policy ahead of the writer is the commitment.

Neither reason justifies overstating the current state. When automated asset-level entries start appearing, this page will replace the status callout with the last update time.