In this section we propose a high-level design for the RECAST framework and discuss some issues that must be addressed in its implementation. Immediately, we factorize the system into three main components.

  • The front-end (this web site) serves as a communication broker: it provides a web interface for collecting requests, performs a basic match-making role to connect requests and analyses, and manages inputs and approved results. The front-end has no authority and no direct access to the analyses.
  • The back-ends which serve as the workhorses of the system: processes an alternative signal through an archived analysis chain, determines signal efficiencies and limits on production rate, provides authority of the result. Several back-ends are anticipated, the implementation of each being the responsibility of a particular collaboration.
  • The API which defines the interface between the front-end and the back-end. The beta API (application programming interface) allows for multiple back-end implementations to work seamlessly with the single front-end. It also allows for the back-end to evolve from a manual system to a fully automated system without affecting the front-end.

We stress that the framework does not need or have access to the data, does not involve design of new analyses, and does not require additional estimates of background rates or systematics. We also stress that the authority of any new results is derived from the collaborations themselves and that the original analyses should be the primary citation.

The design is based on a RESTful API, where interaction with the front-end happens via simple HTTP GET, PUT, and POST commands. These can be easily accessed via the command line with curl or wrapped in a python script. The data can be pulled either in XML or JSON. More details on the API can be found in the API Documentation