# Minimum Viable Product

Establishing the MVP is core to projects as it provides a clear baseline to work toward. The goal of my internship is to create this MVP. Based on the [stated goals](https://teaguemm.gitbook.io/internship-avatar-pipeline/problem-definition/stated-goals), an MVP will contain the following:

* A simple web front-end in which the user can upload/link (an) image(s) or video(s)
* An API to connect to
* A service to provide bounds for validation
* A service to perform OpenFace analysis and compare this to the bounds received from the aforementioned service
* A simple report overview page (with the option to download it)

## Updated MVP After Design

After later feedback, some edits and additions were made to the prior MVP design. This is reflected in the [Software Architecture](https://teaguemm.gitbook.io/internship-avatar-pipeline/software-architecture/c4-model). The main points are threefold: a desire for increased cloud integration, a more defined analysis using the OpenFace data, and an emphasis on the traceability of jobs.&#x20;

#### Increased Cloud Integration

This comes down to a desire for the different Azure services on offer to be used to their fullest extent. More information on how this was tackled can be found in the [C4 Model](https://teaguemm.gitbook.io/internship-avatar-pipeline/software-architecture/c4-model), [Azure Functions](https://teaguemm.gitbook.io/internship-avatar-pipeline/project-contents/pipeline-components/azure-functions) and [Application Insights](https://teaguemm.gitbook.io/internship-avatar-pipeline/project-contents/pipeline-components/application-insights).

#### Defined Analysis

There were initially various methods outlined for the analysis using OpenFace data. These have now been added to the [Final Recommendations section](https://teaguemm.gitbook.io/internship-avatar-pipeline/problem-definition/broken-reference). The analysis now consists of a set of parameters containing a desired value for each AU and a degree to which it can vary from that specified parameter. Parameters can be manually entered or generated through the use of a reference image. OpenFace data is compared to the chosen set of parameters, after which a report is made and stored.

#### Emphasis on Traceability

Core to the application is the ability to know how each step in the process went (and where it potentially went wrong). Ideally this would be displayed in an interface similar to GitHub actions, as explained in the [Week 7](https://teaguemm.gitbook.io/internship-avatar-pipeline/week-reports/week-report-overview/week-7-11-10-15-10) post.&#x20;

With that in mind, the best suited solution has been realised using [Application Insights](https://teaguemm.gitbook.io/internship-avatar-pipeline/project-contents/pipeline-components/application-insights), an Azure service used to store logs. Each analysis job has a UUID associated with it. Application Insights allows logs to be queried, allowing the user to query logs based on the associated UUID. With this, users can retrieve all logs using the UUID.

### End Result

In the end, the scope of the project remains the same, but the emphasis moves from the analysis to the general architecture and cloud implementation.
