'S ;S

Phtgrp by Ei n RasAln

0885-9000/87/0800/0051/ $01.00 1987 IEEEFALL 1987 51

planning, investment, risk management, borrowing,retirement, special-needs funding, and estate planning.Good financial plans provide coordinated recommen-dations covering actions to be taken in these areas overtime-all in the context of client specifics such as age,financial status, anticipated needs, and financialattitudes.While expert systems have begun to show potential

in a broad range of business applications,1 developinga system from prototype to useful product has provena major obstacle. APEX-Applied Expert Systems,Inc.-attempted to overcome this obstacle with itsPlanPower research. PlanPower contains an opera-tional expert system, used by financial planners, thatproduces high-quality and comprehensive financialplans. This article describes PlanPower's developmen-tal history and its overall expert system architecture.

The original development team began work on thePlanPower project in 1982, defining the problem andinitiating market research studies. The notion thatexpert systems technology might be applicable ledthem to build a small prototype-a simple productionrule system written in Franz Lisp on a VAX 11/780that took about four months for one program-mer/knowledge engineer and one part-time expert todevelop. They used this prototype to identify technicalproblem areas and to estimate the size and cost ofbuilding a full-scale operational system, concludingthat the market was large enough and the technologyappropriate. They also felt that, to support commer-cial applications, the technology needed to evolve.They considered tax-related issues the largest knowl-edge area, estimating that it would contain about 40percent of the system's knowledge.

Applied Expert Systems (APEX) was incorporatedin late 1982 and started operations at the beginning of1983. It had a development partner a firm that sawthe potential of expert systems and wanted to be firstin the market with such a financial planning tool. Thiscustomer provided further market input and systemfeedback throughout the development cycle, andgreatly influenced decisions about what knowledgeareas were included and how deeply each was covered.From the beginning, we at APEX had a strategy

about the development team's composition. We clearlyseparated knowledge engineers from "systems"programmers. Knowledge engineers focused on the

financial domain and tended to have financial back-grounds. Some began with limited programming expe-rience; others were well versed in traditional dataprocessing. This mix ensured good communicationsbetween knowledge engineers, financial experts, andthe systems group.

Systems programmers focused on underlying tech-nology and had backgrounds either in Al or in tradi-tional data processing. APEX mixed these culturescarefully, seeking a methodology for commercialexpert system development. Throughout this develop-ment, tensions existed between good data-processingmethodology (requirements, specifications, design,implementation, and testing) and good expert systemsmethodology (an evolving sequence of prototypes).Expert systems methodology dominated the earlystages because the task proved complex and difficult.Knowledge engineers and systems programmersworked together during this period to develop aknowledge architecture and an appropriate develop-ment platform. As these became clearer, the twogroups worked more independently.The knowledge engineering team, with a primary

expert, devoted early 1983 to learning more aboutfinancial planning. By April, they understood enoughto attempt a second version-a somewhat larger pro-totype built in EMYCIN,2 licensed from Stanford, andported to the Xerox 1100. This effort required twoknowledge engineers, two systems people, and about amonth. Primarily, it explored production rule technol-ogy as a basis for the system. We concluded thatEMYCIN's technology was inadequate, particularly incontrol structure and data representation areas.We obtained an early Loops3 version from Xerox

and built our third prototype in that system-an efforttaking until July and involving four knowledgeengineers, four systems people, and three experts. Thisprototype resolved issues regarding what experts weneeded and where the problem was most difficult. Wediscovered that tax was merely a subproblem of invest-ment decision making. We also concluded that the sys-tem required multiple experts. Generalist financialplanners could cover overall strategies and knowledgeintegration, but we needed specialists (an estate plan-ner, for example) to get depth. We discovered thatfinancial planners often work in such mixed groups.We attempted a knowledge base specification at this

point, which was relatively useful although wecouldn't find a succinct way to express everythingknowledge engineers knew about the depth of knowl-edge in each domain area the system had to cover.While it guided the next few months' work in a

IEEE EXPERT52

general sense only, the knowledge base specificationcommunicated to our customers what the systemwould generally know.We completed the fourth prototype-a more ambi-

tious effort aiming at both the knowledge base andthe total system picture (including the user inter-face)-by the end of 1983. And we finally had realproof of feasibility: The problem was circumscribed, a

solution structure was in place, some knowledge engi-neering was done for major knowledge areas. overallsystem architecture was known, and a first-pass user

interface had been implemented. This prototype tookeight knowledge engineers, six systems people, fourexperts, and ran on top of Loops on Xerox 1108s.While significant changes would still be made to theknowledge base architecture and the platform, theproject had changed from experiment to product com-

pletion.We started implementing the production version

early in 1984. The APEX team had grown to 10knowledge engineers, 12 systems people, and sixexperts. To ensure the consistency of knowledgeobtained from different experts, several experts met as

a panel for overall review. Management style changedfrom the loose prototype-and-see-where-we-getapproach to a planned-milestone method. We gener-ated and maintained specifications at both system andknowledge base levels.By the spring of 1984, a knowledge base information-

flow diagram covered one office wall. It becameapparent by mid-year that we had built (1) an interfacesoftware layer, (2) our own rule-based languagebetween Loops and the knowledge base code, and that(3) we were no longer using Loops directly. In effect,we had built a platform specific to our needs on top ofLoops. New features had been added, some featureshad been adapted, and others were not used at all.We felt that a great deal of overhead existed in this

extra layer, so the systems team extended our own plat-form downward to Lisp-an implementation tailoredto just what the problem demanded-and we were

able to make optimizations when full generality wasn'tneeded. Ultimately, we obtained several-factor gains inboth speed and space. We feel that-while using Loopssped development by a year-our product required a

custom platform. Since that time, of course, commer-

cial expert system shells have appeared and continu-ously improved.The system went into field test in May, 1985-and

testing took precedence from then on. While system-level testing was relatively straightforward, qualitycontrol of the knowledge base remains difficult for

want of a methodology ensuring adequate coverage ofthe possibilities. We treat knowledge base testing as an

art relying on carefully chosen test cases and detailedreview by financial planning experts. Consequently,knowledge engineers must be closely involved indeveloping test cases and predicting the impact of"fixes" to the knowledge base.One general heuristic-examining boundary condi-

tions or extreme cases-proved useful; for example,such examination uncovered a serious bug when theclient was running a deficit. The risk module "real-ized" that dependents would be left with insufficientincome, and recommended buying far more life insur-ance than the client could afford. Of course, this rec-

ommendation aggravated the deficit. The correctsolution addresses the deficit first.

Xerox announced the 1186 Lisp machine in August,1985. APEX formally introduced and demonstratedPlanPower on the Lisp system at a financial planners'conference in September, 1985. Volume shipmentscommenced in April, 1986. Thus, PlanPower spent a

full year in field test-all of it needed to achieve com-mercial robustness. The system is now in a

maintenance-and-enhancement mode, with releasesoccurring every three to six months.

Users can run PlanPower in a fully automated man-

ner to produce financial plans, or in an interactivemode as an expert support system. The interactivemode requires a full complement of standard worksta-tion software (data entry forms, database and query

systems, spreadsheet and word processing software,what-if modeling, and so forth). All of these were

built in Lisp and integrated into a standard user inter-face. PlanPower uses Xerox's Tedit word processor,but we replaced Tedit's user interface to ensure systemconsistency.We base client data for system input on an 80-page

questionnaire; however, not all 80 pages need be com-

pleted since many values can be defaulted and inap-plicable sections can be skipped. A shorter summaryquestionnaire can be substituted. Users enter informa-tion through a forms system that uses the worksta-tion's graphics capabilities and provides selection

FALL 1987

PlanPower must continuallyexamine the entire picture

during planning.

n

53

Figure 1. The expert's high-level architecture.

menus, default calculations, and error checking toexpedite the process. We store the input in a data file;users can convert this into a knowledge base of frameinstances by running a program called the Casemaker.

PlanPower provides clients with financial plansranging from 20 to 120 pages, plus up to 40 tabularand graphics data exhibits. The expert system also cre-ates an after-planning case representing the client's sit-uation after all recommendations have been simulated.Planners can examine these by viewing exhibits andcan experiment by simulating further recommenda-tions of their own.

The system also allows planners to influence theexpert's recommendations in various ways: Specificrecommendations like using a certain asset as col-lateral for a loan may be prohibited; objectives such astarget percentages for asset categories may be specifiedeither directly or by changing properties used to deter-mine the objective; priorities may be affected by coerc-ing the system to consider a particular recommendation;and investment features such as yields can be alteredto affect the expert system's available choices. Whilequite extensive, this capability has been carefully tai-lored to maintain reliability. For example, although wecan coerce the system to consider a type of investment,it will not necessarily recommend one. Planners aren'tallowed to change rules themselves, for that wouldraise a difficult problem-ensuring that the expert'srecommendations follow a consistent planningstrategy.The following scalars provide some sense of the sys-

tem's size: The expert has both a frame-based repre-sentation of static data and a procedural representation

for its heuristics. The frame system contains about 500classes, about 2500 slots, and about 1500 when-neededprocedures that calculate relatively simple functions(for example, the equivalent of a taxpayer's 1040form). Most slots (both primitive and when-needed)contain time-varying data.The system incorporates about 1200 chunks of heu-

ristic procedure-knowledge that tends to be groupedin pieces larger than we consider typical for produc-tion rules. We estimate these chunks roughly equiva-lent to 6000 simple rules (each containing about 3-5antecedent and 1-2 consequent clauses).

InterLisp-D is about a 3M-byte memory image in aXerox Lisp machine's compact representation. Plan-Power is delivered in a memory image (including Lisp)that takes about llM bytes. We estimate that thewhole system contains about 250,000 lines of Lispcode.

PlanPower's expert is a highly complex programembodying much detailed knowledge and orchestrat-ing many interactions. We applied considerable effortto provide an overall architecture enabling theseknowledge fragments to cooperate in producing finan-cial plans of professional quality. Some major stepstoward automatically creating financial plans follow,illustrating how expert system technology made thislarge-scale problem tractable. Along the way, we will

IEEE EXPERT54

discuss some trade-offs caused by the nature of theproblem.

Figure 1 illustrates PlanPower's architecture at thehighest level. Process input consists of a problemdescription including the client's financial and per-sonal data, attitudes to risk, and goals. To control theexpert, planners can add data for this specific case orthe generic knowledge base. The knowledge base pro-vides a comprehensive set of frames describing invest-ment vehicles completely enough for the system to(1) model a financial transaction and (2) determinethe complete effects of that transaction consideringthe applicable time frame and macroeconomic varia-bles such as inflation rate.

Processing comprises three stages: before-planningobservations, planning and recommending, and plandocument production. The first stage represents acomplete diagnostic expert system in itself-its majortask is to analyze the client's current financial situa-tion, projecting this into the future and providingobservations summing up positive and negativeaspects. The knowledge base provides generic finan-cial observation frames from which the expert canchoose to construct problem descriptions, worthwhilegoals to pursue, and comparisons between the client'sposition and the recommended position for clients insimilar stages and income levels. Observations can bequite simple (such as noting that client debt paymentsare high proportional to cash flow) or quite complex(such as evaluating client tax situations, allocatingassets into various investment categories, and deter-mining whether clients would achieve their goals if norecommendations were followed).

Observation. Processing in the observational stageevaluates backward-chaining if-then rules. Each rulemay make an observation in its own area either byinvoking other rules or by evaluating and logicallycombining predicates that apply to the case data.Some lower level rules could be implemented equallywell in a forward-chaining manner, but higher levelrules may make control decisions best handled bybackward chaining. Such rules can decide not onlywhether a particular observation is true but whatobservations should be attempted.

Since general techniques for language productionwere not adequately developed, we provided a speciallanguage (Computed Text) enabling knowledgeengineers to specify rules that build the documentfrom facts and frames in the knowledge base thatresults from planning. At one extreme, the languagelets knowledge engineers specify formatted boilerplate

text and customize it to the data (as in traditional let-ter merge programs). At the other extreme, it allowsthem to write rules determining in top-down fashionhow to arrange plans and what to express. Rules canquery the database to decide whether a certain sectionshould be included, and at what point. They cansearch for recommendations or explanations relevantto the point at hand, and they can decide how to pre-sent them. The language facilitates access to knowl-edge base information. A limited set of syntaxgeneration primitives allows knowledge engineers tospecify methods for handling constructs such asplurals and possessives.

Of the three major processing stages in PlanPower'sfinancial planning expert, plan generation is the mostcomplex. Its structure can be compared with anautomobile's, which has numerous subsystems (likethe fuel system and the electrical system) that interactclosely. PlanPower's subsystems are modules, each ofwhich is expert in a specific area such as retirement,insurance, asset allocation, and tax planning. Thesemodules are carefully coordinated.

Figure 2 expands plan generation into its nextarchitectural level, where we can more clearly see sometechniques used to structure problem solving andmanage the large space of constraints and possibleactions. Because of space limitations, however, manydetails are not covered here and even entire processingmodules are not described.

Planning's first step rules out as much as possible,creating a focus of attention that will drive the plan-ning process. In effect, the expert evaluates all possibleactions on all available investment vehicle types anddecides whether to consider them in depth. It also exa-mines the client's current specific assets and deter-mines whether to modify these assets (for example, sellthem). The system creates a possibilities list usingbackward-chaining rules that evaluate particularinvestment vehicles or general classes of investmentvehicles. In fact, these rules are indexed into theknowledge base's frame hierarchy so that (while simi-lar to regular if-then rules) the rules are invoked in away that takes advantage of the object-oriented pro-gramming paradigm.5

Planning and recommending. The planning stagedetermines what actions clients should take to

FALL 1987 55

Figure 2. A partial architecture of the planning stage.

optimize their financial positions over the succeedingyears. Planning is the most complex stage by far sincenumerous different constraints must be accounted forand the possible combination of actions is considera-ble. Moreover, the far-reaching effects of financialactions oh client situations prevent us from indepen-dently treating goals and problems discovered in theobservation stage.

During planning, the system must continuallyexamine the entire picture. Planning produces recom-mendation frames, most of which detail particularactions that clients should take. These frames form aplan in the sense that the system specifies actions,their timing, and their exact parameters to addresstwo top-level goals: increasing the client's wealth, andprotecting the client's assets. Applying each action atthe recommended time will (1) improve the client'sposition regarding these goals, (2) determine if anyspecial funding objectives can be met, and (3) followaccepted financial planning guidelines.While some goals may not be achievable at all (like

buying a vacation home), others are not binarychoices and can be satisfied to varying degrees (likediversifying assets, reducing taxes, increasing networth, improving cash flow, and providing for retire-ment). Planning must evaluate goals as a whole andchoose actions that optimize the total position. Forexample, reducing taxes is simply one possible meanstoward an end. It is valuable only to the extent that itcontributes toward the system's top-level goals.

Besides its main task of producing action plans, theexpert's planning stage also constructs explanation

frames in the knowledge base. These frames justify itsrecommendations and record significant decisions orevaluations made during its processing. They includereferences to contextual data used by the expert'srules as well as pointers to general financial planningprinciples providing background rationale for thereasoning (while not being a part of the logical argu-ment). The former can be viewed as the set of argu-ments used by rules, while the latter providesjustification for using rules at all.The knowledge base includes financial models that

support planning and observation. These models con-sist of perhaps 1500 rules and procedures for makingfinancial calculations regarding net worth, cash flow,tax situation, yields, investment costs, and the like.They also allow logical evaluations of resulting num-bers. Although intricate, these rules are straightfor-ward since they embody accounting procedures ratherthan financial planning expertise. The expert's obser-vation and planning stages can access financialmodels on demand. Whenever the expert requests afact that is part of one of these models, that modelwill calculate it (if necessary) and store the result untilit becomes invalid.

These models, evolving over PlanPower's history,led to an interesting discovery about the financialplanning domain-a discovery that forced significantredesign. Originally, the rules comprising thesemodels were joined in a complete dependency net-work. Whenever data was changed, the dependencynetwork ensured that exactly those facts depending onthe change would be recalculated the next time they

IEEE EXPERr56

were needed. Al programs have used this techniquefor years.4 While the network provided correctbehavior, it was excessively slow.Examination showed the facts to be so intercon-

nected that (1) even minor changes affected largeamounts of data, and (2) many facts the expert wasinterested in using after a change were located at theend of the dependency network. This caused most ofthe data to be marked for recomputation after eachminor change, almost entirely wasting the networkmaintenance overhead. Consequently, we replaced thenetwork with a simpler scheme that marked largeinformation blocks as needing recomputation after achange. This marking was extremely fast. Since thesystem invoked rules by backward-chaining, reprocess-ing remained demand driven and the expert couldmake assertions without actually triggering recompu-tation until the financial models received a subsequentrequest for information.

In problem areas such as this, where significantnumerical calculation exists, an extension to thedependency network approach looks promising. Thisextension has not been implemented, but can be illus-trated by a procedure that finds all the assets of a per-son and adds up their values-a procedure requiringmultiple retrievals and additions. If one asset's valuechanges, or if the set of assets changes, the proce-dure's result should be declared invalid. Rather thanrecalculating, as a simple dependency network would,a procedure can be invoked to modify the oldresult-a procedure requiring only one retrieval andone addition.

Plan document production.The third processingstage, producing the plan document from the after-planning case, presents (1) the diagnosis of the client'ssituation, (2) recommended actions that should betaken, (3) explanation and rationale for these actions,and (4) relevant background information about finan-cial matters. The document had to be well organizedand written in good English, which posed a problemsince language generation is difficult even in limiteddomains and our domain was extremely large andcomplex.

The possibilities list forms a kind of agenda workedon throughout the planning stage. When an item isfirst added, criteria considered include such conditionsas the state of the economy, financial rules concerningsuch investments, tax implications, client preferencesfor keeping or acquiring such investments and, ofcourse, observations resulting from the first processingstage. The expert prioritizes possibilities by comparing

them in light of the current situation and objectives.Directives input by the planner at the start of process-ing significantly affect this part of the reasoning.

At this point, the transactions on the possibilitieslist represent only abstractions of the final actions tobe recommended. The specific types of investments tobe used and the exact amounts and timing of thetransactions are still to be determined. The problem cannow be considered as a refinement process in whichthe detailed actions to be recommended are developedfrom the rough description on the possibilities list.The space of possibilities is large and the constraintsare very complex. The changes produced by eachaction need to be evaluated in light of all the informa-tion produced by the financial models, general princi-ples of diversification of assets among categories, andconstraints provided by either the client or the plannerin terms of preferences or objectives.

PlanPower addresses this problem in several ways.First, we have studied the domain thoroughly,developing heuristics to order some possibilities. Forexample, when transferring assets to achieve a desiredtarget within an asset category, a particular order maybe preferable. The system can prioritize specific invest-ments or types of investment to sell or buy. In suchcases, assets can be bought in that order until the goalis satisfied and then the process may stop. Otherheuristics can modify this process-to prevent buyingtoo much of one asset at one time, for example(thereby reducing risk).When we first examined financial planning, the

complexity of the process appeared overwhelming.However, ordering can sometimnes govern the resolvingof separate goals. For instance, the system always han-dles insurance needs before allocating discretionaryassets. Extensive knowledge engineering revealed thatmany choices could be decided beforehand or couldbe decided more simply than expected. We should notexpect the system to solve planning problems fromfirst principles or to master financial planning.Experienced financial planners have, in effect, com-piled the results of their experience. Codifying this isnot easy, but is important if the resulting system is tobe an effective product. It is also easier to representwhen knowledge engineers have a convenient way toexert procedural control over the program.

Developing rules that estimate the effect of execut-ing actions is a technique that allows the system todetermine details, such as investment amounts, with-out simulating many possibilities. Estimates are thenchecked by simulation and adjusted if necessary. Plan-Power can set up temporary contexts as hypothetical

FALL 1987 57

situations in which to perform these checks.In some cases, the system must resort to a search. It

may find appropriate actions for achieving goals bysearching a few carefully chosen possibilities and dis-carding all but the best. We devoted significant effortto finding heuristics that minimize this search space.Even small changes can propagate effects over wideareas in this domain; therefore, fully evaluating singlehypothetical situations is expensive.Throughout planning, an asset allocation model

modulates action recommendation-a modelcategorizing assets into types such as tangibles, realestate, and fixed income. This model provides objec-tives for investment proportions that clients shouldachieve in each category. Initially, the model decidesthese objectives based on the client's situation-onparameters such as the state of the economy andwhether the client is at an early or late stage of finan-cial development. For example, the client may beaccumulating assets or may be nearing retirement. Asplanning proceeds, however, it may become clear thatideal asset allocations cannot be met. The modelgradually relaxes its constraints while the remainingsystem attempts to meet its revised goals.

The planning stage produces frames that provideexplanations of the expert's observations and recom-mendations. Early in PlanPower's development, werealized that we could not rely on fully automaticexplanation generation mechanisms for several rea-sons. First, such a mechanism would have difficultyseparating out the expert's relevant decisions: Somewere simply decisions about processing order; otherswere trivial; still others were correct but not the mostrelevant explanations for users. Appropriate explana-tions might actually have been part of the rationalefor writing rules in the first place, but may not be rep-resented in rules at all. For example, one rule statesthat selling treasury bills is pointless because they'reshort-term investments-we might as well wait untilthey mature. In PlanPower, this may be represented as"do not sell if x is a T-bill." The relevant rationale isnot necessarily part of the operational decision. Thisproblem has been cited before.6

Second, fully automatic mechanisms were unableto generate explanations fluent enough to satisfyfinancial planning product needs. Generating relevant

explanatory information, and preparing high-qualityexpositions of it, are active research areas.We addressed the first problem by allowing knowl-

edge engineers to specify what was relevant to anexplanation and what should be explained. Knowledgeengineers represent these important facts and deci-sions as observation frames in the knowledge base.When the expert system runs, its rules create instancesof these frames and fills them with context informationtailoring them to the specific situation. Knowledgeengineers can also specify which observations provideexplanations for which others. In the worst case, par-ticular instances can be explicitly linked. In mostcases, however, a two-step approach is more con-venient. First, the knowledge base is provided withgeneric assertions about which types of observationmay support which other types. Then, when observa-tion instances are created, they're given refinementassertions that usually refer to objects in the currentenvironment. We find particular supporting explana-tions for a supported observation by filtering genericobservations that could support it; by so doing, welocate those generic observations that have been givencontextual tags matching the supported observation'srefinement assertions. This approach allows somedecoupling of supports from supported observations,enabling dependencies to be set up easily betweenobservations created in separate rule invocations.We created fluent English explanations by associat-

ing rules from the text production language with vari-ous observation types. These rules can access anycontextual information associated with the instance ofits observation frame, and knowledge engineers canhave rules tailor text to that information-therebymaking available the full expressiveness of the textlanguage.

While previous sections have described the Plan-Power expert's features, some features of the platformused to support this expert should also be discussed.The knowledge base consists of a frames database anda rules database. Frames are organized along the linesof other frame-based systems. The system uses a classtaxonomy for inheritance and each class can haveinstances. For example, since observations are framesin the knowledge base taxonomy, they can use thehierarchy. Observations can inherit generic depen-dency information and attached text production rules

IEEE EXPERT58

from more general observation types. Frames haveattributes-attributes that can have values, defaults,and attached methods that either specify particularfacts about an instance or generic facts about allinstances of a class.

The APEX frame system has special mechanismsthat handle time series of information, manage rela-tions having inverses, and classify entities. Time seriesin particular were essential for this domain: We usethem to represent values of facts at different pointsand they provide methods to (1) default values foryears when they are unknown, or (2) calculate valuesby applying known growth rates. The knowledge basecontains many time series facts-facts that provedpractical for adequately representing time in the prob-lem area. We considered that more general representa-tions of time periods and relationships between timeperiods were insufficiently developed for this problem.The APEX heuristic-knowledge language combines

a typical if-then rule-based language and a set ofpowerful procedural constructs. It includes three typesof rule: actions, predications, and designations. Anaction determines how to execute procedures; itsresults are side effects to the database. A predicationdetermines how to test or assert statements of logicaltruth. A designation determines how to reference anentity or set of entities by description. Predicationsand designators can chain to combinations of otherpredications and designators or can be evaluatedprocedurally.PlanPower orchestrates these three rule types in a

way that allows knowledge engineers considerable con-trol over rule invocation-an extremely important fac-tor in PlanPower's development since (1) the domainis complex, (2) the expert combines a diagnostic sys-tem and a synthetic (plan-producing) system, and(3) the ultimate product-quality system must meetprofessional financial planning standards.

The frame system and rule language couple tightly.The system indexes rules closely into the frame knowl-edge base, taking advantage of the inheritance hierar-chy and allowing some rules to be more general thanothers. In effect, the platform combines rule-based,procedural, and object-oriented aspects. The resultingexpressiveness, combined with the graphic interfacethat APEX has built upon InterLisp-D, enabled a size-able group of knowledge engineers to build a verycomplex system and complete it on schedule. Thisdevelopment environment and architecture permittedAPEX to react quickly to the most significant InternalRevenue Code changes in decades.

Pln nPower-generating comprehensive per-sonal financial plans-is one of the earliestcommercially available large-scale expertsystems. Its development history, major

processing stages, and analysis/synthesis structureprovide the expert systems community with anotherexperiential data point. The difficulty and length oftime required to develop PlanPower underscore thepressing need for better methodology and develop-ment environments. Other research areas that willhelp enormously in the future include explanationgeneration, fluent and efficient natural language gen-eration, and representation of both knowledge andcontrol paradigms.On the other hand, PlanPower demonstrates that

today's techniques can produce operational systems atacceptable cost.O

Acknowledgments

We acknowledge the dedication and hard work ofthe financial planners who shared their expertise withPlanPower, the knowledge engineers who gave thatexpertise to PlanPower, the systems and researchgroups who allowed PlanPower to receive that expert-ise, and those special people who had the idea in thefirst place and who carried it to fruition.PlanPower is a registered trademark and Computed

Text is a trademark of Applied Expert Systems, Inc.

References1. F.L. Luconi, T.W. Malone, and M.S. Scott Morton, "Expert Sys-

tems: The Next Challenge for Managers," Sloan ManagementRev., Summer 1986.

2. W. van Melle, System Aids in Constructing Consultation Pro-grams, UMI Research Press, Ann Arbor, Mich., 1981.

3. D.G. Bobrow and M. Stefik, "The Loops Manual: A Data andObject Oriented Programming System for InterLisp," VLSIDesign Group Memo KB-VLSI-81-13, Xerox PARC, Palo Alto,Calif., Aug. 1982.

4. R.M. Stallman and G.J. Sussman, "Forward Reasoning andDependency-Directed Backtracking in a System for Computer-Aided Circuit Analysis," Artificial Intelligence, Vol. 9, No. 2,1977.

5. M. Stefik and D.G. Bobrow, "Object-oriented Programming:Themes and Variations," Al Magazine, Winter 1985.

6. W.R. Swartout, "Explaining and Justifying Expert ConsultingPrograms, " Proc. Seventh Int'l Joint Conf. Artificial Intelli-gence, Morgan Kaufmann, Los Altos, Calif., 1981.

FALL 1987 59

James L. Stansfield manages the Representation and Reasoningsection at Applied Expert Systems, Inc. Before joining APEX, heheld a senior staff position at Computervision Corp., working onCAD tools for electronics design. He has served as a research

Softwr EngineersNorthrop Corporation's Defense Systems DMsion in Rolling Meadwss, Illinois is the fastestgrwngenterprise in an expanding electronic countermeasures Industry. v& offer professionals with aBSCS, BSEE, BS Math or Physics (or equivalent) MS preferred, and a minimum of 3years experienreopportunities inthe folowing are nasM . S=tem Archic Thna Leaders ande ieft asi*isnmenis a able.

System ProiammersOur many variedapplications require significant grwth in our support capabilities. We need thebest people with experience in:

LANGUAGES, including Ada, Assembler, C; FORTRAN, JOVIAL, and Pascal* OPERATING SYSTEMS, including UNIX and VMSDevelopment of ReaMime Operating Systems*Development of Software ToolsPerformance Modeling and EvaluationUse of Software Structured Development Methodologies

Softvare Systems EngineersOur software engineers develop software from system requirements through implementation, andneed expernence in:

* Software Requirements Analysis * Architectural Design* Software Validation and Test Specification * Interface Design and Specification* Performance Specification and ModelingECM/EW Systems Software EngineersECM/EW Systems are our business. We neecT the best people with experience in:

* ReaMime Control Systems * Object Discrimination &* Radar Data Processing Classification* Embedded Computer Systems * ECM Algorithm Development* System and Unit Level Diagnostics * Calman Filtering* Optimal Control

Hardware Diagnostics Software EngineersWe design and deveTop advanced systems using the latest hardware and software technologiesfor our military clients. Experience required:

* Intelligent Control Panel Systems * Built-n-Test* Development * Functional Test* Micro and Macro Diagnostics for

Fault Identification

Arlificial IntelligenceArtificial intellieence technologies promise state.of-the-art solutions to complex ECM/EW challenges.Pbsitions require people who can bring Al technologies to avionic electronics, with experience in:

* LANGUAGES, including: Ada, C, LISP, and Prolog* System Prototyping * KncM'ledge Engineering* Implementation of Al Technology * Expert Systems Developmentin RealTime Embedded Systems

Interested individuals are encouraged to fovrward resume to: James Fascona, Tedmkal Remuiredfret C9, Noulrp Coiporaion, Defense Systems DMs:ion, 600Hicks Road, Rding Medos,ILEO_ We are an equal opportunity employer M/F/V/H. U.S. Citizenship may be required forcertain positions

NORTHROPDetense Systems DivisionElectronics Systems Group

associate at MIT's AI laboratory and as a lecturer at MIT's Divi-sion for Study and Research in Education. He received his BA andMA in mathematics from Cambridge University, England-and hisPhD in artificial intelligence from Edinburgh University, Scotland.

I0

Norton R. Greenfeld is vice president ofsoftware development at Applied Expert Sys-tems, Inc. Before joining APEX, he was asenior scientist in the Al department of Bolt,Beranek, and Newman, Inc., where heworked on Lisp machines and did research inexpert systems for output presentation. Hereceived his BS in mathematics, and his MSand PhD in computer science, from theCalifornia Institute of Technology.

The authors can be reach at AppliedExpert Systems, Five Cambridge Center,Cambridge, MA 02142.

IEEE EXPERT

-

60O