I-X Austin Tate, Jeff Dalton, Robert Inder, John Levine, Robert Rae, Jussi Stader Artificial Intelligence Applications Institute Division of Informatics University of Edinburgh http://www.aiai.ed.ac.uk/project/ix/

I-X Approach The I-X approach involves the use of shared models for task directed communication between human and computer agents who are jointly exploring (via some process(es)) a range of alternative options for the synthesis of an artifact such as a design or a plan (termed a product). I-X system or agent has two cycles: Handle Issues Respect Domain Constraints I-X system or agent carries out a (perhaps dynamically determined) process which leads to the production of (one or more alternative options for) a synthesised artifact. I-X system or agent views the synthesised artifact as being represented by a set of constraints on the space of all possible artifacts in the domain.

What does I-X Offer? Outer level approach of handling issues and respecting constraints in the domain model gives an intelligible approach to what an I-X system or agent does. Middle level provides a fractally composable cell which employs a model/viewer/controller systems integration approach. Detailed level provides an approach which represents and reasons with constraints on the space of all possible artifacts, and allows for the provision of specialised solvers for some or all of these detailed constraints. I-X makes contributions at level 1 and 3, and is compliant with other approaches at level 2.

What does I-X Stand For? Intelligent – I-X supports the construction of intelligent systems and intelligent agents Intelligible - I-X supports the construction of systems which are intelligible to their users and to other systems and agents. Integrated – I-X is a systems integration architecture. Issue-based – I-X is an issue-based and issue handling architecture.

Example I-X Scenarios I-Plan Planning Agent DERA Master Battle Planner Agent Emergency and Unusual Procedures Assistant Expository Scenarios Meeting Room Booking Agent Non-activity based, nodes are meetings Interior Decoration Design Agent No time points PicoIX and I-Sim For simple coding experiments and explanations Car Design Example To show both product constraint adding and activity inclusion approaches both are possible and it is a design decision which to use Example that can use probabilities within Issue Handlers and/or Constraint Managers

Shared Product Model – using Constraints on the space of products (<I-N-CA>). Shared Task Model - Mixed initiative model of “mutually constraining the space of products”. Shared Space of Options – for the Product. Shared Model of Agent Capabilities - handlers for issues, functional capabilities and constraint managers. Shared Understanding of Authority - management of the authority to handle issues and act which may take into account options Shared models are the basis for communication between I-X systems or agents and people. They can be partially shared in some cases and need not be globally agreed. Some example systems developed during the course of the O-Plan project, which partially demonstrate some of the I-X features, are shown. (Partially) Shared Models

Uses of a Shared Model Knowledge Acquisition User Communication Intelligible Representation Formal Analysis System Manipulation The shared models can be used for a range of purposes.

Space of Legitimate Product Models <I-N-CA> Product Model Issues Issues or Implied Constraints Node Detailed I N CA Nodes Constraints I - Issues - Plan Agenda - implied constraints on the plan   N - Nodes - Plan Entities - Anchoring activities in a plan CA - Critical/Auxiliary Constraints - Detailed Plan Constraints (Critical constraints will be defined later) A model of a product being created, modified or used within an I-X system or agent is specified by giving a set of constraints on the whole space of legitimate products in the area of application. Nodes are the principal entity in the product. The decision to include a node is a very important step in a system whose aim is to synthesise such a product description or model. Examples of using I-X and <I-N-CA> A very simple car consists of a chassis, 4 wheels attached to the chassis and an engine attached to the chassis. There are only 6 named parts named in the entire domain. There are two ways to approach this problem. We can make a system that seeks to specify "attached-to" relationships between the parts and we evaluate the overall product on whether it meets our requirements for what a car looks like. Or we can make a system that specifies the process that will be used to build a car in terms of "attach" activities. a) Issue: design car (to an agreed specification) Nodes: the parts of the car Node-relatable Objects: none Constraints: attached-to(chassis ?x) Domain model: for all ?x not(attached-to(?x ?x) b) Issue: create-plan-to-make car (to an agreed specification) Nodes: attach(?x ?y) activity Node-Relatable Objects: Parts of the car. Constraints: attached-to(chassis ?z) Domain model: for all ?x not(attached-to(?x ?x) If we had a military planning domain in which the objective was to "achieve air superiority", then the following mapping to I-X/<I-N-CA> is possible: Issue: achieve air-superiority (for some evaluation metrics) Nodes: <military activities> (such as flying missions, etc) Constraints: time, resource and other constraints Domain model: capacity availability, limitations of use of resources in time, etc. Space of Legitimate Product Models C=Critical Constraints A=Auxiliary Constraints

I-X and <I-N-CA> Product Model Issues Choose (IH) IH=Issue Handler (Agent Functional Capability) Do (IH) Nodes Propagate Constraints Constraints The I-X processing cycle begins with the selection of one or more of the outstanding issues in a product model. A handler is selected to address the issue(s). The handler is then called. This can lead to alterations to: the nodes included in the product model (a key decision for synthesis systems); the introduction of constraints on the way in which the nodes are related between themselves and to other entities in the application domain which are termed Node-Relatable Objects the introduction of further issues or sub-issues to handle. A constraint propagation loop is then activated which looks at the feasibility of introducing the constraints added by the issue handling loop. This can lead to further constraints being introduced to resolve constraint interactions, and can lead to even further issues which are passed back to the Issue Handler – possibly just to be posted into the Product Model for later handling.

Generic and Activity Ontologies Generic Ontology Entities Relationships Issues Constraints Nodes Node-Relatable Objects Activity Specialisation Entities Relationships Issues Constraints Activities Time-points Activity-Relatable Objects

<I-N-CA> Generic Ontology Entities Relationships Issues Constraints Node Constraints Critical Constraints Auxiliary Constraints Nodes Node-Relatable Objects (NROs)

<I-N-OVA> Activity Ontology Entities Relationships Issues Constraints Node Constraints Include Node Constraints Other Node Constraints Critical Constraints Critical Ordering Constraints Critical Variable/Object Constraints Auxiliary Constraints Auxiliary Ordering Constraints Auxiliary Variable/Object Constraints World-State Constraints Resource Constraints Other Constraints Activities Time-points Activity-Relatable Objects (AROs) I - Issues - Plan Agenda - implied constraints on the plan N - Nodes - Plan Entities - Anchoring activities in a plan OVA - Orderings/Variables/Auxiliary - Detailed Plan Constraints The activity specialisation of <I-N-CA> is just one (useful one) amongst many possible specialisations. We could have an <I-N-SPOGA> if the critical constraints used in an application were of type S…, P…, O…. and G…. Whatever they stood for. Another useful <I-N-CA> specialisation we have used is for configuring computer systems, where the critical constraints are the connections (“C”) between boards and the backplane of a computer or piece of automated test equipment. The boards are the nodes.

I-X Components I/O Handlers Controller Issue Handlers Model Manager Inter-agent messages Information from the environment User Input Inter-agent messages Information to the environment User Output I/O Handlers Events -> Issues Other Information Model Manager Controller Issue Handlers Domain Model Constraint Managers This slide shows a component diagram for parts of an I-X Agent or System. This implements the more abstract “2 cycles” view presented in an earlier slide. n I-X system that communicates via an Agent Communication Language is termed an I-X Agent. A system that does not use an ACL at all is termed an I-X System.   The first type of component in an I-X system is an I/O Handler. There can be one or more of these. One kind of input may be “Events” which arrive on the input channels to the I-X System or Agent. Some of these are mapped to issues for the agent to address or handle. Issues may be related to the system’s or agent’s task, or they relate to one or more of the options for the products being created, modified or used within the I-X system or agent. Other kinds of inputs may be treated as environmental information and may update internal models directly without becoming issues. The second component of the I-X system or agent is the Controller. There is one I-X Controller in every I-X agent or system. It performs the role of taking the issues accepted through the I/O Handlers and coordinating the handling of these issues. For those systems where the aim of the system is to investigate alternative options it coordinates which option is being worked on and what the status of that options development is. It acts as the “Task and Option Manager” for the system or agent. It has a range of Issue Handlers plugged into it that provide the actual performative capabilities for the I-X agent or system. The controller operates continuously wand handles whatever issues are added to its issue list (sometimes called the “Agenda”). It can handle agent or system issues or issues with respect to one or more products and can interleave such operations or handle these in parallel if the system design and implementation supports this. The third component of the I-X system or agent is the Model manager. There is one I-X Model Manager in every I-X agent or system. It performs the role of knowing (whether implicitly or explicitly) the domain or application environment or “domain model”. It also stores the product model (or models if there is more than one option) being synthesised, modified or used by the I-X agent or system – again it can do this in a clearly defined format or it could implicitly present such a view to the other I-X components. The Model Manager may utilise Constraint Managers to perform its role. < I - N - CA > Product Model(s)

Constraint Associator I-X Components – Level 2 Inter-agent messages Information from the environment User Input Inter-agent messages Information to the environment User Output I/O Handlers Events -> Issues Other Information Viewers Model Manager Controller Issue Handlers Constraint Associator Domain Model Constraint Managers Viewers may be part of the I/O handlers to support user views of the I-X agent’s and system’s process or product options.   The preferred I-X mechanism for introducing Constraint Managers is to have a “Constraint Associator” which is told which constraints should be passed to which constraint managers, and manages the cross-communication between constraint managers of mutually constraining elements (these constraints communicated between more than one constraint manager are called critical constraints and will arise in the “maybe” answer from constraint managers to be described later). < I - N - CA > Product Model(s)

I-X Cell – Model/Viewer/Controller I/O Handlers Constraint Managers Issue Handlers Viewers Domain Model Controller Model Manager

I-X Cell – Plug-in Components I/O Handlers Domain Information Issue Handlers Viewers Constraint Managers Controller Model Manager

I-X Constraint Managers Issue Handlers Optional Try add C and/or A constraint(s) -> yes/no/maybe Commit add C and/or A constraint(s) -> yes/no/maybe (I.H. must commit to at least one case of the maybe) Model Manager Constraint Associator Yes No Maybe* in terms of alternative sets of Issues and C Constraints to add Domain Model Constraint Managers Issue Handlers can do a trial attempt to add constraints and see what the consequences are, or they can commit to adding constraints and undertake to handle the consequences. Constraint Managers give yes. No and maybe answers when asked to add a constraint to those they already have in their model. The maybe answer provides important information about the mutual “Critical” constraints that need to be added to keep the constraint set managed by any specific constraint manager consistent. Model(s) < I - N - CA > * Maybe = Provided That

I-X Options and Alternatives Inter-agent Tasking Options I/O Handlers Intra-agent Model Alternatives Inter-agent Tasking Options and/or intra-agent alternatives Intra-agent Model Alternatives “Current Model ” related to an Option Mapping table for Option name to option object and therefore to to current and other intra-agent Alternatives related to the option(s) Controller Issue Handlers Model Manager Constraint Associator Yes No Maybe Intra-agent Model Alternatives for current alternative model only Domain Model applies to all Options and Alternatives Options referable to externally to the agent boundary may also include sub-options that are intended to be closely related variants of the main options. Domain Model Constraint Managers Model with Intra-agent Alternatives < I - N - CA > Each option has one “Current Model” associated with it

I-X Controller Controller Issue Handlers Model Manager Issue is handled by IH… IH can terminate having indicated: Okay and (if changed) current model to be associated with option Okay with current and N-1 other inter-agent options and/or intra-agent alternatives Failed Model Manager

Dealing with Probabilistic Uncertainty I-X may be applied to build a system in which the world is probabilistically modelled. This is allowed for at the heart of the design by letting constraint managers return issues as well as yes/no/maybe answers. A Constraint Manager (or Issue Handler) can give a yes/no answer in definite cases, or may be the maybe answer to return an issue that the answers given are only probabilistically true to some level. Higher level Issue Handlers or the agent tasking environment can then respond as appropriate to that issue which will be attached to the model.

Other I/O to and from the Environment Example I/O Scenarios Information from/to the environment User Input/Output Inter-agent messages Viewers Agent ACL Message I/O Other I/O to and from the Environment I/O Handlers

Example I/O Scenarios Inter-agent messages Robot effectors and sensors Thermometer with preset min and max alarms Continuous readout thermometer Database access Monitor output for continuous status updates and warning lights for specific events User viewing agent process and model(s) User controlling agent process and model development

Probing Questions for an I-X Design What issues does the agent handle (Verb, NPs, Qualifiers)? What are the principal entities in the model which the agent handles? What constraints in the domain should the agent respect? What types of options the agent can handle? What sources of input and output can the agent handle? How are events communicated to the agent? How can a user interact with the agent? What views can the agent present? I.e., what functions – on what entities – under what constraints – with which options - communicated how?

Probing Questions for an I-X Design Level 2 Can each Issue Handler return just one answer, or more than one? Can it fail (return no answers)? Can the various constraints identified by handled by one solver or are several specialised solvers preferable? What answers can each constraint manager provide? Yes/No Yes/No and Maybe Notes: Maybe states the constraint is valid with respect to the current state of the model – provided that the system handles or satisfies at least one of the alternative sets of issues and constraints returned. Any constraint returned in a maybe answer from a constraint manager is defined as a critical constraint. Any other constraint is termed an auxiliary constraint.

I-Technology I -PE Process Editor I -P Process Panel Cooperation and 2 Process Panel Cooperation and Communication I-Plan Planning Aid I -PL Process Librarian Other Agents AIAI’s work to use the I-X design and <I-N-CA> ontology will lead to the development of a number of systems. These include a process editor (I-PE), a very simple process library (I-PL), a range of simple to sophisticated process panels (I-P2), a planning aid used for workflow support amongst other things (I-Plan) and a range of other specialised agents and systems. Some infrastructure modules to provide user viewers (I-View) and even lower level components for I-X Interfaces (I-Faces) to the user (User I-Face) and persistent repositories (Repository I-Face) are also part of the project. I-View I-Face - User I-Face - Repository I-Face

I-X Continuing Discussion Topics Constraint Associator/Manager/Checker interfaces Viewers for agent process, options,and model (<I-N-CA>) I/O interfaces for all types of I/O scenarios Is environment/state model a separate thing to <I-N-CA> model or just a part of the CA elements for all possible models? What about information sources used by components of the agent? How fundamental is the nature of the “Include Node” constraint? (e.g., in the interior decoration design scenario). Concept of Options needs refining.

Further Information http://www.aiai.ed.ac.uk/project/ix/