1. I-X Austin Tate, Jeff Dalton, Robert Inder, John Levine,
Robert Rae, Jussi Stader
Artificial Intelligence Applications Institute
Division of Informatics
University of Edinburgh

2. 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.

3. 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.

4. 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.

5. 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

6. 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

7. 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.

8. 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

9. 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.

10. 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

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

12. <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.

13. 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)

14. 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)

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

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

17. 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

18. 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

19. 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

20. 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.

21. 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

22. 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

23. 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?

24. 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.

25. I-Technology I -PE Process Editor I -P Process Panel Cooperation and2
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

26. 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.

27. Further Information