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 which serves as a communication broker: 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. A well-defined API (application programming interface) allows for multiple back-end implementations to work seamlessly with a 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.