Help for Editors

This page provides guidance on editing incidents.

General principles

The purpose of this project is to make information about caving incidents available in a modern and accessible format. For this to be done, incidents need to be categorised, and the metadata relating to an incident — such as the cave name or the type of group involved — need to be separated from the content of the incident report itself.

Editing UI

When editing an incident, fields which do not have a value, or are marked as None or Unknown, are highlighted in red. This does not mean that you are required to fill out these fields before proceeding. Rather, it is simply to draw your attention to data that is not held in the database. If you have reviewed the incident report and are unable to populate the field based on the data available, you can leave it as it is.

Data normalisation

Care should be taken to ensure that information relating to each incident is structured within appropriate fields. The Incident report field need not contain a header with the cave name, as the cave name is already stored in the incident metadata. Similarly, analysis of the incident should not be in the Incident report field as Incident analysis is a separate field. This normalisation of data is critical for producing a consistent and accessible database and the principle applies to all fields, not just the ones mentioned above.

AI generated data

Incidents are initially extracted from the original ACA Journal PDFs using OCR and then analysed by an AI model which extracts metadata and properly formats the incident report. AI models are prone to errors, and it is important that editors thoroughly check the data which has been generated.

The Incident report field is automatically compared to the original and flagged if it is significantly different, which helps to mitigate the possibility of this information being incorrect. In other cases, however, the AI is asked to make a subjective judgement, such as when populating the Category or Primary cause fields. Editors should take extra time in reviewing these fields and not hesitate to change them if they are incorrect.

Approval process

The incident approval process should be fairly straightforward and is designed to ensure that the data is correct and consistent. The process consists of either five or six steps, depending on whether the incident was processed by artificial intelligence or not.

When clicking the Approve reports menu option, you will be presented with the following pages:

  1. AI incidents — a page to check the date of the incident is correct.
  2. All incidents — a page to check the incident report, analysis, references and summary.
  3. All incidents — a page to add any injured cavers to the injured cavers table.
  4. All incidents — a page to check the incident metadata.
  5. All incidents — a page to check the incident flags.
  6. All incidents — a final review page before the incident is approved and published.

Each page will display either the original pre-AI-processing text, or the edited incident report, as a reference to help you determine if the data is correct.

It is strongly recommended to read the text at the top of each approval page, at least initially, as this changes depending on the type of incident being approved and provides guidance on what to look for.

Errors after approval

Incidents may still be edited after they have been approved and editors are encouraged to do so, should they spot any errors that need correction. Simply select the "Edit incident" option from the menu and make the necessary changes.

Editing an incident that has been approved will not 'unapprove' it, and the incident will remain published.

Incident metadata


The date of the incident. For some incidents, the precise date is not known, in which case the closest month or year should be selected, and the Approximate date checkbox used. For example, if we only know that the incident occurred in 1970, the date should be entered as 1970-01-01 and the Approximate date checkbox selected. If the incident occurred in June 1970, but no date is given, the date should be entered as 1970-06-01 and the Approximate date checkbox selected.


The name of the cave in which the incident occurred. If the cave name is not known, you must enter Unknown.


The state in which the incident occurred. Always use the full name of the state — New York, not NY. If the state is not known, the field must be left blank.


The full name of the county in which the incident occurred. If the county is not known, the field must be left blank.


The country in which the incident occurred. If the incident occurred in the United States, you must enter USA. For all other countries, the full name of the country should be used. If the country is not known, you must enter Unknown.


The overall category of the incident. Most incidents will fall into either the Caving or Cave diving categories.

Category Meaning
Unknown It is not possible to determine the category from the incident report.
Caving The incident involves a trip into a cave, mine, or other underground space.
Caving related The incident involves a cave, mine, or other underground space but is not typically caving related — for example a crime committed in a cave.
Cave diving The incident involves a trip into a cave, mine, or other underground space in which diving equipment was used.
Other The incident does not fit into any of the above categories. Enter more information in the Notes field if necessary.

Primary type

Almost all caving related incidents can be categorised into one of the types listed in the dropdown. Please select the one which best describes the incident. If the incident does not fit into any of the available types, you must enter Other.

Secondary and tertiary type

These fields are optional and should only be used if the incident can be categorised into more than one type. For example, if a caver suffered a fall which was caused by faulty equipment, the primary type would be Caver fall and the secondary type would be Equipment problems. In most cases, None will be selected.

Primary and secondary cause

These fields are a free form text description of what you feel the causes of the incident were. The secondary cause field should only be used when there was clearly more than one cause. Some examples of values found in these fields may be:

These fields are optional, but it is strongly recommended that you fill in at least the Primary cause field. If no cause can be determined, you must leave both of these fields blank.

Aid type

The type of aid (rescue) required for this incident. Unknown must only be selected if it is not possible to determine if aid was required or not, otherwise None must be used to indicate that no organised rescue took place. If SPAR (self-rescue) techniques were used but no external aid was required, None must be selected.

If more than one category is met, such as both Surface aid and Underground aid, the most severe category of intervention must be selected, which would be Underground aid in this case. If someone died and their body was recovered from a cave, Body recovery must be selected.

Field Meaning
Unknown It is not possible to determine type of aid delivered from the report.
None No organised rescue took place. Self-rescue may have taken place.
Surface aid Aid was provided outside of the cave, such as an ambulance attending after cavers exited.
Underground aid Aid was provided inside of the cave, such as an organised search party to find lost cavers, or an injured caver was hauled out.
Body recovery Someone died inside of the cave and their body was recovered by a rescue team.
Aid on standby A rescue team was organised, and may have gone to the cave, but no aid was required.
Other Any aid provided which does not fit into the above categories.

Group type

The type of group involved in the incident.

This field can be very subjective, and your judgement should be used, in particular when deciding between Cavers and Novice cavers or between Novice cavers and Non-cavers.

Group size

The total number of people in the underground group when the incident occurred — not the number of injured people or the number of people directly involved. Do not include any rescuers that were not part of the original group. If the group size is not known, you must leave this field blank.


This is the source of the information contained within the original incident report. It is not who submitted it to the ACA Journal, nor who wrote the report, but rather who provided the original information regarding the incident. For example, if the incident report is based on a report by a newspaper, the source would be Third party. If the source is not known, you must select Unknown.

Field Meaning
Unknown It is not possible to determine the source of the information.
Injured caver Someone who was underground and injured as part of the incident provided the information.
Member of injured caver's party Someone who was underground at the time of the incident but not injured provided the information.
Third party The information was provided by someone who was not present at the time of the incident.

Incident flags

A number of flags exist, to mark incidents which have certain characteristics. If an incident meets the criteria for a flag, the checkbox must be selected. You may select any, or none, of the flags for any given incident.

Flag Meaning
Fatality Someone died as part of, or as a result of, the incident.
Injury Someone was physically injured as part of the incident. This flag should also be selected if there was a fatality.
Multiple incidents The caving trip contained a series of incidents which are not directly related. For example, several falls, or two unrelated injuries. Some subjectivity may be required to determine if the incidents are related or not.
Rescue duration over 24 hours A rescue team was on-site at the incident for more than 24 hours. This does not include the time taken to travel to the cave or any time that a rescue team was on standby but not at the location of the incident.
Vertical incident The incident involved the usage of vertical caving techniques. Do not include simple free climbing in this category. As a general guide, this flag should be selected if some equipment, such as a rope, or ladders, was required to ascend or descend the cave.
SPAR Self-rescue (SPAR) techniques were used by the caving group to resolve the incident. This does not include any techniques used by any external rescue teams which attended later. An example of SPAR would be a caver who fell and injured themselves but was able to exit the cave without assistance from their group, or a group which set up a hauling system themselves. This flag must be selected if the SPAR was unsuccessful and organised rescue later took place.

Incident text fields

Incident report

The original text of the incident report from the ACA Journal or submitter of the incident. This field should contain a factual description of the events that took place underground only and should not contain any analysis or references to external publications or resources.

Incident analysis

Any analysis of the incident which was included in the original publication. Do not provide your own analysis.


A short (maximum 400 characters) summary of the incident. This should be a factual description of the incident, and you may provide the summary yourself. Examples of short summaries may be:


A list of references to external publications, resources, or websites which contain information about the incident. This could be caving journal articles, newspaper websites, or other sources of information such as names of cavers who reported the incident. If the reference is to a printed publication, the name, author, date, year and page number must be provided if available.

Each reference must be entered on a new line.


Any other information which may be relevant to someone reading the incident. Some examples may be:

Editing notes

The editing notes field is only visible to people who are signed in as an editor of the database. It should contain information relating to editing only. If the editing notes field is populated, it will be considered as having items to action and it will not be possible to approve it. An example of text contained in the editing notes field may be: