Methodology

Where entries come from, how they are written, checked and anonymised, and what the register does not claim. Most entries are found in public reporting by an automated pipeline. The rest are submitted directly. Both are described here in full.

How entries are made

Two routes lead into the register, and they are not equal in volume. Most entries are found rather than submitted.

Found in public reporting

An automated pipeline runs several times a day. It searches news and trade reporting for incidents at energy assets, discards what is out of scope, reads the articles it finds, writes a draft entry, checks that draft against the sources, and decides whether to publish. Where the sourcing is thin the entry is published with a provisional badge and rechecked over the following days, or held back until more reporting appears.

Language models do the writing and the checking. There is no point being coy about it, so here is exactly what they do and what they are not allowed to do.

• A cheap model screens each candidate from its headline and drops what is clearly not an incident at an energy asset. Anything it is unsure about is kept.
• A second model reads the article and writes the draft entry and the verified record from it.
• A third pass reviews that draft against the same sources and decides whether to publish, publish provisionally, hold, or reject. The reviewing model is not the model that wrote the draft.
• Every field must be supported by the cited sources. A model is never asked what it knows about an incident, only what a given source says. Where a source does not state something, the field is left empty rather than filled in.
• The disclosure rules below are applied at this stage and are not negotiable. An entry from public reporting names what the reporting names and never an individual person. A submission that cannot be anonymised is rejected rather than published.
• Entries are audited afterwards by a further pass that compares the published text against the sources and flags anything that overstates them.

What this means for you as a reader. Every entry lists the sources it was written from, so nothing has to be taken on trust. If an entry says something the source does not, that is a mistake and we want to hear about it through the corrections page. Automation is why the register can cover incidents across many countries daily. It is also why the sourcing on any single entry matters more than the size of the register, and why each entry says whether it rests on one source or several.

Submitted directly

Anyone can submit an incident through the submission form. Submissions go through the review sequence set out below under the confidential disclosure rule, so the published entry never identifies the site, the companies or the people. The editor sees every submission in the daily log and can correct or withdraw an entry. They are a small share of the register today and are the part we most want to grow, because they cover what never reaches the press.

Who is responsible

The register is run by an editor who sets the rules the pipeline follows, reviews what it produces, and answers corrections and takedown requests. Automation does the volume. Responsibility for what is published sits with a person, and correspondence is answered by a person.

Reference numbers

Every entry is given a number in the order it was written, EIR-0001 upwards. A number is issued once and is never reused or reassigned, so a link to an entry keeps working and a number quoted in a report always means the same incident.

This is why the highest reference number is larger than the number of published entries. An entry that is taken off the register keeps its number, and the number is not given to anything else. If you see a recent entry numbered above the published total, nothing is missing: the difference is entries that were removed. How many have been removed is on the statistics page, because a register that never removes anything is not being checked.

Entry types

The register contains two kinds of published entry, each clearly labelled:

• Direct submissions are entries from people with first-hand knowledge of the incident, operators, engineers, contractors, asset owners. They are anonymised before publication. Submitter identity is held in confidence and never published. Most entries today are found in public reporting; direct submissions are welcome and are held to the same standard of sourcing.
• Entries from public reporting are written from publicly available material: government health and safety publications, EPRI's public BESS Failure Incident Database, regulator findings, fire service statements, operator statements and news reporting. Each carries a link to its sources and names the site and the companies as those sources name them. They reflect only publicly confirmed facts and do not draw conclusions beyond what the sources state. Where an investigation is ongoing, the entry says so.

Almost every entry today is written from public reporting by the automated pipeline described above, which is how the register covers incidents across many countries daily. Direct submissions are the part we most want to grow.

Editorial principles

• Two disclosure rules, chosen by where the entry came from. An entry written from public reporting names the site, the place and the companies exactly as the reporting names them, and no further; it never names an individual person, and a name the source does not give is a guess and comes out. An entry from a first-hand submission is anonymised absolutely: no site, no company, no product, no person, and no identifying detail, in the public entry or the paid record. That second rule never bends.
• Descriptive, not investigative. The register describes what happened and what was learned. It does not assign blame, attribute fault, or substitute for regulatory investigation.
• Lessons-led. An entry without a clear lesson is not published. The register exists to share learning, not to log incidents for their own sake.
• Submitter confidentiality. The identity of submitters is held in confidence and never published.
• No commercial promotion. The register does not name, promote, or endorse any product, service, or vendor.
• Public benefit. Every published entry must contribute to industry-wide learning. Material whose primary function is commercial intelligence or competitive disclosure is rejected.

The review process for direct submissions

This sequence applies to incidents submitted through the form. Entries found in public reporting follow the automated route described above, which applies the disclosure rule for publicly reported incidents and the same standard of sourcing.

Provisional entries. Incidents found in public reporting are sometimes published before the full picture is available, so that readers hear about them early. These carry a "Provisional" badge and a short note saying what is confirmed and what is not yet known. The register rechecks provisional entries automatically over the following week, searching for further reports, and updates or confirms the entry when more sources agree. A provisional entry that turns out not to be an incident at an energy asset, or that duplicates an existing entry, is removed. The anonymisation rules apply to provisional entries in full.

1. Acknowledgement

Submitters receive an email acknowledgement on receipt, typically within one working day.

2. Initial screening

Each submission is screened for completeness, relevance, and immediate concerns:

• Is the asset class within scope (utility-scale energy)?
• Is the description sufficiently detailed to extract a lesson?
• Are there clear lessons-learned statements?
• Are there obvious identifying details that need removal or further anonymisation?

Submissions that fail screening are returned to the submitter with specific feedback. They may be revised and resubmitted.

3. Anonymisation review

Submissions that pass initial screening go through detailed anonymisation review. Identifying details are removed, including but not limited to:

• Operator, asset owner, site, and project names
• Vendor, equipment manufacturer, integrator, and contractor names
• Personnel names, role titles where they would identify individuals, and team names
• Specific dates beyond year
• Specific capacities, sizes, or geographic locations beyond broad bands
• Combinations of details that, while individually non-identifying, would together uniquely identify a site or party

4. Clarification (if needed)

If the submission requires clarification, to extract a clearer lesson, to verify technical detail, or to confirm anonymisation, the submitter is contacted by email. Clarification correspondence is held in confidence.

5. Publication

Approved entries are published with a unique reference ID (EIR-XXXX), structured fields, and three sections: what happened, contributing factors (where provided), and lessons learned. The submitter is notified by email when their entry is published and is provided with the public reference ID.

6. Correction and takedown

Published entries can be corrected or, in exceptional circumstances, taken down. Submitters may request a correction at any time. Third parties who believe a published entry contains identifying information that should not have been published may request a takedown review at editorial@energyincidentregister.com. All takedown requests are reviewed; corrections are logged on the corrections page and removals are counted on the statistics page.

Disclosure and anonymisation policy

There are two rules, and which one applies depends on where an entry came from, not on a judgement.

Publicly reported incidents. An entry written from published reporting names the site, the town or city, the country and the companies exactly as the reporting names them, and no further. It never names an individual person, of any role. A name the source does not give is a guess and comes out. Naming a company is a statement of what was reported, not a finding of fault. Any named party can ask for a correction or a right of reply through the corrections page.

First-hand submissions. Anonymisation is non-negotiable and never bends. The register's value to submitters depends on the trust they place in the process. Everything below applies to submissions.

What is removed from a submission

• All names of operators, sites, vendors, contractors, and personnel
• Project names and brand names
• Specific dates (only year is retained)
• Specific capacities (only size band is retained)
• Specific geographic locations (only broad region is retained)
• Any combination of details that would uniquely identify a site or party

What a submission keeps

• Asset type (BESS, solar, wind, grid infrastructure, hybrid)
• Incident category (thermal, electrical, control system, mechanical, gas release, near-miss, commissioning, other)
• Severity (near-miss, minor, significant, major)
• Year of incident
• Broad geographic region
• Lifecycle stage (commissioning, normal operation, maintenance, end-of-life)
• System size band (for example under 10 MW, 10 to 50 MW, 50 to 100 MW, 100 MW and above)
• Description of what happened, written to convey the technical event without identifying details
• Contributing factors
• Lessons learned

Where anonymisation is uncertain

Where it is not clear whether a combination of retained details could allow identification, the safe choice is taken: details are aggregated, generalised, or removed. The default is to publish less. An entry that loses some specificity but preserves the lesson is better than one that risks identification.

Boundary with regulatory reporting

The register is not a regulator. Submission to the register does not satisfy any regulatory reporting obligation that may apply to the incident under national legislation, employer policy, or contractual requirement. Submitters are responsible for ensuring that any required reporting to the Health and Safety Executive, the relevant national energy regulator, or any other competent authority has been completed.

The register is a complement to regulatory reporting, not a replacement for it. Where an incident is the subject of an active regulatory investigation, submitters should normally wait until the investigation is concluded before submitting, to avoid any conflict with that process.

What is rejected

• Submissions outside the asset scope (residential, behind-the-meter, small commercial)
• Submissions without clear lessons learned
• Submissions that cannot be sufficiently anonymised without losing the lesson
• Submissions whose primary function is commercial criticism, vendor disparagement, or competitive intelligence
• Submissions where the lesson is sector-specific to the point of being irrelevant to the wider industry
• Submissions where the submitter does not appear to have been authorised to share the information

Reporting

The statistics page is the register's live report: entries published, provisional, taken off after review, verified records, and pipeline health, updated daily. Corrections are logged on the corrections page. A summary of each year (submissions received, entries published and removed, methodology changes, governance and funding) will be published on the register once it has a full year behind it, the first covering 2026.

Limitations

These are the things the register cannot tell you. They are listed here rather than buried because a reader who does not know them will draw wrong conclusions from the counts.

• It records what was reported, not what happened. An incident that nobody wrote about is not in the register. Countries with open reporting and technologies that attract press attention are over-represented, and a company with a larger installed base will appear more often than a smaller one for that reason alone.
• English language sources dominate. Coverage of incidents reported only in other languages is thinner, and that is a gap we are working on rather than one we have closed.
• Counts are not rates. The register knows the capacity of sites that had an incident. It does not know the installed fleet behind them, so it does not publish incidents per gigawatt, and any figure of that kind taken from these counts would be wrong.
• A rising line usually means better collection. Recent years look worse than older ones largely because reporting and our own coverage have improved. Do not read a trend chart here as a trend in industry safety.
• Depth varies by entry. Some entries rest on one report and some on six. Each one says which, and the paid record shows every source used.
• It is not a regulatory record. Nothing here substitutes for a formal investigation, and the register does not assign blame or determine cause. Where a cause is given, it is what the cited sources reported.