text: a constant challenge faced by business and personal entities , including corporations is to ascertain the credentials of the many different entities they interact with namely but not exclusively , customers , partners , job applicants , vendors and so on . with increasing emphasis on security and authenticity in transactions between entities even at the job assessment level , it is only a matter of time before predetermined validation steps for different entity interactions becomes a legal imperative and then possibly binding on each of the entities . what is described herein is a framework that uses software to facilitate an entity to create a validation request and have one or more entities one of which may be itself to perform validations on the request and provide one or more validation outcomes . the outcome may be a confirmation of the request , a negative assessment based on the request or some level between these two extremes of an outcome . there are one or more entity types , the entity type being based on one or more classifiers . there are one or more validation rules that are in turn based on the entity type . the combination of entity type and validation rule / s becomes a validation request . thereafter the validation request is sent to one or more entities to perform the validation or at least a portion of the validation in accordance with the validation rules . the software can also be used to allow the requesting entity to modify or add entities as well as modify or add validation rules . moreover the software works within a framework can be integrated with other software used by the entity or by others thereby adding to the functionality and usefulness of existing software . the entity validation framework uses but not exclusively entities , validation rules and validation entities as described below : an entity type can be , for example but not limited to , any entity which is to be validated on behalf of a requesting entity . an entity type can be a customer entity , vendor entity , applicant entity and so on . the requesting entity using the software and framework can create new entities if there is no predetermined entity type but as will be described there will need to be additional aspects of the software created so that the rest of the validation process can be performed on the new entity . classification of the entity type can be by means of matching supplied information to predefined data formats ( e . g . e1000 ‘ e ’ refers to employees ), query from specific fields of host tables and so on . the process of matching can be aided by using predefined fields and formats but that is not always necessary and there exist data matching programs to assist if that is not the case , or alternatively the person in the entity using the software can assist to match the received information . however , the program will hold the final classification of the entity type . this refers to the different rules for validating an entity . validation can be in the form of questions , or can be based on filter values ( create a validation request for all candidates based in a particular city , say new york ) and other mechanisms that can be predefined by the software or created by the user entity . the user when creating the validation request chooses the validation criteria from defined criteria that can include selection rules and finally associates the validation rules to the entity requested to be validated . this refers to entities that perform the actual validation . the validation can be performed by third party validation agencies , a central validation repository , global validation repository and peer systems involving departments of the same entity making the validation request . the framework allows the requesting entity to define the mode of communication with the one or more validation entities , the validation time frame , priority of validation and so on . the mode of communication can be through for example but not limited to extended mark - up language ( xml ) or idocs . once the validation entity is defined by the requesting identity or the type of request can automatically determine the entities to validate the request , the association between the entity , validation rules and validation entities is made and the framework can start the process of validation . these are third party agencies that perform validations on the entity request based on the requesting entity &# 39 ; s requirements . the framework provides a mechanism to integrate with a third party request receipt system by means of xml or idoc . once the validation is done , the required data in the form of a validation outcome is passed back to the requesting identity through the framework . the framework reads and processes the results of the validation based on the validation rules and business entity rules defined by the requesting identity . this is a central agency or central process that updates the information relating to validation within a corpus of companies or between different units of the same company . at the very least the central validation repository can be considered as a database where the validation outcomes are stored and accessible to predetermined entities , such as for example but not restricted to , different units of the same company or specified other entities willing to rely on the outcomes of other requests . the latter being the basis of sharing of information but which would need to be very controlled and managed to ensure issues such as currency of information , veracity of the outcomes and the requests that prompted the outcome and records of the entities used to perform the validation . workflows can be linked to the entity based on the validation outcome and additional system events can be defined . thus for example if a candidate for a position fails the validation , a workflow can be initiated to inform recruitment that the validation has failed and action triggered to update the candidate record . once the validation results of an entity is stored , then other companies or units of a company can access this validation repository to validate the entity themselves . for example if an entity validates the credentials of a job candidate who applied for a job , it can place the details of the validation and its outcome in a centrally accessible validation repository . another unit of the same entity , can now access this validation repository to determine the credentials of the candidate when they apply again to this entity even at another unit of the same entity . global validation repository — this refers to a global agency or process that collects information relating to an entity from diverse sources and then consolidates the data and provides the data to entity requesting it for a validation process . for example a global validation repository would contain data relating to a potential job candidate from different sources for example but not limited to educational institutions , former employers , and so on . based on the validation request put forward by the entity , data is selectively fetched about the job candidate and included in the validation request construction or the validation process itself . accepting information from disparate information sources can increase the accuracy of the validation process whether the information received confirms or puts into doubt any information being compared for the validation process . fig1 depicts a peer - to - peer system wherein each entity acts as a conduit for validation information . an entity may have agreed to collaborate with another entity for obtaining confirmatory or otherwise validation information . the other entity in turn might have collaborations with yet other entities for the purpose of validating information . the request for validation from the first entity is accepted by the second entity and it may deal with the request itself or forward all or a portion of the request to another entity thus becoming a requesting entity . once a response or responses are returned the request outcome can be returned to the originating requesting company . based on the different types of validation entities defined above , there could be a number of validation architectures used by the framework . in fig2 the data to be validated is stored in a central database that is managed by an agent . the various inwardly directed arrows indicate data flowing from different entities to the agent &# 39 ; s central database . when an entity requests information about another entity , the agent provides the data collected and stored in the central database about the other entity . in the validation request / response process , the entity requesting information in a validation request sends such a request to the agent . the agent then publishes the validation request to all the member entities in the agent network . all the member entities provide information at their disposal about the entity being validated to the agent who then in turn collates and provides a validation outcome to the requesting entity . it may also be possible for the agent to act merely as a data gatherer so that the requesting entity can collect sufficient information to generate its own validation outcome base on that received information . by way of example , the steps associated with the procedures described above in general are provided by way of illustrative screen shots of a software implementation of one embodiment of the invention as depicted in fig3 to 13 . the implementation provides a totally html based application . fig3 depicts an employment recruiters &# 39 ; validation workbench screen where a validation request can be raised and sent to a third party validation agency , wherein the screen has fields for applicant id , first name , second name and various dates associated with the applicant . one of the columns allows for the designation of the validation entity . another of the columns allows for the setting of questions to be investigated by the validation entity . overall the screen is presented like an e - mail presentation program with in , out and result boxes for dealing with validation requests and validation outcomes , as well as a cvr box for accessing a central data base of validation outcomes and requests . various other functions are available including a search facility , various visual presentation alternatives , etc . fig4 depicts a validation request raising screen where the applicant id is entered , and the validation agency acronym or id is entered and various attachments can be made . fig5 depicts a screen containing validation criteria , in this example , being in the form of a questionnaire . the question can be obtained from drop down lists or created by the recruiter . all questions are displayed fro review and modification as required . fig6 depicts that once the validation request is created , the xml or idoc is generated based on a pre - agreed format and sent to the validation entity . the format can be one of many as long as the recruiter and validation entity are agreed on a common format . fig7 depicts the screen that the third validation entity sees when it receives the validation request . fig8 depicts the list of questions and answers based on the recommendation of the employment recruiter . fig9 depicts the posting screen available to the third party validation entity once the validation request is completed . the validation outcome is ready to be posted and this is achieved by highlighting the outcome and clicking the outbox as shown pictorially . fig1 depicts the screen seen by the employment recruiter of the validation outcome / s sent by the third party validation entity . two such outcomes are shown for selection by the recruiter . in this example the same validation entity was used for both candidates . fig1 depicts the screen showing the questions that were dealt with by the validation agent . the questions are displayed by clicking an appropriate button on the detail panel of the screen . fig1 depicts the screen containing the validation entity &# 39 ; s response to questions and the overall response to validation . the answers are displayed by clicking an appropriate button on the detail panel of the screen . fig1 depicts a screen showing the recruiter posting the results of a validation for candidate ashwin to a database . the candidate is selected , as depicted , by the highlighted entry in the overview panel and the sending is achieved by clicking an appropriate button . a central validation request and outcome database can be set up within the entity generating the requests so that the information is available to selected personnel within the entity or the information may be made available to a more widely accessible database available to two or more entities willing to pool such information . having a framework for exchanging validation information whether inside an entity or by agreement between entities promotes greater efficiencies in validation efforts for the participating entities . thus , an example embodiment of the present invention may provide for a method as illustrated in the flowchart of fig1 . at step 1400 , entity type classifiers may be created . at step 1401 , an entity type of an entity to be validated may be classified based on the created classifiers . at step 1402 , validation rules may be created . at step 1403 , a list of the validation rules , e . g ., that are associated with the entity type classification , from which the validation rules are selectable may be displayed . at step 1404 , one or more validations rules may be selected . at step 1405 , a validation request may be produced . at step 1406 , the request may be provided to a validation entity . at step 1407 , the validation entity may save a validation outcome . at step 1408 , the validation entity may provide the validation outcome to a requester . at step 1409 , the validation entity may use the validation outcome to respond to additional validation requests . at step 1410 , a validation management display as described herein may be generated . it will be apparent that one or more of the steps may be omitted , and that the precise sequence in which the various steps are shown in fig1 is exemplary and may be changed . it should be also appreciated that the present invention can be implemented in numerous ways , including as a process , an apparatus , a system , a computer processor executing software instructions , or a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links . for example , fig1 shows an example system that includes a processor 1500 in communication with a computer - readable medium 1502 that stores validation software 1504 . the validation software 1504 may include instructions executable by the processor 1500 , such that , when the processor 1500 executes various portions of the instructions , the instructions cause the processor to perform the various methods described herein . it should be noted that the order of the steps of disclosed processes may be altered within the scope of the invention , as noted in the appended claims . the present invention may be practiced according to the claims without some or all of these specific details . for the purpose of clarity , technical material that is known in the technical fields related to the invention has not been described in detail so that the present invention is not unnecessarily obscured . throughout this specification and the claims that follow unless the context requires otherwise , the words ‘ comprise ’ and ‘ include ’ and variations such as ‘ comprising ’ and ‘ including ’ will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers . further , references to any prior art in this specification is not , and should not be taken as , an acknowledgment or any form of suggestion that such prior art forms part of the common general knowledge . although the foregoing invention has been described in some detail for purposes of clarity of understanding , it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims . it should be noted that there are many alternative ways of implementing both the process and apparatus of the present invention . accordingly , the present embodiments are to be considered as illustrative and not restrictive , and the invention is not to be limited to the details given herein , but may be modified within the scope and equivalents of the appended claims .