Official confirmation of failure or lapse in services as evidenced by documented email communication between EIS and the client.
 

Since our company maintains email boxes that records communications between our very own “project team leader” and the client, any service flaw is easily identifiable “on lapse in dates of delivery”, “topics that were not attended to” or “fault in service contents”.
 

A procedure can be done in as many ways in as many preferred approach.  As a basis of failure, any module that EIS has gone to deliver and has not resulted into a desired “data condition” of the client’s need may be regarded as a failure.   

However, if the method of EIS differs on the client’s technique or manner but nevertheless serves the same purpose, this condition negates the validity of a claim to “incapability”.

It may also happen that the source of data whereby the client specifies a resultant with which the same is not achievable under our software design, is not to be acknowledged as a sign of incapacity of EIS. 

There could be limits to our initial design specifications but not on any add-on that we may provide on top of the subject software under this guaranty clause.
 

A bug is a bug.  During the course of our development, some instances of imperfection may occur even in a very professional and quality-managed EIS development cycle.

This may have been caused by haste and urgency to deliver at commendable short- time-element.

In all likelihood, it may be from an inadvertent typo error during the EIS coding effort or a plain and simple oversight.

A significant disadvantage from a bug-induced loss must be not in the league mentioned above.

Clarifying the same is on a dimension of the ones listed below:

A move that is deliberate; or

Unprofessional substance or consequence of the software; or

Gross negligence of the BOSS software on any module within its functionality but excluding the areas of hardware deficiency or operating system glitch.