• Real-time contract exchange

This is one of the possible Use Cases.

1. Abstract

Production Rules are often used to define "contracts" in an executable form. The interchange of such contracts is a fundamental issue in e-business.

2. Status

Proposed by PaulVincent of Fair Isaac TIBCO.

This use case is based on a number of commercial systems that aim to automate the "contractual information" as a set of rules to be associated with commercial data, usually in a supplier-customer type exchange of contract rules. Commercial cases include:

• use of the ACORD/SPX standard for insurance policy forms, where the rules for constraining and validating the data are defined as part of the form and passed from insurance carrier to agency / customer as required, and then returned when filled in per the rules in the form;
• use of customer contract rules for a media company who is consolidating customer requirements against a fixed resource (such as an advertisement schedule in a TV schedule); the customer contracts may specify goals of certain types of advertisement schedule times that should be used and what other customer advertisements may or may not be ajoining, etc.
• use of customer contract rules for a foodstuff company who is consolidating customer requirements against a fixed resource (such as a product run of foodstuffs); the customer contracts may specific goals of certain types of product recieved (for example, drink product A in pack size N) and prices for these as well as replacement products and packages in case replacements need to be shipped instead.

Updated 27 Feb 2007: references: ILOG example

3. Links to Related Use Cases

See also:

• Rule-based Service Level Agreements (SLA) and Web Services

• E-Procurement Contract Exchange, with Default-Inheritance Ontologies/E-Contracts with Exceptions, with OWL Process Ontologies

• Price Discounting/Supply Chain Ordering Lead Time/Refund Policies in E-Commerce

• Credit Card Transaction Authorization - a possible application for extending authorization rules to other parties

• Importing rules to check data compliance

• Rule Based Service Level Management and SLAs for Service Oriented Computing

• Organizing a Vacation with Friends - this is about personal contract exchange!

4. Relationship to OWL/RDF Compatibility

Typically, contract exchange rules will be operational rules (ie running in operational systems against operational data) rather than knowledge systems (ontological descriptions). Although it would be possible for (and indeed, potentially a good fit for) semantic-web type RDF data representation, this is rarely used in industry today and is not part of the examples described in the status above.

5. Benefits of Interchange

Contracts are portable and transferrable concepts that require interchange between parties to be effective. [NB: possibly there is a formal definition that should go here].

6. Requirements on the RIF

To be effective in handling contracts, RIF must

• Handle executable rules that operate against operational (W3C) data systems
• Provide sufficient structure to represent (rules of) the parties involved and the data they deal with
• Be inexpensive in representation (cost of transfer and cost of transformation) - RIF must be able to accomodate real-time performance requirements.

7. Examples of Rule Platforms Supporting this Use Case

There are 2 types of rule platforms in use for this use case: - COTS Commercial Off The Shelf rule engines and rule management systems such as Blaze Advisor. - Custom rule platforms supporting generic rule mechanisms.

For the ACORD/SPX model, both the above apply. ACORD/SPX uses XPATH as the rule expression language, XML as the data representation and transport, and can be executed by custom engines or commercial engines capable of running XPATH expressions against XML.

In other cases, an infrastructure vendor may choose a COTS rule engine (or any rule engine) and simply define their own interfaces for clients, such that the actual rule language used for rule interchange is common to the vendor system used.

8. Breakdown

Domain XML standards that embed contractual terms into data streams such as the ACORD/SPX insurance example). In this case the buyer and seller are to do with insurance.

NOTE: The ACORD/SPX model today uses XPATH expressions to represent rules; this use case in no way implies any policy change by ACORD in supporting RIF instead of XPATH. Fair Isaac is a member of but does not represent ACORD.

8.1. Actors and their Goals

• Buyer - wants to purchase insurance via an independent agent, and provide common information as much as possible to any insurance carrier
• Seller - wants to sell insurance using standardised information; however the information needs to adopt to changing underwriting requirements and the need for new information at any time. For example, in specifying AV equipment for insurance, an insurer may be interested in knowing if the customer now has a DVR (and/or DVD, PVR, etc).

8.2. Main Sequence

1. Seller defines insurance application form: extends the ACORD object model with custom fields for additional information, and adds validation and constraint rules (if state="CA" then EarthQuakeCoverageRequiredField must be true). Rules are embedded in the form.

2. Buyer completes form: agency management system or some other application executes the form's rules to ensure the form is complete. Form is transmitted back to the insurance carrier for further validation and application processing.

8.3. Alternate Use Cases

1. Similar case: an Independent State Operator handling power contracts will obtain contractual rules from various suppliers, and monitor these on their own systems by comparing these rules against realtime supply data.

9. Commentary

Rule interchange for contracts is a common use for rules which would benefit enormously from a common interchange format (ie RIF) to increase adoption.