Steps for a model build
The following four steps are followed for every model we build:
1.	Business solution - Each new business solution will be defined separately for each model built. 
2.	Data collation - Emerge’s approach to data collation is first to attempt to use data a client  already has internally and easily-at-hand to avoid costs that might be incurred collecting data from external parties. We do not request that the data be cleaned before providing it to us and actually prefer if the data has not been cleaned – our algorithms learn nicely off unclean data, provided it is consistently unclean. Should the data used not be sufficiently predictive, we can explore alternative internal or even external data sources and then iteratively improve the model over time. We have relationships with third-party data partners that we can involve if required. Due to legislation that limits transferring personal information, we require that all personal information be de-identified to the extent that it cannot be re-identified again. De-identify, in relation to personal information of a data subject, means to delete any information that: 
a)	identifies the data subject; 
b)	can be used or manipulated by a reasonably foreseeable method to identify the data subject; or
c)	can be linked by a reasonably foreseeable method to other information that identifies the data subject.
We would like as much data as possible but would prefer not to wait too long while data is being collected to build the first iteration. As such we would prefer for data to be sent in batches when collected by a client, with a common key to join the different data sets.
3.	Machine Learning - Based on the data we received in step 2, we will build a bespoke machine-learning model to solve the problem defined in step 1. We will use Emerge’s proprietary methodology for creating the model. We have opted not to patent any of our methods to avoid our solution being available in the public domain and to avoid the costs and time wasted during this process. As such the models that we build will remain the property of Emerge and will be licensed for use. 
4.	Operational execution- The value of our models is achieved only when they are implemented into operational processes. Operational execution includes two main parts
a)	Integrating the model into the operational process
b)	Monitoring and updating the model to ensure continued (and hopefully improved) accuracy
The design for integration needs to be carefully considered. In most cases, it would be best fully to integrate the models into the operational process by making the necessary IT changes to existing systems. In this case, we recommend an API integration between the system and the model. Both parties will need to prioritise the project and IT resources required to manage this integration. However, in some cases, a periodic batch process would be possible and IT integration may be avoided.
To achieve ongoing accuracy of the models it will be necessary to ensure Emerge has the ongoing results of the process for which Emerge’s machine-learning models are being used . A process to get this data will need to be defined. This data will also be used to retrain the model as required.  

Phases of a model build
To ensure that the model is sufficiently valuable to you, we would typically propose following three stages for each model
1.	Proof of Value: This is a short-term piece of work to determine whether a sufficiently accurate model can be built with the available data. This model may not cover all aspects of the final model e.g. it may only consider a subset of key products. The accuracy of the model would be tested on past data. The model will not be implemented into operations at this stage.
2.	Pilot: Following a successful POV, a pilot would be run over a period of three months where the model is used on live data. Typically, this would be a subset of the live data, allowing the model to be compared to any existing process / strategy (where appropriate). The data collection and model runs may still be manual. Over the pilot period the results from the pilot will be used to update the model. Any additional data that becomes available during the pilot will also be used to improve the accuracy of the model. 
3.	Full integration: Full integration would be achieved as described in ‘Operational execution’ in point 4 of the previous section. 

Technical environment
The models will be run in a cloud environment. Our preferred cloud environment is the Microsoft Azure. This environment complies with the highest levels of data-security standards (see https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings). 

Resource allocation
Emerge will allocate resources to this engagement as required to ensure as seamless an integration of its models into the a client environment as possible. The following functions will always be supplied by Emerge: 
a)	Relationship manager to be the primary point of contact
b)	Model building specialists to ensure we quickly build the appropriate models for a client

a client will own the rest of the key steps for model implementation but Emerge can provide support in the following areas if required:
a)	Business solution design specialists to work with internal a client teams to ensure we design the appropriate models for each application.
b)	Data specialists to manage the relationship with data experts at a client.
c)	Process design specialists to work with internal a client teams to ensure we design the appropriate processes for implementation of the models.
d)	IT integration specialist to ensure the different model outputs will be integrated into the a client system environment.

Pricing structure
Emerge charges an initial Proof of Value (POV) model building fee per model to confirm that the model built will add value to a client’s operations. After the POV is completed, a client will need to decide if they would like to go forward with the implementation of the model into its operations (initially via a short pilot). Should a client wish to use the Emerge model(s) on an ongoing basis, an ongoing pricing structure will be implemented. Emerge offers two possible models for the pricing of its services:
a)	A flat monthly licence fee
b)	a lower monthly per model fee supplemented with a performance-based fee 
It should be noted that regardless of the pricing model chosen, the Emerge fee includes:
a)	the required support relating to data specification and transfer;
b)	the development of the proposed models; 
c)	licensing and hosting of the models;
d)	the ongoing performance measurement of the various models; 
e)	support relating to the appropriate use and deployment of model results; and
f)	ongoing retraining and maintenance of the various developed models.

Model scope
For each model that is planned (whether as a POV model or a deployed model), the following items will be defined:
a)	Model definition
b)	Pricing
c)	Data requirement
d)	Timing and next steps

General
The following general terms of use will be applicable:
a)	Emerge will be allowed to refer to a client (including but not limited to brands it uses in the market) as a client and its logos to market itself. Emerge will also be allowed to reference a client in a case study. 
b)	Emerge’s methodology and the models it creates will be considered intellectual property and the ownership thereof will remain with Emerge. The models may be licensed to a client as part of the monthly fee to be paid to Emerge. 
c)	Monthly invoices will be issued in advance
d)	Emerge reserves the right to withdraw rights to use the model should Emerge not receive any fees due.
e)	a client will timeously provide Emerge with the data it requires to perform its duties. This will include full access to operational results of any models run in order to improve the accuracy of its models.
f)	Should the intended results not be achieved for any reason, Emerge will not be held liable, financially or otherwise.  
g)	Errors and omissions excepted