The ProcessLink Redux' Agent

---

redux - (pronunciation) - ducis (abl. reduci or reduce), adj. (reduco)
(1.) act., bringing back, restoring, epithet of Jupiter: Ov.
(2.) pass., brought back, returned: reduces socii, Verg.; me reducem esse voluistis, brought me back from exile, Cic.
- from Cassell's Latin-English/English-Latin dictionary.

---

Redux is a general model of design. Although a complete problem solver can be written explicitly with Redux, we hypothesize that the model is common to many design and engineering problem solvers. So we have extracted a partial implementation of this model called Redux' that captures the dependencies generated by any problem solver that can be interpreted as a Redux problem solver. This interpretation, for any given problem solver, becomes the Redux API in the ProcessLink architecture.

Ontology

In the Redux model of design, the design begins with goals that are to be satisfied (alternatively, tasks to be accomplished). In the scenario described below, the goals are to route the two cables. In order to satisfy a goal, or make progress in doing so, a design decision must be made. The results of a decision may be subgoals and/or assignments: statements about the design. In the scenario, assignments are routed paths and subgoals are the next tasks to be accomplished.

A decision consists minimally of a goal and at least one of a subgoal (a goal itself) or assignment. Other decision features such as (dependent) inputs, contingencies, and rationales are optional.

The semantics of goals are that a goal is satisfied when a decision results in only assignments, which are essentially just statements about the evolving design. A goal is also satisfied if the decision about it results in subgoals and they are all satisfied.

The complete ontology for the terms is given in The Redux' Server with the exception of assignments. The Redux' agent continues to allow assignments to be unstructured strings - essentially having only a value. Redux' has subsequently evolved to allow assignments to have variables, which in turn are composed of features and objects. E.g., a feature might be the color red of object box-1.

In making decisions, constraints may be violated by the resulting assignments. In the scenario, the collision between the two paths is represented as a constraint violation. While goals and constraints are a matter of knowledge representation, there are differences between them in the model. Goals are initially unsatisfied. A goal is satisfied when a decision reduces it soley to assignments, or when its subgoals are all satisfied. A constraint is initially unviolated: it is only violated by assignments made by decisions.

Views and Extensions

The full Redux model may be viewed in different abstraction spaces for different purposes. Goals and Decision Inputs can be abstracted into a project view in which goals are tasks and decision inputs are task input/outputs. Alternatively, decision assignments may specialized to form a part-of tree in a component view. The Constraint Manager (CM) agent introduces some special primatives that require the Redux' agent to act in special ways for some special assignments, as do the Procura (PM and AM) agents.

Scenario Messages

What are the messages exchanged betwen agents, such as the Free Space Manager (FSM), and Redux'? They are too numerous to document here, but in the scenario, one is to declare a constraint with a specification of the two conflicting paths. This might be sent by the Design Manager (DM). In turn, Jane and Joe are each notified that they are involved in the conflict. Either can ask for possible solutions. Jane declares a resolution of the constraint by rejecting her path. Jane then picks a new path. Each of these actions results in a well-defined message to Redux', resulting in the decision rationales. One of several features not mentioned in the scenario is dealing with subgoals. Suppose that Jane's rejected routing also involved a subgoal that a third engineer, James, was supposed to work on: James should be told of the change as well. This is also part of the work of the Redux' agent.

In the scenario, the restricted space caused Joe to reject an earlier path that ultimately provided a rationale for the current path. When the restrion was eliminated, Redux' notified Joe of this possibility. How this is done is more easily seen in the case when Joe reverts to the earlier path and Jane is then notified. If Joe's path P1v5 is no longer valid, than the rejection of Jane's path P2v2 is no longer necessary to resolve the collision with P1v5. Since Redux' maintains a dependency between Jane's current path, P2v4, Redux' can recognize the situation and notify Jane.

The interested reader will recognize that Dependency-Directed Backtracking (DDB) rationales are being kept by Redux'. And the semantics of these rationales is that they maintain a type of Pareto optimality.

All of the messages to and from Redux' are accomplished either with email messages from Redux' directly to the user, or with "pop-up" menus on the users' tool, such as the Cable Editor (CE) or the FSM. For example, Jane may receive a message that the earlier path, P2V2, is now (Pareto) "optimal". Jane may receive the message either in email or on the tool being used as a pop-up message. The actual text of such a message is:

The path for cable 2, P2-v2,
  which was generated by decision P2V2,
  may now be optimal.

The reason is - Decision P2V2 is preferred to 
  decisions P2V3 P2V4 because the fact 
  "shortest cable" is believed.

It had been rejected
 - to resolve a violation of constraint-2, 
   "cables overlap",
   over assignments A-9 A-3
   but assignment A-9, "path P1-v5", is no longer valid
 - because P2V3 overrode P2V2
   but P2V3 is no longer valid.

The complexity of such messages is still problematic, but the meaning is that while P2v3 was initially preferred to P2v2, the former was rejected. This leaves P2v2 as the best choice, since the collision with P1v5 is no longer applicable.

Goal Blocks

If you have read this far, your patience may extend to considering the problem of goal blocks. What if, after the collision with Joe's path, every design Jane tried was too heavy or too expensive? This should be Joe's problem too, because it is his cable that is blocking her single solution. Redux' will remember this and will also help when the problem is not so obvious, in the case of subgoaling. Suppose that Jane's goal to route Cable-2 was a subgoal of a previous decision on how to route the cable made by Jack. In this case, Jane is constrained in her choices by both Joe and Jack and both should be notified in this instance, which is created by Jane simply declaring to Redux' that her goal is blocked. She need not mention the other decisions: Redux' will identify them and notify the appropriate users.

What the user should carry away from this page is the idea that even simple scenarios with well-understood domains quickly lead to coordination complexity. "Bookkeeping" agents such as Redux' are useful for managing this complexity. Design Rationales are a useful by-product of this bookkeeping. And there are many potential applications: all modern airplanes and civil engineering projects, for example, may benefit in cost and time from the application of such distributed engineering management.

Protocol

The Redux protocol is the core of the ProcessLink Electronic Project Language.

Other Uses of Redux

Redux has been used in several projects, usually reimplemented. Some of the strongest collaboration has been with the AG Künstliche Intelligenz at the University of Kaiserslautern. See especially the CAPlan, City Planning Project (Der Intelligente Bebauungsplan), and CoMoKit projects. For follow-on work at Stanford, see Precedents and Industrial Use.

---