RIF Use Cases and Requirements

Rules are often used in matching the goals of end-users of a service/device,conjunction with the goals of providers and regulators ofother declarative knowledge representation formalisms, such services/devices. RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations ofas ontology languages (e.g. RDF and OWL), in order to provide greater expressive power than is provided by either formalism alone. Ontology languages, for example, typically provide a richer language for describing classes (unary predicates). Rules, on the sanctioned rules governingother hand, typically provide a service/device. This use case concerns Dynamic Spectrum Accessricher language for wireless communication devices . Recent technologicaldescribing dependencies between properties (binary predicates), and regulatory trends are converging toward a more flexible architecture in which reconfigurable devicesmay operate legallyalso support higher-arity predicates.

Rich domain models combining both rules and ontologies are often needed in various regulatorydomains such as medicine, biology, e-Science and service environments. The ability of a device to absorbWeb services. In such domains, several actors and/or agents are involved that have to interchange the data, ontologies, and rules definingthat they work with. An example is the policiesuse of such a region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules beingdomain model in a forman application that aims at assisting the device can use, as well as their being tailored to work with deviceslabeling of brain cortex structures in the same class having different capabilities.MRI images. In this use-case we suppose a region adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users. ( The decision by the European Unioncase, an OWL ontology is used to allow "Dynamic Frequency Selection" (DFS) use ofcapture knowledge about the 5 GHz frequency band by wireless systems,most important brain cortex anatomical structures, and a band intermittentlyrule base is used by militaryto capture knowledge about mereological and weather radar, isspatial dependencies between properties.

For example, a recent example.) Supposerule is used to express the policy states: A wireless device can transmit ondependency between the ontology properties isMAEConnectedTo and isMAEBoundedBy, in particular (a simplified form of) the knowledge that two Material Anatomical Entities having a 5 GHz bandshared boundary are connected:

If  no priority userMAE X is  currently using that band. Note, since default negation (not) such as negation as failurebounded by Z and MAE Y is  not supportedalso bounded by  RIF BLD thereZ then X is  no adequate wayconnected to  represent that "no priority user is currently usingY.

Benefits of interchange via RIF include the band". How does a device know that no priority user is currently using a band it wantsability to use?collaboratively develop and share valuable knowledge, the answer will depend onability to integrate anatomical images, possibly from distributed image sources, and the specific capabilitiesability to use large-scale federated systems for statistical analysis of the device. One typebrain images of device may answermajor brain pathologies.

This question by sensinguse case concerns the amountintegration of energy it is receiving on that band. That is, it might employinformation from multiple data sources. The rule: If no energy is detected onSemantic Web provides a desired band then assume no other device is using the band.common data representation in RIF BLD Presentation Syntax using relations: Document( Prefix(pred http://www.w3.org/2007/rif-builtin-predicate# ) Prefix(func http://www.w3.org/2007/rif-builtin-function# ) Prefix(ex http://example.org/example#) Group ( Forall ?device ?band ?level ( ex:used(?device ?band) :- ex:detect(ex:energy(?level ?band)) External(pred:numeric-greater-than(?level 0)) ) ) ) Note,and query language, which greatly simplifies access to diverse sources but does not directly address the engergy detection function would requireproblem that independent data sources may have rather divergent information models.

Rules are an external call for sensing the level of energy.effective way to express mappings between such procedural attachmentsinformation models. However, rules locked within local proprietary systems cannot be specified in BLD. Reaction rules provide event detection capabilities.reused. With a second typecommon rule representation, such mappings can be published across the Semantic Web, enabling an enterprise or community to progressively build up a rich network of device, may getmappings unifying the information from a control channel that letsmodels.

Information mapping and integration problems like this arise in many diverse domains including health care, travel planning, IT know whethermanagement and customer information management. The desired band is being used by a priority user. That is, it might employfollowing scenario comes from the rule: If no control signal indicating useworld of a desired band by a priority user is detected then assumeIT systems management.

Vlad has been given the band is available. Representation in RIF BLD Presentation Syntax using relations: Document( Prefix(pred http://www.w3.org/2007/rif-builtin-predicate# ) Prefix(func http://www.w3.org/2007/rif-builtin-function# ) Prefix(ex http://example.org/example#) Group ( Forall ?device ?band ?user ( ex:used(?device ?band) :- ex:detect(ex:signal(?user ?band)) ex:priority(?user,"high"). ) ) ) So each typejob of device will needanalyzing how exposed his division's business processes are to employ different "interpretations" or "operational definitions" of the policychanges in question. Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that eachtheir IT maintenance contracts. He has three sources of these manufacturers uses a distinct rule-based platform in designing its devices. Each manufacturer needsinformation to write 2 interpretations of the policy (for each of the two types of device). That means that 20 different versions of the policy must be written, testedcombine:

• a report on application services and maintained. Enter RIF.associated servers, databases and networks (from the 10 manufacturers formIT department)
• a consortium. This ismaintenance contracts database (from the finance department)
• a third-party group that is responsible for translating regional policies into RIF. When it does so, however,registry indicating which business processes use which IT provides different versions corresponding toservices (from the possible interpretations (operational definitions) of the policy. So in this case, 2 RIF versions of the DFS policy are provided for the 2 types of device mentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers. That is because the manufacturer only needs to develop such a compiler once for every architecture it owns. Contrast that investment with having to produce, test, and maintain different versions of various policies over the lifetime of a product. This arrangement also allows the overall process to be organized in a fashion that maintains the natural division of labor in the corresponding division of artifacts produced by that labor: the policy and its various interpretations are written and maintained in platform-independent artifacts (RIF); knowledge about how to translate from RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; the implementation implications for the various device architectures is generated automatically at the lowest level. 4.4 Access to Business Rules of Supply Chain Partners A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chainbusiness processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains. A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent. Where business logic is represented in different rule languages this presents a significant burden to the BP designer in designing an integrated process. Two primary integration modalities are possible: importing the different rulesets into a single engine and processing them in a uniform manner, or accessing the rulesets by querying remote engines and processing the results.planning group)

Each modality has its uses and contra-indications. Where there are strong ownership boundaries involved it may not be permitted to merge rule sets of partners. For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical decision in how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible: If inspector believes vehicle is repairable then process as repair otherwise process as total loss. Note that BLD and PRD do not support modal operators or predicates on quoted sentences; therefore standard representations of knowledge, belief, and/or uncertainty cannot be specified in BLD and PRD. Even without such constructs, it can be possible to represent knowledge or belief using the semantics of possible worlds. That is, one can get the effect of saying that an agent A believes proposition P by saying that P holds in all words that are belief-accessible to P. For example, to get the effect of saying Believe(john,overCreditLimit(bill,t)) one says instead holds(overCreditLimit(bill),t1) :- beliefAccessible(john,t,t1) However, it is not possible to express this in RIF, for two reasons: First, because the direct expression of knowledge or belief within possible worlds, as illustrated above, requires the construct of reification, which RIF BLD and PRD do not support. Second, because expressing the standard axioms on belief or knowledge would require the use of negation, also not supported by BLD or PRD. The question of whether a vehicle is repairable is one that is dependent on the processes executed by the inspector and cannot be directly integrated into the insurance companies own adjustment process. The insurance company effectively queries the inspector's logic. Within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims. Even in the case of a single company, which is nominally under a common ownership domain, information and business logic is often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (business units). Each unit will be motivated differently, will have different ontologies and business logic and may use different rule languages to represent their logic (this is particularly the case where one company acquires another company). RIF should be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules without changing their own technologies. How such a unified view of the business rules can be realized in a deployed BP will depend on both technical and non-technical factors. Even where all the parties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of the rule sets. In the situation where merging of rulesets is not possible, then a query-style access to partners' business rules may be used. In this way, RIF permits a unified dynamic view of the business rule logic no matter what the original form of the rules. For this to be viable from a business perspective it is critical that the semantics of the rules and query exchange be completely predictable and preferably loss-less. 4.5 Managing Inter-Organizational Business Policies and Practices This use case concerns organizations that acquire rule sets from external sources and that have to integrate these new rule sets into their existing rule bases. Such rule sets may be acquired in the following ways: An organization may buy rule sets from expert sources An organization may use rule sets from shared interest groups such as trade associations A component of a distributed organization may acquire rules when a rule set is distributed across a distributed organization. In such case, there may be different localization requirements in different regions and locations, entailing a variety of integration challenges in these various locations and component organizations. The following scenario examines these different methods of acquisition and the various types of integration and management issues that may arise. This scenario uses the (fictitious) car rental company, EU-Rent, used as the case study in the Semantics of Business Vocabulary and Business Rules Specification . The EU legislation discussed is also fictitious, as are the consulting companies CarWise and AutoLaw. EU-Rent's corporate HQ deals with CarWise, a consulting company with expertise in managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulations. An EU regulator issues a directive dealing with insurance for vehicles owned by corporations. CarWise agrees with the regulator on an acceptable interpretation, and provides EU-Rent (and its other car rental clients) with two sets of rules: A business policy, stating that every car rental must be insured for damages to third parties. A supporting rule set, addressing levels of required coverage, tax calculation in different EU countries, liabilities in rentals that span multiple countries, and reporting of compliance with this business policy. EU-Rent decides that it will maintain its compliance documentation electronically. CarWise then provides EU-Rent with an additional rule set for electronic compliance documentation, including such rules as: Each tax schedule must have electronic signatures from two EU-Rent employees who are at least at the level of manager. Before it can use the two general rule sets, EU-Rent needs to connect them to the relevant data sets in its IT systems, e.g. relate the EU country-specific taxation rules to the relevant record types in its databases. EU-Rent corporate HQ subsequently decides that the cost of third-party insurance will be built into the basic cost of each rental, and not shown as a separate item on the rental contract, to ensure that it can never be omitted from rentals or disputed by renters. It then sends three rule sets to its operating companies in the EU: The rule set for car rental insurance (from CarWise), including the basic policy and the supporting rule set. The rule set for electronic compliance documentation (also from CarWise). Its own rule set for building insurance into the basic rental cost. The operating companies then have to localize the rule sets for their countries of operation. For example, in the UK, another consulting company, AutoLaw, advises EU-Rent of rules for placing aggregate insurance for large fleets with more than one insurer in order to spread the risk, for example: For fleets of more than 200 vehicles, fleet insurance policies must be placed with at least 3 insurers, each of whom covers at least 25% of the risk. A timing issue makes it difficult for EU-Rent UK to strictly comply with this directive. EU-Rent UK has some existing insurance policies in place, which provide third-party insurance as an explicit item, and it cannot get refunds on early termination. It therefore asks corporate HQ for a temporary dispensation: that it can continue its existing insurance until it expires, and then switch to the new rules. EU-Rent HQ permits this, not just for the UK, but for any of its operating companies that have similar insurance arrangements. To ensure that this dispensation is temporary, it adds a new rule: Insurance policies that provide separate third-party coverage must not be renewed. EU-Rent HQ is also concerned about meeting deadlines for electronic filing. It introduces a new rule that it distributes to operating companies: Each electronic compliance document must have its required electronic signatures 48 hours before its filing deadline. This rule is meant to be implemented as follows: If '48 hours before filing deadline' passes, and the electronic signatures are not present, then the operating company's rules system must report the out-of-compliance situation, and subsequently wait for the responsible managers to provide the signatures. 4.6 Ruleset Integration for Medical Decision Support Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with rules is an important part of this expert decision making. For complex decision support systems, it is expected that rules will be furnished by a variety of different sources, including ontologies, knowledge bases, and other expert systems. This use case illustrates how RIF makes it possible to merge rulesets from diverse sources in diverse formats into one rule-based system, thereby enabling inferences that might otherwise have remained implicit. Medical decision support systems, such as the ones discussed below, might use rules from pharmaceutical knowledge bases, laboratory knowledge bases, patient databases, and medical ontologies. For example, a large amount of information on therapeutic medications (drug taxonomies, indications, contraindications, and clearance times) and diseases (disease taxonomies, etiologies, and symptoms) is contained in existing ontologies such as SNOMED Clinical Terms®. Rules can be used to express therapeutic recommendations, to formulate queries about relevant prescriptions for a patient, and to assess the effectiveness of a treatment. The following scenario illustrates how rule-interchange would be used in various medical decision support systems to support the following functionalities: Improving situation assessment, e.g., determining when a patient needs to be put on medication, or have his medication switched. Prescribing a course of action, e.g., determining which drug is best for a patient in a particular circumstance. Improving event planning, e.g., determining whether a patient can be scheduled for a procedure given the medication that he is currently taking. Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Dr. Rosen has been using the AutoDoc system to help him decide when to switch to medications and which drugs to prescribe. The AutoDoc system uses two sources when making its recommendations: a laboratory knowledge base giving particular results for patients and specifying when these results are out of normal range, and a pharmaceutical knowledge base giving guidelines for the use of medications. Automated reasoning with rules from these combined sources is possible if the rules are first mapped to RIF. Here are two specific examples of such synergistic effects. This scenario discusses the fictitious expert systems AutoDoc and MEDIC. In the interest of readability and brevity, the information and rules presented in the following scenario may not precisely capture the current state of medical knowledge and best practices in this field, but may be somewhat simplified. Originally Bob's diabetes was controlled through diet and moderate exercise. In time, however, Bob's blood glucose level began to rise, even under this regimen. Due to Bob's elevated HbA1c level (which indicates one's average blood sugar level over the last several months), Dr. Rosen prescribed oral medication for Bob. He was forced to change Bob's medication a number of times over the course of a year. He first prescribed Precose, an oral alpha-glucosidase inhibitor, but had to discontinue this medication due to undesired side effects. He then prescribed several sulfonylurea drugs, Micronase and Glucotrol, to no avail. Bob's lab results still indicated an elevated HbA1c level. The following rule from the laboratory knowledge base suggests that Bob's treatment at that time was not effective: If a Type II diabetes patient's current level of HbA1c is high, then the patient's current treatment is considered to be ineffective. Representation in RIF BLD Presentation Syntax using relations and an event calculus axiomatization: Document( Prefix(pred http://www.w3.org/2007/rif-builtin-predicate# ) Prefix(func http://www.w3.org/2007/rif-builtin-function# ) Prefix(ex http://example.org/example#) Group ( Forall ?Patient ?Treatment ?Level ?T ( ex:holdsAt(ex:ineffective(?Patient ?Treatment) ?T) :- ex:holdsAt(ex:hasDisease(?Patient "diabetesTypeII") ?T) ex:holdsAt(ex:elevated(levelOf(?Patient "hbA1c" ?Level)) ?T) ex:holdsAt(ex:treatmentPlan(?Treatment ?Patient) ?T) ) ) ) Note, the example requires the formalization of changeable states which can be represented by an event calculus axiomatization. KS86 ] The EC axioms can then be represented using RIF BLD. To deal with this problem, Dr. Rosen was about to prescribe Glucophage (metformin, one of the biguanides) 850 mg, 3 times a day, when as usual, he double checked his prescription with the AutoDoc system. The system, based on the following guidelines from the pharmaceutical knowledge base , informed Dr. Rosen that he should have prescribed an oral bitherapy (two medications, each of which controls blood sugar levels) instead of a monotherapy. If an oral monotherapy at recommended doses of a sulfonylurea or biguanide, combined with lifestyle changes, is ineffective, then the monotherapy should be replaced by an oral bitherapy. Based on the recommendation from AutoDoc , Dr. Rosen switched Bob's prescription to Glucophage and Avandia (rosiglitazone, one of the thiazolidinediones). Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI (Magnetic Resonance Imaging). When asked about current medication, Bob told Dr. Cervello that he was taking Glucotrol to control his diabetes, forgetting that he had been switched to Glucophage. This was potentially problematic, since Glucophage should not be taken close to the administration of a contrast injection. Fortunately, when Bob went to the lab to schedule his MRI, the medical receptionist pulled up MEDIC (Medical Event and Drug Interaction Consultant), the hospital's new automated system, which checks for incompatible medical events and/or drugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.). MEDIC uses a variety of sources in its reasoning, including: the pharmaceutical knowledge base, described above the patient databases, which gives the patient record, including the medications a patient is currently taking the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures In this case, MEDIC uses all three sources, and pulls up the following information: Metformin is contraindicated with contrast dye. Metformin is the generic form of Glucophage. Bob is taking Glucophage. The contrast MRI requires as one of its steps injecting the patient with contrast dye. MEDIC therefore determines that Bob should not be taking the contrast MRI at this time. For MEDIC to work, the rules from these different sources must be mapped to a unified interchange format. 4.7 Interchanging Rule Extensions to OWL Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and OWL), in order to provide greater expressive power than is provided by either formalism alone. Ontology languages, for example, typically provide a richer language for describing classes (unary predicates). Rules, on the other hand, typically provide a richer language for describing dependencies between properties (binary predicates), and may also support higher-arity predicates. Rich domain models combining both rules and ontologies are often needed in domains such as medicine, biology, e-Science and Web services. In such domains, several actors and/or agents are involved that have to interchange the data, ontologies, and rules that they work with. An example is the use of such a domain model in an application that aims at assisting the labeling of brain cortex structures in MRI images. In this case, an OWL ontology is used to capture knowledge about the most important brain cortex anatomical structures, and a rule base is used to capture knowledge about mereological and spatial dependencies between properties. For example, a rule is used to express the dependency between the ontology properties isMAEConnectedTo and isMAEBoundedBy, in particular (a simplified form of) the knowledge that two Material Anatomical Entities having a shared boundary are connected: If MAE X is bounded by Z and MAE Y is also bounded by Z then X is connected to Y. Benefits of interchange via RIF include the ability to collaboratively develop and share valuable knowledge, the ability to integrate anatomical images, possibly from distributed image sources, and the ability to use large-scale federated systems for statistical analysis of brain images of major brain pathologies. 4.8 Vocabulary Mapping for Data Integration This use case concerns the integration of information from multiple data sources. The Semantic Web provides a common data representation and query language, which greatly simplifies access to diverse sources but does not directly address the problem that independent data sources may have rather divergent information models. Rules are an effective way to express mappings between such information models. However, rules locked within local proprietary systems cannot be reused. With a common rule representation, such mappings can be published across the Semantic Web, enabling an enterprise or community to progressively build up a rich network of mappings unifying the information models. Information mapping and integration problems like this arise in many diverse domains including health care, travel planning, IT management and customer information management. The following scenario comes from the world of IT systems management. Vlad has been given the job of analyzing how exposed his division's business processes are to changes in their IT maintenance contracts. He has three sources of information to combine: a report on application services and associated servers, databases and networks (from the IT department) a maintenance contracts database (from the finance department) a registry indicating which business processes use which IT services (from the business planning group) Each of these sources is in a different form but can be mapped into RDF to simplify access. However, they all have different information models. The IT report is too fine-grained: it talks about routers and interface cards whereas Vlad only needs to identify servers and pick out some generic dependency relations. On the other hand, the finance database models the world in terms of physical assets such as racks, which is too coarse-grained. First, Vlad creates simple mapping rules to create a uniform, simplified view of the data in terms of a small number of concepts -- Server, Business Process and Dependency. This involves rules such as: If x is a ComputeNode in Rack r and Rack r is in Cage c and mc is a MaintenanceContract for Cage c then x is a Server with MaintenanceContract mc If x is a ComputeNode with a NetworkInterface with Port p and app is an Application running on Port p then x is a Server that hosts app If bp is a BusinessProcess that uses Application app then bp has a Dependency on app Representation in RIF BLD Presentation Syntax using relations: Forall ?X ?MC ?R ?C(  ?X[rdf:type->ex:Server ex:maintenanceContract->?MC] :- And(  ?X[rdf:type->ex:ComputeNode ex:location->?R] ?R#ex:Rack  ?R[ex:location->?C] ?C#ex:Cage  ?C[ex:maintenanceContract->?MC] ?MC#ex:MaintenanceContract )) Forall ?X ?Ni ?P ?App (  ?X[rdf:type->ex:Server ex:hosts->?App] :- And(  ?X[rdf:type->ex:ComputeNode ex:networkInterface->?Ni]  ?Ni[ex:port->?P]  ?P#ex:Port  ?App[rdf:type->ex:Application ex:onPort->?P])) Forall ?App ?BP (  ?BP[ex:dependsOn->?App] :-  ?BP[rdf:type->ex:BusinessProcess ex:processUses->?App] )) He then creates rules that combine the data across his now simplified data sources, e.g. If bp is a BusinessProcess that has a Dependency on Application app and x is a Server with MaintenanceContract mc that hosts Application app then bp has a Dependency on mc Representation in RIF BLD Presentation Syntax using relations: Forall ?App ?BP ?App ?MC(  ?BP[ex:dependsOn->?MC] :- <  ?BP[rdf:type->ex:BusinessProcess ex:dependsOn->?App] ?App#ex:Application  ?X[rdf:type->ex:Server ex:hosts->?App ex:maintenanceContract->?MC] )) This gives him a uniform view that links from business processes through to the IT and finance data. Vlad publishes these rules so that other people across the company can reuse them to construct similar views. 4.9 BPEL Orchestration of Rule-Based Web Services Rule-based Web services depend on the use of XML data for their request and response format. The involved rules must be able to access and compare XML data in their conditions and modify and generate XML data in their actions. An existing commercial credit approval service deployed as a Web service takes an applicant credit request document as input and returns an approval or denial (with reason). It is implemented as a BPEL orchestration of two Web services -- a credit history providing service and a decision service containing a rules engine. BPEL first passes the credit request document to the decision service to determine, using rules, whether enough information (SSN, mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history from the history providing service and passes the credit history document to the decision service to be evaluated. Based on the evaluation, credit is approved or denied. Because the rule engine is part of a Web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluation model can be changed easily using GUI tools to customize rules. Use of RIF would improve the situation further. First, the credit history vendor could supply a default set of rules for evaluating its histories. Second, there would be several rule editing and customization tools fromof these sources is in a different RIF compatible vendorsform but can be mapped into RDF to tailorsimplify access. However, they all have different information models. The rulesIT report is too fine-grained: it talks about routers and interface cards whereas Vlad only needs to meet specific business objectives.identify servers and pick out some generic dependency relations. On the credit evaluation rules are themselves grouped into three rulesets that are executed sequentially. Rules inother hand, the first ruleset apply thresholds to several "red flag" quantities infinance database models the credit report, such as: numberworld in terms of timesphysical assets such as racks, which is too coarse-grained.

First, Vlad creates simple mapping rules to create a payment was 60 days late debt-to-income ratio numberuniform, simplified view of foreclosures or repossessions numberthe data in terms of garnishmentsa small number of liens bankruptcyconcepts -- Server, BusinessProcess and Dependency. This involves rules such as:

 If x is a  red flag above the threshold resultsComputeNode in  denial of credit. RulesRack r
    and Rack r is in  the second ruleset incrementCage c
    and mc is a  credit score variable.MaintenanceContract for  example: If applicant owns residence then add 40. If applicant rentsCage c
       then  add 30.x is a Server with MaintenanceContract mc
 
 If  applicant has lived at current address 2 to 4 yearsx is a ComputeNode with a NetworkInterface with Port p
    and app is an Application running on Port p
       then  add 20.x is a Server that hosts app
 
 If  applicant's incomebp is  under 20000a BusinessProcess that uses Application app
       then bp has a Dependency on app

 If  applicant's incomebp is  between 40000a BusinessProcess that has a Dependency on Application app
   and  50000x is a Server with MaintenanceContract mc that hosts Application app
      then  add 40.bp has a Dependency on mc