As late as the 1990s, spacecraft fault protection was done in an ad-hoc manner, using inline "if-statements" and hard-coded parameters that check the state of data within the system to determine if problems exist. This method of fault protection produces a system that is not easily scalable, difficult to implement and maintain, and time consuming to update. In order to address this problem, a data-driven fault protection architecture was developed for NASA's Kepler spacecraft that utilizes a repository to collect fault protection data and a generic fault monitoring framework within the spacecraft's flight software. This architecture uses a separation of concerns philosophy to insulate the fault protection data from the software and allow each to be updated independently. The fault protection information stored within the repository is used by numerous different engineering disciplines during the design, construction, and operation of the Kepler spacecraft, a timescale that encompasses many years. The task of managing the flow of this information among all consumers of the data over the entire lifetime of the mission presents a problem of data flow and interface management. Using a data-driven fault protection architecture provides many advantages over the traditional ad-hoc system. Maintenance of the software is easier since each software application performs its fault monitoring in a standard manner using parameters that are output from the repository. Also, utilization of a repository to store the fault protection data not only allows the parameters that control the actual performance of the system and the source code of the software to be updated independently, but also provides a way to ensure that the software and documentation are updated synchronously. XML is used to define a standard interface format in order to manage the flow of fault protection information from the iv repository to all of the clients that use the information. The clients can then design their various systems to interpret the information in a known format. Utilization of a repository for storage of Kepler fault protection data requires a method of managing the flow of fault protection data among all consumers across all program phases. Specification of a standard XML format for the database output products effectively insulates the database that stores the information from the clients that utilize the data. Since the output product is in XML format, there are a multitude of freely available tools that convert the information into other formats, allowing multiple final products to be created using the single output product from the database. The extensibility of XML allows changes to be easily incorporated into the generated XML documents with minimal impact to either the repository or existing client applications, which leads to a more agile system of fault protection that is more cost effective and displays a reduced risk to build and maintain.