"In general, a knowledge-driven DSS suggests or recommends actions to targeted users. This type of DSS has specialized problem-solving expertise relevant to a specific narrow task. The "expertise" consists of knowledge about a particular problem domain, understanding of problems within that domain, and "skill" at solving one or some of these problems."

While business rules are often used more to replace human decisions than to support them, they blur into the kind of systems Dan is discussing as many allow for some choice by users and most refer a percentage of transactions to a human operator. It seems worthwhile, then, to consider how a Decision Service compares. Dan had 11 items that characterize these systems, so here goes with some notes on each when it comes to decision services:

Asks questionsWhile a decision service might have an interactive dialog, often the information is "pushed" into the service rather than built with questions. This is a reflection of the forward-chaining approach to rules-based decisions and contrasts with the backward-chaining approach of expert systems

Backtrack capabilityThis is not typically a feature of a decision service and deliberately so. By and large the rules that should be followed are defined and there is little need to go back and forward in this way. Indeed, as most decision services are trying to make a decision absent human interaction, this is largely moot anyway.

Display confidence or certainty informationMost decision services will refer a transaction that cannot be processed. When referring it, the service may well describe why in ways that display confidence or certainty information. The ability of a decision service to refer something and explain why it was referred is a key benefit. Additionally, the use of predictive models may help manage uncertainty in decision services. For example, the use of predictive scorecards to handle risk predictions helps manage uncertainty by calculating a score from many additive factors, putting a numeric value on uncertainty.

Explain HOWA feature common to decision services and one of their key advantages over traditional code - explainability. A decision service knows exactly what rules and what models fired for each transaction and can log this. This allows for review and compliance.

Explain WHYSomething that is sometimes built into decision services but by no means a common feature, largely because they are not interrogative the way an expert system is.

Initiate actionsAbsolutely - this is what decision services do, or at least what they cause to happen. Decision Services cause actions to be taken, they don't just add to the body of knowledge.

Output selectionNot usually, most decision services are focused on a particular output.

Resume analysisThe ability to resume a decision is common when external data sources must be consulted. This is often not handled as "resume" so much as "retry with new data", however. Decision Services are designed to work inside transactions and so waiting and resuming is often not an option.

Retrieve data about a specific case or instanceAlways a feature of decision services as they are built to interact with corporate information systems. This data might be passed in or retrieved by the service as it needs it but it is going to access real data.

Store inputs, results and user actionsLogging is a common feature of decision services as noted above.

Train usersA decision service does not usually train users unless that is its ultimate purpose. The idea that using it will make the person able to not use it does not really come up.