PCjs Machines

Home of the original IBM PC emulator for browsers.


PC-SIG Diskette Library (Disk #976)

[PCjs Machine "ibm5170"]

Waiting for machine "ibm5170" to load....


MAE (Management Action Expert) is an expert system shell that can solve
problems in a non-procedural manner from an application of rules and
facts about a problem.

MAE reads a file known as a "knowledge base," and asks you a series of
questions to determine the cause of the problem. Based on the answers
and the information in the knowledge base, a recommended course of
action is given.

Create your own knowledge base with a few simple commands and use the
program for a variety of applications.


Disk No:  976                                                           
Disk Title: Management Action Expert                                    
PC-SIG Version: S3.1                                                    
Program Title: Management Action Expert                                 
Author Version: 3.2                                                     
Author Registration: $25.00                                             
Special Requirements: None.                                             
MAE (Management Action Expert) is an expert system shell that can solve 
problems in a non-procedural manner from an application of rules and    
facts about a problem.                                                  
MAE reads a file known as a ``knowledge base,'' and asks you a series of
questions to determine the cause of the problem.  Based on the answers  
and the information in the knowledge base, a recommended course of      
action is given.                                                        
Create your own knowledge base with a few simple commands and use the   
program for a variety of applications.                                  
1030D East Duane Avenue                                                 
Sunnyvale  Ca. 94086                                                    
(408) 730-9291                                                          
(c) Copyright 1989 PC-SIG, Inc.                                         


║             <<<<  Disk #976 MANAGEMENT ACTION EXPERT  >>>>              ║
║ To unarchive the program, type:  UNPACK MAE.ARC                         ║
║                                                                         ║
║ To run the program Management Action Expert, type: MAE (press enter)    ║
║                                                                         ║
║ To print the documentation for Management Action Expert, Type:          ║
║             COPY MAE.DOC LPT1: (press enter)                            ║


    Client Information: Access, Security And Technology.


The necessity of record keeping is reviewed.   Client privacy and
confidentiality are recognized as important determinants of
record keeping.   The grounds for policies and procedures to
govern record keeping, with primacy to client 'ownership' of
their own data, are reviewed.   Finally, the role of an emerging
computer software technology, Expert Systems, in assisting staff
to administer such policies is explored.


Keeping records is a vital part of any rehabilitation process.
They are necessary to track progress during a rehabilitation
episode and to provide continuity between episodes, even if these
are separated by years.   Records of all the services provided
within an organization are the statement of outcomes for that
organization, and at least in theory, the records of all the
organizations in a given area amount to the history of work in
that sector of the industry.   In not-for-profit agencies,
services are the outgoing side of the ledger, and records are the
beinnings of financial accountability for services.   Without
records, evaluation of service quality and effectiveness is a

Record keeping, however, is not without cost.   Tangible costs
are those of collecting, storing, processing and rectrieving
information and records.   Unless record systems are carefully
designed to meet information goals, they rapidly become costly
exercises in 'make work'.   And they can make plenty of it !
Since many of the costs are widely distributed or hidden amongst
other administrative overheads, the burden of record keeping is
frequently unrecognized.

Perhaps the most important and intangible cost of record keeping
is the loss of client or patient privacy, and the accompanying
risk of compromising client or patient confdentiality.   Any
serious client information system must address these issues.   It
is important for the organization to have a clear, formal policy
on the issues.   What is more, such a policy must be widely
communicated and the terms of this policy enforced.

The first step in developing such a policy is to consider the
issue of client consent.   What consent procedures or forms
currently function in your organization ?   Do they mention
permission to keep records and exchange information ?   It
important that a client record system rest on an adequate basis
of client consent. It is useful if the terms of the consent are
the same throughout the organization.   The wording of the
consent need not be legalistic, in fact in the interest of
informed consent it should be simple,direct and descriptive.

Such a consent should allow the organization to keep records as
necessary, for professional reasons only.   Permission to
exchange information with other relevant professionals and
agencies for the purposes of facilitating services to the client
should also be sought.

For a variety of reasons, clients may refuse to give their
consent for these activities.   It is their right to do so.   It
is useful if the policy guiding the administration of consent is
sufficiently flexible to allow clients to negotiate the terms of
a consent with which they will feel comfortable.   It is
important that the organization then work within the terms of
that consent.

Once the terms of the client consent have been settled the policy
maker should turn their attention to the question of access.
Who needs access to the client record and when ?   Related to
this is the issue of security, that is stopping people who have
been denied access gaining it in any event.

Internal access should be governed by the relevance of the
request for information to delivery of service to a client.
This will depend on the working arrangements of the organization.
If there is a heirachy amongst service deliverers this will need
to be catered for.   However, no one should have veto over access
policy.   The records administrator needs to be given the
organizational clout to say 'No' to anyone in the organization
who wants access to client information outside the agreed
guidelines.   Particularly sensitive areas should be catered for
with special access arrangements if necessary.   An example would
be enhanced security on the client record of people who have
received serives and work for the organization or clients who
serve on the board of management

External requests for information are relevant to the service
needs of the client and the terms of the consent obtained.   A
consent by the client to the requesting person or organization
can override those terms.   At any time, the client should be
given the opportunity of directing access to his/her record.
After all, the information collected is in a very intimate way
their property.   Approaching the issue in this fashion provides
a first principle which will clear away many imaginary barriers
and problems in administering record access.

Some external requests for information are of course
irresistable.   These are legally enforcable requests such as
subpoena and those made by government bodies with extraordinary
powers to force access, such as the Taxation Department.   Such
requests must obviously be complied with.

Security is an issue which is often thrown up during
computerization of the client information function.   People are
legitimately concerned that computer records may be more easily
compromised than physical ones.   Their faith in your answer will
depend on the integrity with which physical files have been
handled.   In general terms, it is in fact easier to define and
enforce security in a computer system than it is in a physical or
paper record system.

Many organizations do not take adequate steps to secure physical
files.   Files should be well controlled, housed in a secure
environment when not in use, and in accountable hands when they
are used.   Rooms which house record systems should be locked
when not under the supervision of a responsible manager and
filing cabinets must always be lockable.

Computer systems should have access controlled by password and in
shared systems, file protection mechanisms offered by most
operating systems should be used to guard against unauthorized
access.   Controlling access to actual computer equipment is also
effective in stopping casual inspection of records.   An
important point to note is that for the forseeable future client
record systems will consist of both computer and paper records,
and the need for adequate security on both is the same.

Once the points above have been resolved in terms which accord
with the philosophy and practice of the organization, and have
been agreed by relevant management, they need to be put into
practice.   Traditionally, this would involve drafting and
issuing a policy statement, and perhaps a procedural document.
If a manual of Policies and Procedures exists, then such
statements would be included in it.   An additional step would be
to include coverage of these policies in both orientation and
refresher training programs within the organization.

One of the classic problems which emerges is that such statements
of policy, when sufficiently exhaustive to cover likely
eventualities, become complex documents. While these state a
defensible position, they are not always useful to the staff on
the spot in assisting them to make their decision about releasing
or allowing access to client information.   People often do not
read manuals until they know they have made a mistake, which is
ironic because the manual is there to help them not to make that
error.   The problem is compounded when the issue is one which
staff confront infrequently, so lessons learnt in one epsiode can
easily extinguish before the situation is confronted again.

A computer technology called Expert Systems, currently growing in
use offer a possible avenue to address this problem.   Expert
Systems are a software technique for embodying decision making
knowlege in an operational way.   Procedures such as the rules
governing the release of client information are the sort of
problem domain in which they work well.

A variety of commercial systems to build Expert Systems exist,
ranging from very expensive systems designed to run on mainframe
computers, to relatively cheap systems to run on micro-computers.
I have designed and written a system (MAE or Management Action
Expert) to run on personal computers.   Using this tool I have
written an example Expert System to show how such technology
could be used to assist the staff of client service

Using the system is called a consultation.   When a consultation
is commenced the system loads the rules about client information
release (the collection of rules is called the 'Knowledge Base').
While it is doing that it, a preliminary Flag page of information
about the purpose of the Knowledge Base is displayed, as in
Figure 1.

                        Figure 1

                 Preliminary Expert System Display

    Management Action Expert [MAE] Inference Engine  V2.02       27-Dec-1987
    K Base is: a:cir.   LOG is: NONE.       Attributes = 8      Rules = 34
                   Rehabilitation and Welfare Agency
                      Client Information Release
                        Expert System Advisor
                     Author:   Charles C. Britton

            When asked for information about a client, it is
            very important to maintain client confidentiality,
            but at the same time aid service to the client.
            This system will help you in the decision about
            how much information to release to whom under
            what circumstances.



       Press any key to start Query
                  Knowledge Base Loaded

Once the Knowledge Base has loaded, the Expert System then
presents the staff member with a list of possible choices about
who is making the request for information, as is Figure 2.
Depending on the choice made here, the Expert System will prompt
for further information relevant to the decision path which is
being taken.   Thus, for instance, if Item 6 in Figure 2 (Co-
Ordinator) were chosen, the query

    What is the status of the client ?

       1)  NON-CURRENT
       2)  CURRENT
       3)  STAFF

would appear, whereas if Item 2 in Figure 2 (Solicitor) were
chosen, the query

    Has a subpoena for this information been issued ?

       1)  NO
       2)  YES

would be issued.

When the particular path produced by the queries and answers
concludes, the Expert System produces a recommendation for
action.   In the instance when the person requesting the
information is the co-ordinator, the client is a staff member, in
which the co-ordinator has a legitimate professional interest,
but for which the client has not given a specific request, this
system gives the advice that:

RELEASE_ACTION value is ...

Deny access, until Client consents to this request.

This is one of many possible paths through the Expert System, and
one of many answers it may give.   The point illustrated is not
the action that should be taken under the circumstances described
- your organization may well solve the problem differently.   The
point is that the person who needs to make the decision can be
stepped through the solution to the problem by the Expert System.
They did not have to wade through a five page document full of
details and policies irrelevant to the problem at hand.   The
system focusses attention on relevant factors, but makes sure
that steps in the decision process are not skipped.

                        Figure 2

                 Expert System Choice Display
    Management Action Expert [MAE] Inference Engine  V2.02       27-Dec-1987
    K Base is: a:cir.   LOG is: NONE.       Attributes = 8      Rules = 34

    Who is making the request ?

                  Choose the number of an option below:

    1)  CLIENT
    4)  MEDICAL
    5)  STAFF
    7)  OTHER


        Type  ?  for more information on prompt

The Expert System could be written to embody any set of rules
whch are agreed upon for the release of client information.   It
provides an alternative technology to paper and ink as a method
of communicating that policy to the actual decision makers on the
job.   What it does demand is ready access to computer resources
for those people to be able to consult such an advisor when and
as they need to.   This is a relatively simple example of the
technology at work, but the application of the technique to
larger and more complex procedural problems is simply a question
of working out an adequate rule structure.  In fact doing so
frequently forces a critical examination of the rules in place,
to the surprise of all concerned in terms of what is really
important in making the relevant decision.


                        Management  Action  Expert


MAE or Management Action Expert is a simple general purpose Expert
System shell.   A knowledge base, defined in terms of rules and
data about the components of the rules known as 'attributes', is
read by the system at the beginning of a 'consultation'.   Based
on the answers given by the operator, and the state of knowledge
generated by the internal operation of the system, a recommended
course of action relevant to the problem domain covered by the
Knowledge Base is given.  The system can be asked to justify it's
working at this point.

Expert Systems are part of the more general area of interest known
as Artificial Intelligence.   They are being explored by most major
corporations and many government agencies.   They have found practical
application in many industrial and commercial niches, where they
allow the knowledge of experts in a given field to be codified and
stored in an operational way which makes it available to people who
are less expert in the field.   Hence the term Expert System.

                       Operation of the MAE system

The Management Action Expert is invoked from the DOS prompt in
two ways:

          1) issuing the command MAE, thus:

                        C:>MAE <Return>

             The MAE program will load, and display a flag page
             of information about the system, and the conditions
             of use, see Attachment at end of this file.   To
             continue, press the <Return> key.

             MAE will next prompt you for the name of the
             knowledge base to be loaded. This is the name of the
             .KB (Knowledge Base) file as described below in the
             section entitiled Knowledge Base Documentation.   To
             run the demonstration knowledge base which
             accompanies the MAE program, you enter:

                        PC <Return>

             You are then asked for the mode of DEBUG you wish to
             generate.   MAE has the facility to generate a trace
             of it's internal workings.   This can be directed to
             the screen or written out to the printer or to a
             disk file with the name of the knowledge base  and
             the extension .LOG.   Using a Debug log may slow the
             system down, and is not required.   Unless you are
             developing a new system it should not be necessary
             unless you are curious to see what goes on behind
             the scenes.

         2)  issuing the command MAE, with the name of the KB you
             wish to use, thus:

                        C:>MAE PC <Return>

             The MAE program will load, and will then
             automatically load the nominated KB.   This is a
             useful feature if you wish to run MAE from a DOS
             batch file for instance.  You do not have the option
             of creating a Debug output and when the KB session
             terminates, your options are limited to consulting
             again or exit, you cannot load another KB without
             terminating MAE.

If a FLAG has been defined for the KB (see below) then the flag
text will be displayed during the rule load.

Once the Knowledge Base has loaded the second line of the screen
displays a status line, which shows you the name of the Knowledge
Base selected and the name of the .LOG file, or NONE.

How many rules and attributes are in the Knowledge Base are also
displayed on the status line when they have been loaded, and
their appearance indicates a successful load of the KB file.
The user will then be prompted to push Return to clear the screen
and continue with the KB query.

Once the load phase has completed, the status line for the
PC Knowledge Base is:

    Management Action Expert [MAE] Inference Engine  V3.20   15-DEC-1989
    K Base is: PC.      LOG is: NONE. Attributes = 22    Rules = 31

You will then be presented with the first prompt options for
information required by the system to solve the goal defined in
the KB file.   You have the option at this point of typing a
'?'.   In response, the system will display help text about the
question being posed.

After requesting help, or without it if it is not needed, you
select the number of the answer option which answers the question
for your problem.   MAE will either list another question and set
of answer options, in which case you proceed as above, or MAE
will provide you with a recommendation, such as the one below:

   FIX_PC value is ...

   Increase buffers allocated on BOOT.

The appearance of this recommendation indicates that you have
completed the consultation.

An alternative is that MAE will run another KB, or provide access
to an external file of information screens.   How this is
achieved is described in the manual below.   If either of these
outcome actions occurs, the next section about asking MAE to
justify the outcome does not apply.

You will then be asked if you want the system to justify why it came
up with this recommendation.   You must answer:


If you answer Y, MAE will display:

         Firstly, the set of facts you gave, or it discovered during
         the consultation, and the values attached to them.

         Secondly, the particular rule which was found to be true and
         render the recommendation.

If you answer N, or after these justifications have been displayed, MAE
will prompt you with three possible options;

         K: which enables you to consult this Knowledge Base again,
            perhaps responding in a different way and so provoking a
            different recommendation.

         A: which enables you to load a different Knowledge Base, and
            proceed to consult it.

         Q: which leaves MAE, and returns you to the operating system.

                       Brief Sample Session using the
                            PC Knowledge Base

What follows below is the briefest possible consultation with MAE.
The operator responses are enclosed in angle brackets <thus>.

------------------------ START CONSULTATION ---------------------------

Are the expectations of the user's realistic  ?

              Choose the number of an option below:

1)  NO
2)  YES

 --> <?> <Return>

Before complaint, users should be aware of the capabilities of the PC.

1)  NO
2)  YES

 --> <1> <Return>

   FIX_PC value is ...
   Send users on training course.

 --> Do you want the system justify this conclusion [Y/N] <Y>

   The reason for this conclusion is:
   The attribute EXPECTATIONS was given the value  NO

 -->  Press any key to continue

   This makes the following rule true:

 For the rule ROOT-4
 The correct course of action is :
 Send users on training course.

 -->  Press any key  to continue

------------------------ END CONSULTATION -----------------------------

                       Knowledge Base Documentation

The knowledge base consists of text rules stored in a single
file, the filename of which is effectively the name of the
knowledge base.  This should be a plain ASCII format file created
with a text editor, not a file from a wordprocessor which may
embed stray control characters in your text.

For example, one of the example knowledge bases is called PC, and
consists of a file called PC.KB.   This contains the goal and the
rules which ultimately satisfy the goal and the attributes for
the rule base, which  describe the aspects of the knowledge base
given values in the rules.

SYNTAX for structuring the Knowledge Base with MAE.
General Syntax:


        Comments are marked with an asterisk - '*'.

        Any material in a line after an '*' will be skipped when
        being read into MAE, so it should never be used in a rule
        or attribute element.

        Comments should be included to name the Knowledge Base to which
        the file belongs, to note the Author and Date created, and to
        record any significant edit history.   Much the same as for good
        program documentation. For example:

        *                       PC Expert System
        *                       ----------------
        *                    Author:  Charles C. Britton
        *                    Date:    February 1987

        Comments can also be used to delimit segments of the relevant
        file and for simple spacing between rules or attributes.
        For example:


        The knowledge base consists of 2 types of text, that which is
        used by the Inference Engine to make it's decisions, and
        that which is displayed when a decision is made or a
        question is asked.   That which will be used for screen
        displays must be surrounded by double quotation marks,
        "This material would be displayed on screen".
        Otherwise, MAE converts all unquoted lower case to upper
        case and strips all spaces away.   Only quoting one end of
        a screen literal will lead to unpredictable results from MAE.


        Spacing is not important, since spaces are
        stripped out, except where literal text has been quoted.

        GOAL definition.

        A goal must be specified once and once only in each rule
        file, in the form

              GOAL 'goal name' or PROMPT

              'goal name' must be an attribute defined as an
              attribute capable of being resolved as a goal. If
              PROMPT is specified, then MAE will prompt for a
              goal at runtime, when the goal must conform to the
              points above.

        FLAG definition.

        A FLAG is optional in the KB file.   If defined it will
        be displayed during the loading of the KB, so long as it
        is defined early in the KB file.   It can be defined
        anywhere.   Display of a flag page during the load can be
        a useful diversion for the user during a long load of a
        large KB.
        The start of a FLAG block of text is marked by the key
        word FLAG.   Flag text then follows.   Each line of such
        text needs to be enclosed in "double quotes".   The end
        of the block is marked with the key word ENDFLAG.

Rule Syntax:

        Each rule is defined as a block, beginning with the RULE
        operator and ending with the THEN operator.   The conditional
        and concluding parts of the rule are specified in between
        using the 'IF', 'AND', & 'THEN' operators.

              EXAMPLE RULE 1
              RULE  CPU-2
              IF SW8087 is YES
              AND INTERP is NO
              AND INVEST is YES
              AND INV is C
              THEN FIX_PC is "Install co-processor chip in PC."

        RULE specifies the beginning of a rule block in the form
             RULE;'rule label'
             'rule label' is an arbitrary label assigned by the
             knowledge base builder.   It serves no purpose for the
             operation of MAE, and should be chosen to reflect the
             tree structure guiding your development of rules, or
             some other useful purpose you may decide upon.

        IF specifies the first conditional attribute of the rule
        block, in the form:

             IF 'conditional attribute' IS 'value'

                'conditional attribute' must be an attribute
                defined as an attribute (see below).

                IS functions as a delimiter between the
                'conditional attribute and the 'value' specified
                in the instance of this particular rule block.

                'value' is the value which will satisfy this
                conditon of the rule, and which will either be
                obtained from the user in interactive dialogue or
                be derived from the operation of the Inference

        AND specifies the subsequent conditional attributes of the
        rule block, in the form:

             AND 'conditional attribute' IS 'value'

                'conditional attribute' must be an attribute defined
                as an attribute.

                IS functions as a delimiter between the
                'conditional attribute and the 'value' specified
                in the instance of this particular rule block.

                'value' is the value which will satisfy this
                conditon of the rule, and which will either be
                obtained from the user in interactive dialogue or
                be derived from the operation of the Inference

        THEN specifies the concluding attribute of the rule block, in
        the form:

              THEN 'concluding attribute' IS 'value'

                'concluding attribute' must be an attribute defined
                as an attribute.

                IS equates the value following with the
                'concluding attribute' within the MAE System,
                where it may either resolve the goal, or provide
                intermediate values for the context used to
                resolve the goal.

                'value' will either be:

                (1) a "quoted screen literal" in which case it
                    will be used to give information about the
                    resolution of the goal, (see example rule 1).


                (2) it will be an unquoted value which will be
                    tested in conditional parts of some other
                    rule block ( as in example rule 2).

              EXAMPLE RULE 2
              RULE ROOT-2
              IF OUTOFMEM is YES
              AND DISKACTIVE is NO
              AND EXPECTATION is YES
              THEN INV is M


                (3) it will contain a statement expressing a Goal
                    Outcome Command.   Such Outcome Commands are
                    expressed in a quoted string, beginning with
                    a > sign.   A space must be left between the
                    final command parameter and the closing quote
                    mark for the string.   Available commands

                    RUN.   This command will activate another MAE
                    knowledge base.  The KB which is RUN may
                    itself RUN another one.  There is no limit to
                    the number of KB's which can be nested in
                    this fashion.   When consultation with a
                    KB completes with an outcome which does not
                    run another KB, the user will be returned to
                    the original KB.   The general form is:

                    ">RUN KBname "

                    SHOW.  This command will provide access to an
                    external file of information constructed with
                    the accompanying program FRAMER.   FRAMER
                    commands are given in Appendix 1 to this
                    Manual.  FRAMER sets up a file of Screen Frames
                    keyed by values you supply.   These keys are
                    used in the SHOW command to access the

                    Once in the SHOW option, the user can use the
                    arrow keys to change screens (Up and Down),
                    while the Home key and the  End Key take them
                    to the Top and Bottom of the file
                    respectively.  The Escape key will return the
                    user to the MAE environment.

                    A number of options are available in
                    specifying the  SHOW command.  The general
                    form (where square brackets indicate optional
                    parameters) is:

                    ">SHOW FrameFilename [StartKey [TO Endkey] ] "
                                         [StartKey [N number]  ] "

                    Specifying a FrameFilename only will start at
                    the beginning of the File with all Show

                    Giving an optional StartKey will start at the
                    specified Key, with access to the full file
                    with all Show facilties.

                    Giving a TO Endkey clause will establish a
                    subrange of the File, for which all Show
                    facilties are available, restricted to the
                    Subrange established.

                    Giving an N number clause will give access to
                    the number of Frames specified in strict
                    sequential sequence.  Once the Sequence
                    completes, the User returns to MAE.   N 0 is
                    a special case, which will show just the
                    specified frame, and return the User to MAE
                    when they press the Escape key.

                    DUMP.  This command will cause Mae to dump
                    the Context Stack (the list of Facts  MAE has
                    gathered during the Consultation) to a file.
                    It is optional to specify a Dump File.   If
                    you do not, MAE will simply produce a
                    dumpfile with the name of the KB you are
                    using.   In any event the Dump File will have
                    a .DMP extension.  You must not specify a fie
                    extension if you specify a Dump File name.
                    The general form of the command is:

                    ">DUMP [DumpFilename] "

Attribute Syntax:

          Each attribute is defined as a block, beginning with
          NAME and ending with the key word END.

          These attributes describe the elements which appear in
          the RULE blocks as the conditional and concluding

          Thus, from the Example Rule 1, the conditional
          attribute SW8087 is described as below:

          NAME  SW8087
          TRANS  "Target software supports a co-processor."
          PROMPT  "Does target software support a co-processor [YES/NO] ?"
          HELP  "However, only specific software will utilize
          this delegation function."

          NAME specifies the beginning of an attribute block in the form:

               NAME  'attribute name'

               'attribute name' is assigned by the knowledge
               engineer, and is the link with the rule.   When
               the rule block is being examined by the Inference
               Engine the name is used to access Prompt, Help
               etc., as detailed below.

          TRANS specifies a non-question statement of the utility
               of the attribute in the form:

               TRANS  ' "quoted string of literal text" '

               This is used when justifying the results of the
               Knowledge base query.

          PROMPT specifies the form in which unknown data during
               a knowledge base consultation will be solicited
               from the operator, in the form:

               PROMPT  ' "quoted string of literal text" '

               This text needs to be carefully thought about
               since it is one of the main things a user will see
               in any system you design.   How easily these
               prompts are to understand will govern how usable
               the system is.

          LEGAL specifies the answers which MAE will display in
               the menu of answer options in the form:

               LEGAL  'legal answer','legalanswer', ... ENDLEGAL

               These legal answers must correspond to the
               alternatives specified in the value component of
               the IF and AND segments of the Rule Block.   These
               are space  delimited, and the string terminated
               with the key word ENDLEGAL.   There is no
               arbitrary limit on the number of legal values,
               although a sensible limit would be the number
               which can be accomodated on the screen at once.

          HELP specifies text to be displayed when requested by
               the operator, in the form:

               HELP;' "quoted string of literal text" '

               This text should amplify the information given in
               the prompt.

          END signals the end of the attribute block to the MAE
               input parser

Special attributes:

        There are a special class of attributes, which are not
        used in the same way as most.   These are the GOAL
        attribute, and other particular attributes which have
        been designed to function as links or branches in the
        knowledge tree, rather than to convey information at the
        leaves of the tree.   The following attribute of the PC
        knowledge base is an example.


        TRANS "Physical memory or way application uses memory be investigated."
        PROMPT none
        HELP none
        LEGAL none ENDLEGAL

        Note about this special form of the Attribute Block:

            1)    The PROMPT must be specified as 'none'
            2)    HELP must be specified as 'none'
            3)    the LEGAL none ENDLEGAL section

                       Developing A Knowledge Base
                              With MAE

The first step in developing a Knowledge Base for a given problem domain
is to develop an understanding of common problems, their solution and
the method by which that solution is obtained.   It is generally agreed
that for an Expert System to be successful it should address a a problem
area which has definable boundaries, within which there is a good measure
of agreement about solutions to problems.   If the solutions to problems
cannot be generated by a human expert, your Expert System will not be able
to generate them.   An expert system communicates the solution to problems,
and is totally dependent on the quality and organization of the knowledge
fed into it by the Knowledge Engineer..   What it does achieve however, is
the isolation of the knowledge from the mechanics of the decision making,
and makes available to the Knowledge Base Builder a non-procedural way of
building, that is, he/she does not need to be concerned with how the
inference engine solves the problem.

Next construct a TREE DIAGRAM of the way in which problems are commonly
solved.   You will find this an excellent 'navigational aid' as you develop
the actual rules and attributes of the system.   The initial tree of the
PC base looks like this:

                     EXPECTATIONS        <----------- node (Attribute)
               ---------------------     <----------- decision (Rule fact)
               |                   |
              No                  Yes
               |                   |
               |                   |
           ROOT-6*             DISKACTIVE
                         |                   |
                        Yes                 No
                         |                   |
                         |                   |
                      ROOT-1              OUTOFMEM
                                   |                   |
                                  Yes                 No
                                   |                   |
                                   |                   |
                                ROOT-2             CPUACTIVE
                                            |                   |
                                           Yes                 No
                                            |                   |
                                            |                   |
                                         ROOT-3              ROOT-5*

This TREE consists of nodes,  decision points, and outcome
'leaves'. The nodes equate to the ATTRIBUTES. The logic of the
decision points equates to the FACTS defined in the rule blocks.
The outcome leaves equate to the solution defined in the RULE
BLOCKS.   In the high level tree fragment shown above, most of
the outcomes in fact link to other tree segments. Those marked
with an asterisk (*) are true outcome rules.   You will find the
rules and attributes by name in the KB file.


Thus, rule ROOT-2, which is:

              RULE  ROOT-2
              IF  OUTOFMEM IS YES
              AND  DISKACTIVE IS NO
              THEN  INV IS M

can be seen to be derived from the tree.

Construct the rules and attributes for your knowledge base using
the tree as a guide.    In constructing the MAE rule,
ensure that the attributes in the rule are placed so that they trace the
occurrence of the attributes in the tree, as in ROOT-2.   That is,
EXPECTATIONS occurs first in this portion of the tree, so it is placed
first before the THEN clause.   DISKACTIVE occurs next, and is placed so.
Then OUTOFMEM is last.   When MAE finds this collection of rules to be
true, the system proceeds to the next segment of the tree.   If the
rule is one which defines a final outcome, the system halts and the
defined answer is issued.

Developing the rule base is a question of extending the tree.


Link from ROOT-2 which has made INV equal to 'M':

               |                   |
              Yes                 No
               |                   |
               |                   |
         MEMORY-1*             LOAD_OK
                         |                   |
                        Yes                 No
                         |                   |
                         |                   |
                    MEMORY-2              MEMORY-3

Link from MEMORY-3, which has made APP-PHYS equal to 'P':

               |                   |
              No                  Yes
               |                   |
               |                   |
         PHYSMEM-1*            MEMLIMIT
                         |                   |
                        No                  Yes
                         |                   |
                         |                   |
                   PHYSMEM-2*             EXTMEM
                                   |         |         |
                                   U         V         N
                                   |         |         |
                                   |         |         |
                             PHYSMEM-5*  PHYSMEM-4*  PHYSMEM-3*

Note that in this final tree fragment, all the outcome leaves are
starred.   Therefore when MAE reaches this end of the tree, a solution
must be found.   If you leave some solutions undefined, MAE will
terminate the operation of the system with a message indicating there
is an inconsistency in the rule base.

To repeat, the things at the nodes are the names of attributes.
The things at the end of the lines at the decision points are the names of
rules which satisfy the cumulative effect of the decision points past.

By setting up the decision tree and coding your knowledge base from it,
you are making the operation of the problem solving choices an expert makes
clearer.   Unlike an ordinary tree, you climb downwards, but as you go
the trunk branches with the first decision, and then goes on branching
according to the choices you continue to make.   As you climb down, each
decision closes off alternative routes for MAE until you reach a terminal

                           MAE UTILITIES


         This utility program takes a MAE Knowledge Base file
         and parses it to check for errors and create a disk
         listing file to page and title the KB you have created.
         Unlike the error checking during the live MAE KB load,
         MAEPARSE will attempt to continue parsing the KB after
         it has detected an intial error.   With this
         "incremental" style of error checking, a number of
         errors can be picked up in one pass thru the parser.
         For an example see the TEST.KB and TEST.LIS files which
         should accompany this one.

                           VERSION NOTES


This is the introductory version of MAE.   Directions for future development

        -further development of the boolean function definable in the
         rule with NOT and OR.
        -introduction of a facility to store 'static data', which the
         system would prompt for at the beginning of a consultation.
        -improved DEBUG info in the Debug Log File.
        -a back-tracking facility, to allow the logic of the rule base
         to cater for reversals within the tree structure.
        -arithmetic operations defined in the rule base and executed
         within the Expert System shell.
        -better error detection for rule and attribute parsing.
        -development of a pre-processor to allow more automated development
         of the rules and attributes.
        -development of utility programs to aid knowldge base file

Version 2.0

        -the parsing aspect of MAE completely rewritten, so that
         1 KB file is used.
        -FLAG implemented.

Version 3.00
        Converted to Turbo Pascal Version 4.0
        Set MAE to RUN another KB if defined in the Goal Attribute of
        a rule, Format 'goal IS RUN kbname' where kbname is valid name
        of an existing KB file.

Version 3.10
        Added ShowUnit features to enable random access to Indexed
        Information files from the GOAL outcomes and Dump file

                          FLAG PAGE ATTACHMENT

********************* Management Action Research Systems ******************
                               P R E S E N T S

                      MAE (Management Action Expert) V3.20
                       An Expert System Inference Engine

*** Written by Charles C. BRITTON **************** (c) 1987,1989 *****

MAE is an Expert System shell, which means that it will solve problems
in a non-procedural manner from a description of rules and facts about a
problem domain. To find out more  about the syntax required for these
read the documentation files which should accompany this program.

MAE has been placed in the Public Domain by MANAGEMENT ACTION RESEARCH
SYSTEMS mainly for the purpose of helping you to learn about expert systems
and how they work.   To that end a sample Knowledge Base is included along
with the system documentation on disk.  Please use this program freely and
share it with friends and acquaintances.   Do not sell it for a profit.

Management Action Research Systems and the author will not be responsible
for any loss or damage arising from the use or misuse of this program by
anyone in any circumstances.

If you wish to learn more about Expert System technology, you may care  to
to register with Management Action to receive the source code(*) of this shell
PLUS a database of more than 500 book, magazine and newspaper references
to Expert Systems,and Artificial Intelligence.  It is growing all the time.
This will cost you $150. You also get the most up to date version
of MAE. Register to P.O. Box 47,Dulwich Hill, N.S.W. 2203,Australia.

To continue, press the <Return> key.

(*) Turbo Pascal source

Directory of PC-SIG Library Disk #0976

 Volume in drive A has no label
 Directory of A:\

ARC      EXE     32051   1-31-86   1:19p
FILE0976 TXT      1925   1-04-90   2:16p
GO       BAT        38   1-28-88   4:33p
GO       TXT       771   1-05-90   4:19p
MAE      ARC    196225  11-01-89   8:57a
UNPACK   BAT       199  12-10-89   4:03p
        6 file(s)     231209 bytes
                       88064 bytes free