+Scope
+-----
+
+The blueprint validation UI aims to be hosted by LF servers and will be exposed using public IP and domain names.
+
+It provides a user-friendly way for displaying blueprints validation test results. Based on these results, the status of a blueprint can be determined (mature, incubation state, etc.).
+
+In specific, the purpose of the UI is twofold:
+
+1) Support full control loop of producing results. In this mode, the UI must be connected with a Jenkins instance capable of running blueprint validation tests.
+ It will enable the user to define a blueprint for validation using its name, version, layer, desired lab and desired timeslot. This data constitutes a submission. It should be noted that the blueprint family is derived from the blueprint name.
+ Also, the UI will have the ability to track the lifecycle of a submission. A submission state can be one of the following: submitted, waiting, running and completed. The implementation vehicle for this action is the REST API of Jenkins.
+ Moreover, the UI must be connected with a mariadb instance and the Nexus server where the results are stored.
+ Then, it will be able to trigger the appropriate job in Jenkins and receive the corresponding results from Nexus.
+ Note that it makes no difference whether the Jenkins instance is the community one or a private one.
+2) Partial control of producing results. In this mode, the UI must be connected with a mariadb instance and the Nexus server where the results are stored.
+ Every blueprint owner is responsible of executing tests and storing results in Nexus using his/her own Jenkins instance. The UI only retrieves results from Nexus and displays them.
+
+Currently, the partial control loop is not supported.
+
+In both modes, user authentication, authorization and accounting (AAA) will be supported in order to control access to resources, enforce policies on these resources and audit their usage.
+
+Prerequisites:
+~~~~~~~~~~~~~~
+
+In order for the blueprint validation UI to be functional, the following items are taken for granted:
+
+- An appropriate mariadb instance is up and running (look at the Database subsection).
+ This prerequisite concerns both of the UI modes.
+
+- The available labs for blueprint validation execution are defined by the corresponding lab owners (look at the Database subsection). It is their responsibility to publish them. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a lab owner to update them, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
+ This prerequisite concerns only the full control loop mode.
+
+- The available timeslots for blueprint validation execution of every lab are defined by the corresponding lab owners (look at the Database subsection). It is their responsibility to publish them. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a lab owner to update them, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
+ This prerequisite concerns only the full control loop mode.
+
+- The data of the lab silos (i.e. which silo is used by a lab in order to store results in Nexus) is stored in the mariadb database (look at the Database subsection). It is the blueprint owner's responsibility to publish it. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a blueprint owner to update it, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
+ This prerequisite concerns only the full control loop mode.
+
+- The data of available blueprints (i.e. blueprint name) is stored in the mariadb database (look at the Database subsection). It is the blueprint owner's responsibility to publish it. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a blueprint owner to update it, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
+ This prerequisite concerns only the full control loop mode.
+
+- The data of an available blueprint instance for validation (i.e. version, layer and description of the layer) is stored in the mariadb database (look at the Database subsection). It is the blueprint owner's responsibility to publish it. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a blueprint owner to update it, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
+ This prerequisite concerns only the full control loop mode.
+
+- A Jenkins instance exists capable of executing blueprint validation tests on the specified lab and storing the results to Nexus server (look at the Jenkins configuration subsection).
+ This prerequisite concerns only the full control loop mode.
+
+- A Nexus server exists where all the blueprint validation results are stored (look at the Nexus subsection).
+ This prerequisite concerns both of the UI modes.
+
+- The whole installation and deployment of a blueprint and its corresponding blueprint family components (i.e. the appropriate edge cloud stack with its combination of infrastructure hardware components, OS, K8s, software, etc) are already performed in the appropriate lab.
+ Recall that multiple labs can be used for a specific blueprint validation. Also, it is the responsibility of the blueprint submitter to ensure that the edge validation and community CI labs can support comprehensive validation of the blueprint and cover all use case characteristics.
+ This prerequisite concerns both of the UI modes.
+
+Developer's guide
+-----------------
+