## Generated by Codox

# Wildwood 0.1.0-SNAPSHOT

# Arboretum

This chapter describes briefly an inference mechanism, implemented in the Arboretum prototype; this is included here to show the results achieved in the author’s early work on explanation, on which it is hoped to build in the current work. A fuller description of this mechanism, and of the Arboretum prototype, will be found in [Mott & Brooke 87], from which this chapter is largely drawn.

Arboretum was written in InterLisp-D[4] using LOOPS [5] object oriented facilities, to allow people to manipulate DTree structures through graphical representations: to build arbitrarily large knowledge bases, to use these to provide answers to questions about objects in domains admitting incomplete information - and to provide natural language explanations of these answers. The inference process by which answers are produced is shown as an animated graph. The user can ask the system how the value of any particular feature was arrived at, and what that value was. . It was developed for the Alvey DHSS Large Demonstrator Project, and sought to meet early perceptions of the needs of DHSS Adjudication Officers. Adjudication Officers decide claimants’ eligibility over a wide range of welfare benefits. There is a very large volume of work to be done, so they work under considerable pressure.

The Adjudication process within the DHSS has its own levels of authority culminating in the

Office of the Chief Adjudication Officer. This monitors the quality of the decision making of Adjudication Officers, issues written guidelines to assist them in their decision making, and distributes information about changes in the benefit rules.

These modifications occur frequently, both to correct local anomalies and of course to reflect more substantial political changes in the provision of welfare. A static support system could not be useful because it would become outdated almost immediately. What is required is a system that can be modified and updated easily by the officials in the O.C.A.O.

The general context is then of a large organisation in which relatively numerous junior officials apply extensive and frequently changed legislation in limited time under the supervision of relatively few senior officials. The task of an IKBS support system is to maintain and if possible improve the decision making quality of the former and render more effective the supervision exercised by the latter.

We designed a system to meet these perceived needs around the DTree algorithm devised by Peter Mott. This algorithm interprets graphical data-structures (called ‘DTrees’) as rules of a non-monotonic (default) logic.

Our intention was that the system should access a legislative rule base composed of such rules, should propose a decision for the case in question, and should then draft a letter explaining that decision to the claimant. If the case was straightforward the Adjudication Officer would accept the suggestion offered by the machine. Otherwise (s)he could study a graphically presented trace of the machine’s inference process to assist in formulating an alternative decision.

One of the most significant advantages we would claim for the system as implemented is that it is extremely simple for relatively naive users to build knowledge bases. Knowledge engineering with this system requires no understanding of computer language, no very abstruse knowledge about the machine, and no complex calculation of weightings and probabilities. The logic is designed to facilitate a methodology which we call Elicitation by Exception.

The knowledge engineer’s task, using this methodology to build a rule, is simply to ask: is a given predicate normally true? If it were true, would it normally be a T sufficient condition? And having got this far, is there anything at all which would overturn the decision? If nothing could, the process terminates; but if there is some more abstruse factor which could still cause a change of mind, then that is added as a new condition and once more one asks if there is anything further that could cause a change of mind. Thus we proceed down a conceptual tree where at each level the decision just made is reversed.

Intuitively the deeper the level, the more unlikely the situations that occupy that level. It is our suggestion that the structure of exceptions that can explicitly be recovered by the knowledge engineer in this way is what is implicitly and imperfectly represented by the certainty factors in classical expert systems.

These trees can then be directly interpreted as rules by the DTree algorithm, the root idea of which is that a decision has always been made, there is always an answer available, but one which the system is currently trying to refute. The eventual decision is simply the last one made, the one that the system has failed to refute. At any point it tries to “change its mind”, and when it can no longer do so that is the decision it delivers. After all, if there is nothing as yet unexamined that could make you change your mind why deliberate further, while if there is how may you legitimately stop? The idea of an alternating ‘yes/no’ with decision characterised simply by its position at the end is a very old one indeed due to Thomas Hobbes (16]. The emphasis on trying to refute rather than trying to confirm is of course Popperian (passim, but see for example his [17]).

Let us summarise how to read a DTree rule structure. The basic units are nodes and the edges between them. An edge should always be read downwards, and, when connecting different colours, as meaning ‘unless’. Thus the most basic structure is “hypothesis is false unless condition is true”:

fig 1: simplest possible rule Conjunctions are represented by columns of nodes, only the last of which has the colour to be returned if all are true and disjunctions by branches, each of which terminates in the colour to be returned if any are true. These can be combined in any fashion desired, although we consider it good practise to keep individual rule structures small. This is shown in the figure below:

fig 2: example rule, showing syntax The rule would read: “(rootnode) is false unless (first conjunct) is true and (second conjunct) is true, in which case it is true unless either (first disjunct) or (second disjunct) is true”.

A DTree system contains at any time a number of features, objects and nodes. In a LISP implementation these are litatoms equipped with property lists; the LOOPS implementation is rather different but not in any way that affects the underlying ideas.

A feature has the properties:

    <methods DTreeRootnode default activeFlg>

where methods is the list of methods that the feature applies to see if it holds of the given object, DTreeRootnode holds a pointer to a DTree node if the feature is equipped with one (else NIL), default holds the default value of the feature, and activeFlg is simply a semaphore to prevent DTrees calling themselves.

A word more about the methods property. This may in principle hold a list of any functions that are to be applied (in the order found) with standard arguments by the feature when it is called. A feature may thus be seen as a local “expert” whose task is to decide whether it holds of a given object by applying the list of methods it has been supplied with (this picture was suggested by Lenat [18]). However, for the sake of simplicity, we shall henceforth assume, that the methods property is just the list (DoTree Default) and describe the algorithms accordingly.

A DTree for a feature is a list of nodes. A node has the properties:

    <feature, colour, children, parent>

Feature points to a feature of the system, colour is either Yes or No, children point to successor nodes of the node (if any) and parent to the unique predescessor node (NIL for the origin of the DTree).

An object is just a litatom. The system updates the property list of the object.

The top-level function call is (Decide Feat feature object). This first looks on the property list of object. If it finds (feature. Yes) or (feature . No) it returns Yes or No as the case may be. Otherwise it calls the features’s Dtree if there is one (using DoTree) or if not, returns a default value (using Default). Default may be a complicated function (indeed it may initiate a substantial train of activity) but for present purposes it may be thought of as simply recovering ’Yes or ’No from the default property of the feature.

The function of DoTree is just clerical, the work is done by DSearch. This function induces a subtree of the DTree, the leaf nodes of which are exactly those nodes from which no exit was possible. They represent the points at which the system can no longer “change its mind”. We call them stickNodes, and DSearch passes them to the function Decide.

DSearch uses left to right depth first search. which corresponds well with the conceptual structure of the DTree, exploring each possibility exhaustively as it arises; but other traversals are not ruled out.

This only leaves the function Decide. This simply scans the nodes submitted to it. If all of them have colour No then Decide returns No. But if even one has colour Yes then Yes is returned instead. This represents the fact that our domain rules provide sufficient conditions for access to a benefit. If you qualify by any of the criteria then the overall decision is Yes.

## The Explanation System

The explanation facility is the feature of the system which is of most interest to us here. Arboretum had two innovations in this field. The first was the Natural Language justification of decisions, which is the central matter of interest to us; but the graphical display, and in particular the animated search trace, also contributed to the user’s ease of comprehension of the systems decisions.

This system provided the equivalent of the more traditional “ask how” and “ask why” queries provided by other inference mechanisms. The user could see why a question was being asked, simply by looking at the display and seeing that the answer was needed in the evaluation of the current rule, whose result was needed by the preceding rule, and so on back to the question originally asked. To ask how a particular value was found, after completion of a run, we could point to a node representing the feature in question and select “How?” from the left button menu. The machine would respond by printing out a message saying whether the value was supplied by the user, evaluated from a DTree, or taken from a default. If a DTree had been called, it was displayed.

However, the natural language explanation system was vitally important to the usefulness of the system. Without it, the user must effectively take the decisions of the machine on faith, and in a domain with imperfect information that is dangerous; furthermore, the machine is reduced to giving yes/no answers. We could ask: ‘is this person entitled to benefit’, but not ‘which benefit is this person entitled to’. Of course the system with explanation could still only give ‘yes/no’ decisions, because that is the nature of the logic; but now it could say: ‘yes, this person is entitled to benefit; and the benefit they are entitled to is mobility allowance’.

The explanation system depended on and exploited the fact that DTrees are structured through exceptions from the very general to the more abstruse and particular; and that, in consequence, any path through a rule structure follows a line of coherent argument, again from the general to the particular. Thus a sticking node on the DTree for a feature both records a decision and, by its position in the DTree, implies an explanation of why that decision was made.

Consequently, we attached to each node in the system a text fragment to explain the consequence for the feature whose rule the node was in, if that node were a sticking node. This explanation fragment was a piece of canned text, written by the knowledge engineer.

When writing fragments, the knowledge engineer did not need to look beyond the DTree that was being edited. The task was simply to consider a node and attach text saying why the feature of the DTree obtained (or did not) when that node was conceived as the only sticking node. The structure of the system itself then ensured that in the final text, the fragment would follow sensibly from the preceding one.

This is described in more detail, with worked examples, below.

We discussed and experimented with several algorithms for the recovery of explanations. The one we used worked as follows: when a search resulted in a ‘no’ decision (ineligible for a benefit) then we concatenated the explanation fragments from the deepest sticking node in each succesive tree on the search path. The reason was that this represents the “nearest” that the claimant got to succeeding in the claim. This follows from the structure of the DTree, the deeper nodes represent more abstruse conditions: to reach them at all more general requirements for eligibility must have been met.

Furthermore, the information given in this explanation should be sufficient to assist in the preparation of an appeal, if the claimant felt there were further relevant facts which hadn’t been considered - and this was, indeed, precisely our intention. It is, we think, part of the notion of relevance that it is the “nearest miss” that should be described in such cases.

In the case of a ‘yes’ decision we chose the opposite approach and selected the shallowest sticking node available. This was partly because the claimant who succeeds is less concerned about why, but mostly because it is not relevant to describe how a long and tortuous inference path finally delivered ‘yes’ when a much shorter less involved one did so too. Again this seems in accord with ordinary ideas of relevance.

To provide a small worked example of an explanation generated by the system, which is yet large enough to give some flavour, let us assume our knowledge base contains the following rules:

fig 3: Rule for “Entitled to Widow’s Allowance”

fig 4: rule for “Living with Partner”

which, together, partially encode the following legislation fragment, from the Social Security Act 1975 [6], chapter 14, section 24, as amended by the Social Security (Miscellaneous Provisions) Act 1977, chapter 5, .section 22(2). This reads:

    24.-(1) A woman who has been widowed shall be entitled to widow's
    allowance at the weekly rate specified in relation thereto in Schedule
    4, Part I, paragraph 5, if -

      \(a) she was under pensionable age at the time when her late husband
      died, or he was then not entitled to a Category A retirement pension
      (section 28); and

      \(b) her late husband satisfied the contribution requirement for a
      widow's allowance specified in Schedule 3, Part I, paragraph 4.

      \(2) The period for which widow's allowance shall be payable shall be the
      26 weeks next following the husband's death:

    Provided that the allowance shall not be payable for any period after
    the widow's death or remarriage or for any period during which she and a
    man to whom she is not married are living together as man and wife.

Let us further assume we have entered at least the following explanation fragments, each providing an explanation simply in the context of the rule in which it appears:

1. on the node for “Living with Partner” in the rule for “Entitled to Widow’s Allowance”, the text:

> Although you satisfy the basic conditions for eligibility for Widow’s Allowance, you are not eligible, as we understand that you now have another partner."

2. on the node for “Remarried” in the rule for “Living with Partner”, the text:

> “We understand that you have remarried.”

Of course we would also enter text fragments for all the other nodes in our rules. Now assume we are dealing with the case of a widow whose previous husband had paid his National Insurance stamps as required, and who had not reached pensionable age at the time of his death. Assume further that, within the first six months of her bereavement, our claimant has remarried. The text that would be generated would be:

> Dear [name of claimant]

> Although you satisfy the basic conditions for eligibility for Widow’s Allowance, you are not eligible, as we understand that you now have another partner. We understand that you have remarried.

> Yours Sincerely

> [your name]

There are a number of points to notice. Firstly, we could easily have written far more friendly and less formal fragments; for example, We could have written “we wish you all the best in your new marriage”. The formality here is simply to help in understanding the mechanical nature of the concatenation process.

Much more significantly, note that although the inference engine must have known or discovered, for example, that her previous husband had indeed been regular and conscientious about his national insurance contributions for it to have reached its conclusions, this information has been ’included out of the explanation. It is irrelevant. It is clear that, if our claimant wished to make an appeal, her grounds for doing so would have to be that the information provided had been incorrect, and that she had not, in fact remarried.

## Explanation: a discussion

### Writing explanation fragments

Arboretum’s explanation fragments are canned text written by the knowledge engineer in constructing the rule system. However, because of the way they are concatenated, they are extremely easy to write. Each is basically just a declarative sentence saying, in natural language

    <name of feature at root node> is <colour of this node> because
    <name of feature at this node> is true and none of
    <names of features of children of this node> are true.

Thus, for the `Remarried -` node referenced above, the automatically generated canned text - had we automatically generated the text, which we did not - would have been

> Living with partner is true because remarried is true.

which would probably have been good enough. However, because texts are concatenated from the sticking nodes of the successive trees, we know that the previous sentence will have ended with some natural language expression of the proposition

> Living with partner is true.

Thus, provided we know that the tree for which we are writing the node texts is not the top level tree in the decision system, we can avoid rewriting this proposition. So the declarative sentence becomes simply

    <name of feature at this node> is true and none of
    <names of features of children of this node> are true.

But in this instance there are no children of the node `Remarried +`, so this reduces to

    <name of feature at this node> is true

The actual, manually written text used in the system, as stated above, was

> We understand that you have remarried.

As you can see, this sentence is a polite and understandable representation of the proposition

    Remarried is true

Thus, the claim I am making here - but mildly, it’s not a strong claim - is that even without hand written canned texts, the conceptual design of the DTree engine would allow the automatic construction of perfectly usable explanations.

Arboretum was the first deliverable system from the Alvey DHSS Large Demonstrator project actually to be delivered, and, I think, of the systems the project did deliver, the most polished and most functional, if not the most ambitious. However, it was not intended that the systems built by the project would actually be put into front line use, and indeed none ever were.

Nevertheless, in designing the system, we took very seriously the idea of how an adjudication officer would use such a system in the real world. It’s important for the officer to explain clearly to a claimant why a claim has been disallowed, in language the claimant will understand. Thus, manually written fragments made for much less stilted English, and produced a plausible verisimilitude of an entirely personal letter.

As one of the problems that the DHSS was experiencing at the time was appeals made because the claimant had not understood the reasons for a decision not to award benefit, these very simple, clear, apparently-personal letters seemed to us a significant feature in the potential usability of the system.

### Relevance filtering

This brings us to the question of how Arboretum managed relevance filtering. The answer, as the intelligent reader will already have spotted, is that we did not. Relevance fell fortuitously out of the process of evaluation. The deepest sticking node on each tree on the path to the final decision represents the ‘interesting’ reason to refuse, within the context of that tree; the concatenation of the ‘interesting’ reason to refuse from the successive trees along the path constructed the argument from the general to the particular which is precisely a good explanation of a decision.

What’s interesting about this was that in our later experience with KnacqTools, which was essentially a commercialised reimplementation of Arboretum on less illustrious hardware, we found that this explanation algorithm, designed to assist adjudication officers, provided explanations which were welcomed as clear and understandable in domains as diverse as industrial process control and the diagnosis of fish diseases.

## Conclusion

Arboretum’s ability to abstract relevant information from an inference engine’s backtrace represents a partial solution to the problem described in the preceding chapters.

## References:

3. Xerox Corporation: InterLisp Reference Manual (Xerox Corporation, 1985)

4. Daniel Bobrow & Mark Stefik: The LOOPS Manual (Xerox Corporation, 1983)

5. Mark Richer & William Clancey: “Guidon Watch: A Graphic Interface for Viewing a knowledge-Based System” IEEE Computer Gaphics and Applications vol 5 no 11,1985

6. Social Security Act 1975: Her Majesty’s Stationery Office, London, 1975 Social Security (Miscellanous Provisions) Act 1977: Her Majesty’s Stationery Office, London, 1977

7. D. Neligan: Social Security Case Law: Digest of Commisioners’ Decisions (Her Majesty’s Stationary Office, London, 1979)

8. Mark Richer: “An Evaluation of Expert System Development Tools” Expert Systems vol 3 no 3 1986

9. William Swartout: “XPLAIN: a System for Creating and Explaining Expert Consulting Programs” Artificial Intelligence 21, 1983

10. Peter Jackson: “Explaining Expert Systems Behaviour” paper given at Workshop on Explanation, Alvey IKBS Expert System Theme 20th-21st March 1986: available from the Alvey Directorate.

11. William Clancey: “The Epistemology of a Rule-Based Expert System - a Framework for Explanation” Artificial Intelligence 20, 1983

12. E. H. Shortliffe: MYCIN: Computer Based Medical Consultations (Elsevier 1976)

13. P. Hammond: “APES: A user manual” Research Report DOC 82/9, Imperial College, London

14. W. van Melle, E. Shortliffe & G. Buchanan: “EMYCIN: A Knowledge Engineer’s tool for constructing Rule-Based Expert Systems” (in Rule Based Expert Systems ed Buchanan, G. & Shortliffe, E., Addison-Wesley, 1984)

15. Diane Warner Hasling, William Clancey & Glenn Rennels: “Strategic Explanations for a Diagnostic Consulting System” International Journal of Man Machine Studies 20, 1984

16. Thomas Hobbes: Leviathan (ed C. B. MacPherson, Penguin 1968)

17. Karl Popper: Conjectures and Refutations (Routledge Kegan Paul, 1963)