Hi Manish, good to hear from you! I’ll try to go through your questions one by one.
Any architecture deployed on the grid came to life by storing an architecture description in the blockchain database (BCDB). All the information defining the solution is available in the BCDB, and all the subsequent changes that happened to the architecture are also stored there. One hundred (100) percent of the deployment information is stored, always append (full history) and immutable.
The architects (engineers) of IT workloads can (and will) model redundancy features in these setups based on well know principles such as load-balancing. Monitoring capabilities allow digital workers (3bots) to understand whether issues have or have not occurred. Based on logic written for this particular architecture failed components can be restarted on the same or extra provisioned capacity (since the digital worker has access to currency).
This is what we call “self healing”. We have done a lot of work to make the grid and grid operations selfheal and all the facilities are available for anyone to use those components to built self healing IT architectures. So also for this - if well designed - no human action and / or intervention is required.
So as explained the system has all the means to create selfhealing IT architectures. These architectures are made by developers, system administrators, system integration, blockchain projects and many more individuals creating tailor made solution on this grid. They are also the entities providing support to end users, it is in their business models to create that relationship with the end user. The foundation and the tech company do not play a role in that process.
For certified capacity TF Tech has the facility for supporting farmers if and when there seems to be failures caused by the TF Tech software stack. But this is only supporting the TF tech software stack.