engines like Google Dataset Search, increasing reach and accessibility. Since the CVs for this schema are under development, we recommend that early adopters use free text fields after “other” options to collect information for potential expansions or modifications to the CVs.<sup>14</sup> Finally, _user accounts_ allow contributors to track and edit catalog entries after they have been posted, data owners to claim entries, and front-end users to save searches or individual records, while a _data review system_ contributes to ensuring data quality control and avoiding version control issues, duplication of entries, or so-called “ghost entries”. For this purpose, incomplete entries could be regularly flagged for purging.

**Back-end:** The data entry interface for contributors should minimize the time and effort (and hence potential for errors) required to complete an entry to help maintain data quality. This includes making use of existing information where available. Especially for bulk entry of existing RCT data, a sophisticated implementation could draw on existing public records where available, such as the API interfaces of ClinicalTrials.gov and the World Bank Microdata Catalog,<sup>15</sup> , or the downloadable AEA RCT Registry data. New catalog entries could also be partially pre-filled by scraping web data from external resources such as registry entries and academic articles. This could best be achieved by beginning the data entry with the links to (some) external resources (which would also permit a duplication check within the catalog).

Within a metadata entry, information filled early on can provide inputs to later fields, such as pre-filling the treatment arms that were recorded in the “outcomes and interventions” section (III) in the “data” section (V). The catalog can also prompt contributors for information based on earlier inputs, such as suggesting entries for ethics documentation (section VI) or prior studies (section IV) in the “external resources” section VII. Automated cross-checks and data validation can additionally be applied to numeric and multiple-choice entries. We make specific suggestions in the programming notes in Appendix A. These features minimize errors and duplication of effort and improve consistency. Incomplete entries should be regularly automatically saved to prevent data loss.

An intuitive interface and extensive user support can also help with data entry. For example, CVs should be implemented as multiple choice radio buttons or “select all that apply” tick boxes; at the end of an entry in a loop, the navigation should allow users to choose between adding another entry or moving to the next field. In addition to the field and CV definitions in the Appendix, the interface could provide help “bubbles” containing longform instructions and detailed examples that could be drawn from this article. This could be especially useful for describing the intervention assignment and study design in sections III and IV.

**Front-end:** Careful interface design for front-end users can facilitate a quick overview over multiple datasets as well as individual RCTs. An individual study view could pull selected information from various

> 14The authors encourage submitting suggestions for such changes through the GitHub for this project.

> 15This is facilitated by the crosswalk we created to link individual fields in our schema to those in other schemas; see this project’s GitHub repository.

20