CoralCache: a virtual coral core repository for transparent and reproducible annual growth rate analyses

As science fields enter the Big Data revolution, open-access repositories are essential for addressing larger-scale questions than are possible for single researchers by making data findable, accessible, interoperable, and reusable (FAIR). Furthermore, transparent data and code are increasingly important for reproducible research, especially for data types that inherently require subjective human interpretations. These ideas are applicable to coral sclerochronology, as the field has long been characterized by individual researchers collecting and analyzing coral skeletal cores from their study sites without substantial data sharing or archiving of the core images to meet FAIR principles. Here, we present CoralCache, a virtual coral core repository that not only archives image datasets (i.e., digitized X-rays and computed tomography scans), but also observer interpretations of the density banding patterns. CoralCache is linked to a graphical user interface, CoralCT, which together offer a way forward for coral growth rate analysis that is reproducible and collaborative. The data organization systems presented here could also be readily applied to related archives such as tree rings or bivalve shells.

The data are available at https://doi.org/10.5281/zenodo.17208911 (DeCarlo et al., 2025a) and https://doi.org/10.5281/zenodo.19410281 (DeCarlo, 2026).

1 Introduction

The density bands within coral skeletal cores are the “tree rings of the sea”. As massive- and columnar-morphology coral colonies build their skeletons over decades to centuries, they typically construct alternating bands of relatively high and low density on an annual basis (Knutson et al., 1972; Ma, 1934). Along with providing age-model constraints to researchers analyzing skeletal geochemistry to reconstruct environmental variations, these bands also reveal the annual growth history of the colony (Hudson, 1981; Ma, 1934). The growth rates themselves can be used as environmental proxies and indicators of the relative health of the colony in response to long-term trends of acidification and warming or to acute stressors such as pollution and bleaching episodes (Barkley et al., 2018; Barkley and Cohen, 2016; Baumann et al., 2019; Cantin et al., 2010; Cantin and Lough, 2014; Carilli et al., 2009; Carricart-Ganivet et al., 2012; Castillo et al., 2012; Cooper et al., 2008, 2012; Courtney et al., 2020; De'ath et al., 2009; DeCarlo et al., 2024; Felis et al., 2009; Lough and Barnes, 2000; Mallela et al., 2015; Manzello, 2010; Mollica et al., 2019; Rodgers et al., 2021; Saenger et al., 2009; Samperiz et al., 2025; Vergotti et al., 2025).

Despite the value of coral skeletal core archives, centralized or systematic data sharing and archiving practices are lacking. Whereas other core archives, such as deep-sea sediment or fossil reef cores, have large, centralized facilities for physically storing the cores (e.g., International Ocean Discovery Program (IODP) Core Repositories), no such repository exists for coral cores. Rather, coral cores are physically stored by individual researchers, university archives, or in some cases, by government science agencies (Dassié et al., 2017; Oberle et al., 2026; Williams et al., 2017). Yet, the daunting effort and costs necessary to centralize physical core storage are not necessary for coral growth studies because X-ray or computed tomography (CT) images from coral cores (hereafter “core image data”) effectively capture the annual density banding patterns that can be interpreted for past growth rates. This makes digital data archives an effective, low-cost alternative to physical archives of cores for studies of coral growth variability. Core image data are also often used to screen cores for clear growth axes and early diagenesis prior to geochemical sampling (DeLong et al., 2013; Fouke et al., 2021). Further, these images provide critical information for age modelling, such as age-depth tie points, which contribute to age model refinement. Often these raw images and age-depth models are not publicly available, limiting meta-analyses among sites (Thompson, 2022). Many coral geochemical and growth rate datasets are archived at the National Centers for Environmental Information (NCEI) World Data Service for Paleoclimatology (https://www.ncei.noaa.gov/products/paleoclimatology, last access: 4 September 2025) and the World Data Center PANGAEA (https://www.pangaea.de/, last access: 4 September 2025) (Felden et al., 2023). The paleoclimate community has also recently produced the PAGES (Past Global Changes) CoralHydro2k database hosted at NCEI, a global compilation of coral δ¹⁸O and $\mathrm{Sr}/\mathrm{Ca}$ proxy records of tropical ocean hydrology and temperature for the Common Era (Atwood et al., 2026; Walter et al., 2023). However, without a comparable image archive, re-analysis and interpretation of these valuable datasets is limited to that obtainable from the original published accounts.

We present CoralCache, a virtual coral core repository with global coverage for archiving coral skeletal core image datasets. This repository fills a key gap by enabling researchers to transparently archive and share the raw core density image datasets and the visual analyses of those images, rather than simply the summarized growth rate data, which on their own cannot be traced or precisely reproduced. CoralCache is designed to meet the data-sharing principles of findability, accessibility, interoperability, and reusability (FAIR) (Wilkinson et al., 2016). Researchers can search the entire core list for suitable cores to address a particular question or that are from a certain region prior to expending time and resources to collect new samples. We describe here the standards and mechanisms by which CoralCache achieves these steps forward in archiving and transparency.

2 The CoralCache repository

The foundation of the CoralCache repository is storing CT scan and X-ray image datasets of coral cores, combined not only with output growth-rate data, but also with the observer interpretations of the banding patterns in each core. This is achieved through the repository being linked to a graphical user interface, called CoralCT (Fig. 1; DeCarlo et al., 2025b), that allows users to trace the annual bands in the images (the reader is directed to reference (DeCarlo et al., 2025b) for additional example images of coral skeletal cores and how users interact with them in the CoralCT application). CoralCT pulls image datasets from the CoralCache repository and automatically sends observer band traces back to the repository. These features are built into the CoralCT application; therefore, no extra steps are required for observers to share their annual density-banding interpretations. While there are options to limit public access to pre-publication datasets, the concept for the CoralCache repository is that, upon publication, authors will be able to readily share the raw core images, the output growth rate data, and the exact interpretations they made in generating those growth rate data. This will allow other researchers to review, reproduce, or revisit growth rate analyses of prior works, and even to compile growth rate datasets of potentially hundreds or thousands of cores from across the world. The output data include annual skeletal bulk density, linear extension, and calcification rates, all with assigned calendar years based on the observer's interpretation of the date of the topmost band relative to the core collection date. Important features such as “stress bands” (Barkley and Cohen, 2016; Cantin and Lough, 2014; DeCarlo, 2020; DeCarlo et al., 2020; DeCarlo and Cohen, 2017; Mallela et al., 2015) can be annotated on publicly-visible snapshots and described in a notes section of the output files. The methods used to describe these parameters are published in previous works (DeCarlo et al., 2015; Duprey et al., 2012; Helmle et al., 2002; Lough, 2008), including the measurement procedures in the CoralCT application (Fig. 1; DeCarlo et al., 2025b). The present work focuses on archiving and sharing these datasets via CoralCache, which exists as an online data storage system accessible via secure file transfer protocol (SFTP).

Figure 1 Default display of a partially-analyzed coral skeletal core in the CoralCT application. Sliders found on the right side of the screen are used to adjust the cores appearance to increase visual clarity of annual density bands. In the core image, clear alternations of high-density (bright) and low-density (dark) bands are visible, with a pair of high- and low-density bands together representing one year of growth. The yellow lines and digits indicate user-defined bands. On this core, the observer has identified bands as the darkest part of low-density bands. In the axial image toward the lower-right, the current slice location is displayed by the red box, and yellow dots indicate the distribution of tie-points for the present band (band 17 in this case). Additional descriptions of the methods of the CoralCT application can be found in DeCarlo et al. (2025b).

2.1 Metadata and data standards

Several different file types are associated with the CoralCache repository. Core image data can be either 3-dimensional (3-D) CT scans or 2-dimensional (2-D) X-ray images. CT scans must be in Digital Imaging and Communications in Medicine (DICOM) format (.dcm file extension), and the files must contain embedded within them at least the following metadata elements that are standard to .dcm files: PixelSpacing (in millimetres [mm]), either SliceLocation or ImagePositionPatient (in mm), and both RescaleSlope and RescaleIntercept (i.e., to convert image data to the standard Hounsfield Unit/HU scale; Hounsfield, 1973). The CT scans must be in a stack of images in which each image file is an axial slice (also known as a horizontal or transverse slice). If necessary, the CoralCT application has tools that allows users to (1) convert CT scan data from .tiff to .dcm, (2) rotate .dcm stacks if the individual files are not already in the axial plane, and (3) resize .dcm files if the file size of the dataset is larger than desired (e.g., loading and response times in the application increase with file size). X-ray images must be in .tiff format, and they must include digital pixels per inch (dpi) as metadata. We developed a User Guide that includes a description of file submission requirements that allows data contributors to ensure they understand their data and metadata prior to submission (DeCarlo, 2026).

All cores must contain basic sample collection metadata. These requirements include month and year of collection, latitude, longitude, depth, and coral genus. Additional metadata, described below, are preferred for optimal calibration of skeletal density. For CT scans, data submitters may have developed their own calibration between HU and skeletal density (DeCarlo et al., 2015; Manzello et al., 2014), and if so, that can be added into the metadata linked to each core and used for the final data output from CoralCT. CoralCache also stores user-uploaded CT scans of density standards, which are then available for density calibration of specific cores. For example, if a user scanned three density standards alongside regular cores, they could submit the scans of those three standards and have them saved on CoralCache with a group name that links them to the appropriate cores. In CoralCT, the user can then derive the mean HU of each standard and create a calibration equation against known density, and this equation can be applied to the metadata record of any cores for which that user is listed as a responsible person. Different standard sets and/or calibration equations can be applied to each core. While there is a default calibration equation (DeCarlo et al., 2015), conducting careful density calibrations with suitable standards is essential for accurate density and calcification rate data, especially if the CT scan is not on the regular HU scale (i.e., air is −1000, water is 0, with maximum values of around 2000 for pure CaCO₃) (Hounsfield, 1973). One way to validate density calibrations is to weigh the physical core and calculate its density from the measured mass and CT-derived volume (an output from CoralCT), and then to compare this density value to the whole-core HU-derived density output (also a CoralCT output). Density calibration for X-rays is more difficult, as there is no standard scale, and the brightness of the images will depend on the settings of the X-ray machine as well as the thickness of the coral slab. Data submitters must develop their own calibration equations, and there are a variety of approaches for this, such as using wedges of aluminium or Tridacna spp. shells, pressed coral powders, or via gamma densitometry (Duprey et al., 2012). X-ray images should also either be corrected for the heel effect and the inverse square law (Duprey et al., 2012) prior to submission, or described in the “notes” section of the metadata that these corrections were not yet applied.

Besides core image data, the observer band maps are stored as .mat files. These are default files for the MATLAB language in which CoralCT is written, but they do not need to be opened directly by a user. It is important to note that CoralCT runs in MATLAB Runtime, which uses the MATLAB language but does not require the user to have MATLAB installed or any form of license. For CT scans, the .mat files have the same number of rows and columns as the CT scan they are linked to (i.e., each DICOM image contains pixels in rows and columns), and the third dimension represents each band that has been identified. The data stored within this 3-D array are the vertical pixel indices that were clicked by the observer (pixels downward from the top of the core, beginning at index 1), with zeros filled in everywhere else. The .mat files also contain the following settings used by the observer when marking the bands (DeCarlo et al., 2025b): image brightness and contrast, the size of the filter used for smoothing bands, the projection type used (e.g., minimum or mean), the slice thickness in mm, and the angle at which the core was rotated (if applicable). For X-rays, the .mat file likewise contains the band coordinates, but with rows representing the horizontal pixel index of the core image, columns representing the band numbers, and the value of entries representing the vertical pixel index from the top of the image.

Finally, output growth rate data are stored as comma separated values (.csv) files. These contain key metadata about the core, the username of the observer, any notes made during analysis, and any acknowledgements or citations linked to the core. The growth rate data are presented as annual linear extension (in centimeters per year [cm yr⁻¹]), density (grams per cubic centimeter [g cm⁻³]), and calcification (grams per centimeter squared per year [g cm⁻² yr⁻¹]). CoralCT measures extension and density, and then calcification is calculated as the product of density and extension (Barnes and Lough, 1993). The calendar years assigned to the annual data are based on counting backward from the observer's interpretation of the first calendar year measured. This is typically the year of collection or the year prior, depending on whether there is a complete or partial band formed at the top of the core (see D'Olivo et al., 2013). These .csv files are consistent in terms of the rows and columns where each piece of metadata and data are placed, enabling the development of automated computer codes for reading information from large sets of these files. Furthermore, the CoralCT application contains an option to export data in Linked Paleo Data (LiPD) format (McKay and Emile-Geay, 2016).

2.2 Data storage and access systems

The organization of the combined CoralCT–CoralCache system is more complex than a typical data repository for two reasons. First, it is an interactive system in which CoralCT allows users to not only access data in the CoralCache repository, but also continually add traceable interpretations (i.e., band maps) to CoralCache. Therefore, continuous refinement of the banding pattern can be done across multiple sessions. This precludes a system where the files are read-only and users are allowed to access the full repository directly. Rather, files must be both readable and writable to allow the continual addition and editing of users' band maps. Because at least some files must be writeable, users cannot have direct access to the entire data storage because band maps could be inadvertently edited, moved, or deleted. Second, the CoralCache repository holds datasets for which CoralCT analyses are incomplete or not yet published. Since most researchers will not want these data publicly accessible until after publication, there cannot be public access to the entire data storage.

Effective use of the CoralCache repository, while maintaining the data security constraints, is enabled through two mechanisms (Fig. 2). First, access to the main data storage is moderated by users logging in with unique usernames (see section below) and only reaching data through the CoralCT application, in which only certain actions are allowed. For example, users can download only publicly accessible datasets or those in which the core responsible person has granted access to specified users. Similarly, users can access and edit band maps linked to their username, but they can only view (not edit) other users' band maps. The CoralCT application includes buttons to download openly accessible datasets, including options for bulk downloading of all output growth-rate data in entire regions, or all growth-rate datasets linked to a particular core (i.e., from multiple observers). However, these prescribed actions may limit the efficiency of some research applications, such as bulk analysis of all growth-rate files or comparisons of band maps among observers. For this reason, the second mechanism is that there is a copy of the CoralCache repository that contains all publicly accessible files, including the core image data, output growth rate files, and the band-map files associated with the output files. We run a script (DeCarlo, 2026) separate from CoralCT that updates the CoralCache public copy every month by automatically transferring any new or updated files associated with cores that are tagged as publicly accessible from the main data storage. Since these are only copies of the original files and are not part of the interactive system linked to CoralCT, there is direct and unrestricted access to this data storage (DeCarlo et al., 2025a). With this approach, end-users are able to develop automated scripts that, for example, query the data storage for all files, or all files from a certain user, or all band map files from a particular region, etc. The two-tiered access approach effectively balances user convenience with essential data security. See Data Access section for information on accessing the data storage.

Figure 2 Schematic of the CoralCache system, a virtual repository designed to store and share data on coral skeletal cores, and its integration with the CoralCT application.

2.3 User registration and data submission options

The interactions with the main data storage require users to register in the CoralCT application. This approach is necessary to track which observers have identified bands in specific cores, enabling assessments of observer agreement scores (see below) or potentially weighting different observer contributions. No personal information is required other than an active email address to receive a temporary password. Users are then able to change their password directly in the CoralCT application. By requiring active email addresses, we can subsequently notify all users about updates to the application or general progress notes related to the CoralCache repository. The registration system also enables the band maps (.mat files) to be linked to usernames, so that users can save their work and then re-open a core to continue their work at a later time or from a different computer. Likewise, access to specific cores can be restricted to certain usernames by the responsible person of each core to protect the sharing of datasets prior to publication.

Data submission can proceed by either a flexible submission option or direct submission. In the flexible option, users may submit folders of data or zipped files for DICOMs, or any image file type for X-rays, along with a completed metadata template. Flexible data submissions go to the CoralCT data management team at Tulane University, who subsequently rename files to meet the application requirements and organize them on the CoralCache repository. As long as all of the essential image data and metadata are provided, the flexible submission option is relatively easy for data submitters because they do not need to follow strict file naming or organization requirements. Alternatively, data contributors may use direct submission, which requires DICOM data to be zipped and named in a certain way, X-rays to be submitted in .tiff format, and the metadata template to be completed in a precise way (see description in User Guide, DeCarlo, 2026). If done correctly, the files are directly added to CoralCache and are immediately available for analysis.

Figure 3 Map showing the locations of all coral skeletal cores (pink dots) currently stored on the CoralCache repository.

2.4 Current status of the repository

Since its inception in 2024, 133 users have registered in the CoralCT application and together have added 1388 unique cores from across the tropics to the CoralCache repository (Fig. 3). The cores are mostly from living coral colonies, although some were collected from dead colonies with geochemical dating providing a top-of-core date. Others are reef-framework cores that contain fragments of skeletons from corals that built the reef over centuries to millennia. There are 38 489 total annual band traces that have been processed into output growth rate files from 600 measured cores (Fig. 4). Currently, 496 cores are fully publicly accessible, 334 are available for anyone to measure but with output data restricted to the responsible person of those cores, and 558 cores are restricted to access only by the responsible person and other assigned usernames.

Figure 4 Current status of the CoralCache repository. (A) Total numbers of cores in the repository per region (black) and numbers of cores that have been processed for growth measurements (hatched). (B) Total band measurements including multiple observers per core (black) and excluding multiple observers per core (i.e., using the single longest record per core; hatched).

The directory of cores and associated metadata is viewable in the CoralCT application (Fig. 5). Even though cores may be completely restricted from access by anyone other than the responsible person, all cores are listed in the publicly viewable directory. This enables the community of researchers to know what cores have been collected from a region of interest, potentially helping to spur collaborations via sample discovery and/or avoiding duplicate research efforts and oversampling of Threatened or Endangered coral species. The core directory also lists how many observers have completed analysis of each core, allowing interested researchers to identify data gaps or potential collaborators in need of band interpretations for their cores.

Figure 5 An example section of the coral skeletal core directory currently available on the CoralCache repository showing basic collection metadata.

2.5 Inter-observer agreement scores

The automated saving of observer band maps by username enables calculation of inter-observer agreement scores, which could be used as quality control of output data given that un-restricted cores can be analyzed by any registered user. We describe here a method for how these scores are currently calculated from CoralCache data and displayed in CoralCT, but we note that other approaches could be developed from data in the public copy of the repository. Additionally, it is important to highlight that these are simply agreement scores, not necessarily a measure of accuracy. They are included for potential future meta-analyses including growth rate data from cores that have been interpreted by multiple observers, as data analysts may choose to weight or otherwise select individual observer data based on their agreement with other observers across all cores. Thus, beginning in CoralCT version 2.6.5, the output growth rate files contain the inter-observer agreement score (if one exists) for that observer.

In the first step of calculating inter-observer agreement scores, we search through all cores in CoralCache and only use data from cores that have at least three observers. Therefore, not all observers will necessarily have an inter-observer agreement score because they may not have interpreted bands on any cores with two or more additional observers. For each core, we calculate an among-observer variance score as follows. For each band in a core, we identify the area over which all observers traced that band. Some observers may have traced across the entire area of the core, while others may have identified a smaller region; therefore, we focus only on the overlapping horizontal extents (Fig. 6). We then calculate the standard error of the mean of vertical placement of the band for all the overlapping pixels in the horizontal extent. If the band placement by observers is randomly distributed about a mean position, then the standard error of the mean should decrease with more observers, although outlier placements could cause the standard error to increase. We then average the standard error among all bands in the core, and call this “among-observer variance” (i.e., one value per core for a given set of observers).

Figure 6 Illustration of how different observers identify varying horizontal extents of each band of a coral skeletal core in CoralCT, a graphical user interface. The left image shows a 3-D plot of the surfaces identified by four observers for a single band. The band is plotted in a different colour per observer, set to 50 % transparency, and vertically exaggerated 2× to improve clarity. The right image shows a “top-down” view with colours indicating the number of observers that traced the band across the horizontal extent of the CT scan. The lightest blue colour shows where all four observers overlapped, and this area would be used in the inter-observer agreement score calculations.

The second step in calculating the inter-observer agreement score is to identify the set of observers that minimizes the among-observer variance. Because standard error is the standard deviation divided by the square root of the number of observers (n), in this case, there will be a tendency for the optimal set of observers to favour retaining, rather than excluding, individuals. However, there is also the possibility that a small number of observers agree very closely even if they diverge from most other observers, and this set of the small number of observers could produce the smallest among-observer variance. For this reason, we set a requirement that the optimal set of observers must include at least half of the total observers. For cores with seven or fewer observers, we calculate among-observer variance for every possible combination of $n/\mathrm{2}$ or more. However, some cores have been interpreted by many observers, up to 26 observers in some cases, which equates to over 10 million possible combinations. For these cores (those with more than seven observers), we use a minimization function that searches the parameter space to find the minimum value of among-observer variance. We developed this function by inputting a list of observers (i.e., $\mathrm{1},\mathrm{2},\mathrm{\dots }n$) and allowing the search algorithm to adjust these numbers. We then round the adjusted numbers and retain the unique integers of observers. Effectively, this allows the search algorithm to shift the integers away from “poor” observers and toward “good” observers so that the unique set of integers contains only the “good” observers. We use the simulated annealing function (simulannealbnd) in MATLAB to perform this search because it is effective at initially sampling a wide parameter space and then narrowing into the best solution with smaller adjustments. We allow 250 total function evaluations before reaching the optimal set of observers. We note that it is technically possible that there is a better set of observers beyond the sampled parameter space, but in general, the simulated annealing approach should converge on relatively good sets of observers with low among-observer variances.

The final step is to calculate the inter-observer agreement scores for each username. We calculate this as the proportion of possible cores (those with three or more observers) that an observer interpreted in which that observer's band map was retained in the optimal set of observers. For example, if a user traced bands in 10 cores that met the requirement of three or more observers, and the user's bands were included in the optimal set of observers for seven of those scores, their inter-observer agreement score would be 0.7. We note again that this score represents agreement, not necessarily accuracy, and that there is no set way to interpret or use this score. Rather, it is a potentially useful metric for developing statistical approaches to synthesizing multiple observers per core, and thus it is included in the CoralCT output files. Even if subsequent data analysts develop different approaches, a key step forward in the field is that there can be multiple observers per core, and it is possible to develop quantitative metrics of the skill of the observer(s), which has not previously been possible in sclerochronology or in related fields such as dendrochronology.

The inter-observer agreement scores are automatically updated once per month. We note that because these scores depend on interactions among all other users' band maps, a particular user's score could increase or decrease even without them making new band interpretations. The score printed in the output growth rate files is that user's inter-observer agreement score at the time they processed that particular core, but subsequent analyses could re-calculate the inter-user agreement scores to suit a particular research question.

2.6 Observer confidence scores

At the time that observers choose to process growth rates from their completed band mapping, they have the option to assign a confidence (0–10) score to that core. These scores are saved in the output growth rate files. Similar to the inter-observer agreement scores, there is no prescribed method for how to use the confidence scores in subsequent analyses. However, data analysts could incorporate the confidence scores in various ways. For example, the contribution of each core to a climate reconstruction based on a network of cores could be weighted relative to the confidence scores for that core. Intuitively, higher confidence in interpreting bands by observers is likely to indicate more accurate data. Since observers may differ in their system for assigning relative confidence scores, data analyses incorporating these scores would likely benefit from standardizing the scores per observer. Full access to the public copy of the data storage is again key for enabling automated scripts for pulling these scores for all observers involved in any particular study. Incorporating observer confidence may further enhance data quality and reliability in large-scale syntheses.

2.7 Sustainability

A variety of approaches were used to ensure long-term sustainability of the repository. In earlier versions of the CoralCT application, only the flexible data submission option was available, and nearly all data currently in the repository were submitted in this way. While DICOM is a standardized file format, most data submissions required some organization steps, such as converting submitted CT scan .tiff files to .dcm, rotating the images onto the axial plane, or resizing files, in addition to zipping the files and creating correctly named folders on the data storage. The previous approach, in which the CoralCT data management team performed these organization tasks, was necessary because most data submitted thus far have come from works completed before the CoralCache repository was built in 2024. Data contributors mostly sent data upon request for archiving purposes, and many contributors were no longer active in coral core analysis, so minimizing time requirements for data contributors was crucial to achieving community buy-in. Future data submissions will likely more commonly be from users who plan to use CoralCT for analysis of their new cores, in which case it is reasonable for the data submitters to carefully read the User Guide to learn how to suitably organize their data for the direct submission option. Importantly, the direct submission option requires no effort from the CoralCT maintenance team, so the repository can continue to grow and be used for new datasets regardless of continued personnel support.

Automated monitoring scripts have also been implemented to reduce time requirements for active management of the repository by the CoralCT team. The data storage is automatically queried for several tasks. If a user forgets their password, they may click a button in the CoralCT application, and a new password is created and emailed to the user. New user registrations are currently approved manually as a means to avoid programmed bot (i.e., non-human) registrants, but the monitoring scripts have options for turning on automating approval for all or certain email addresses such as .gov, .ac, or .edu (DeCarlo, 2026). Additionally, the entire repository is backed up onto two separate external hard drives every three days. Finally, once per month, all open-access files are automatically sent from the main data storage to the public copy, and inter-observer agreement scores are updated. These monitoring scripts are provided in DeCarlo (2026), with only the main data storage login credentials redacted. Likewise, the code underlying CoralCT is available at https://github.com/tdecarlo19/CoralCT (last access: 13 May 2026), and has nearly full functionality except that it is linked to a separate data storage with only example datasets.

The whole repository can run with minimal human effort for maintenance. Currently, the CoralCT team is needed to handle datasets submitted via the flexible option, confirm new user registrations without .edu email addresses, and ensure the monitoring scripts are running. Handling data submissions is by far the most time-consuming task because it can involve problem-solving, depending on the state of submitted files. However, if this support were to cease, the organization steps would simply shift onto data submitters without any loss of repository functioning. If needed, the remaining tasks of confirming new users and running automation scripts could readily be handed over to another team or organization. Beyond the publicly available scripts, only data storage login credentials are needed to run the system. As described above, refraining from public release of direct access to the main data storage is a necessary requirement of the interactive link between the CoralCT application and CoralCache repository, and for the option to keep pre-publication datasets in the repository.

3 Data availability

The data are available via the public copy of the CoralCache data storage. The current version of CoralCache is available at https://doi.org/10.5281/zenodo.17208911 (DeCarlo et al., 2025a). Additionally, login information to access all of the data via a FTP client is available at https://doi.org/10.5281/zenodo.19410281 (DeCarlo, 2026).

4 Code availability

The code for the CoralCT application and its interactions with the public copy of the CoralCache data storage is available at https://doi.org/10.5281/zenodo.20159538 (tdecarlo19, 2026). This code has been slightly redacted to remove features associated with usernames and access to the private, pre-publication component of the data storage. The desktop CoralCT application is available following DeCarlo et al. (2025b).

5 Conclusions

Historically, coral core image data have not been shared publicly or placed in a repository, and analyses of growth banding in those cores have largely been opaque and thus difficult to reproduce. While this was incompatible with the intent and arguably the rule of data sharing requirements of most funders and publishers, it was understandable given the lack of a repository for these types of data, especially the large file sizes associated with CT scans. CoralCT and CoralCache together remove these barriers to data archiving and transparency. The data organization and sharing system also meets the FAIR principles (Wilkinson et al., 2016) because the metadata in the core directory are consistent and the datasets are findable; post-publication data are readily accessible through the CoralCT application; output files are consistently formatted so that they are interoperable across software platforms; and the data are reusable because previously published datasets in CoralCache can be gathered into regional- or global-scale meta-analyses. With a graphical user interface and an extensive User Guide, the application and repository are easy to use. Furthermore, CoralCache enhances the robustness of coral growth analyses by enabling objective evaluation of inter-observer agreement and confidence in band interpretations. This additional layer of transparency strengthens the credibility of research findings and enables Big Data syntheses of growth variations in hundreds or thousands of cores. While we do not intend to prescribe a single method, the CoralCT application does offer ease-of-use for 2-D or 3-D growth rate measurements that are then automatically archived and transparent upon public release. Most importantly, even submitting core image data in CoralCache can fulfil a crucial obligation of data sharing for authors working with coral cores, an obligation that is still unfortunately often bypassed by publishing only summarized data without the images necessary for reproducibility (e.g. Galochkina et al., 2026). Given the ability to protect pre-publication datasets, we argue that there is no downside to archiving in CoralCache, and that funders, publishers, and reviewers no longer need to accept claims for the lack of a suitable repository to meet data sharing requirements for coral core image datasets.