Let me begin by saying that I am in total sympathy with the basic thrust of Dave's article (chapter?).
I would like to make a couple points and see what Dave's reactions may be.
First, let us take the valve example. Dave says that this was developed for technicians in diaries and breweries. It would be nice if this knowledge object (KO) could be reused in other contexts. Thus, if I had a KO about breweries and I wanted to embed the valve KO into that structure, could I do it? If one of Frank Dwyer's students had produced a KO on the heart could I combine that KO with the valve KO and compare and contrast? How would the inference engine navigate between these various objects?
Second, I have recently been thinking about the need for a "discourse engine" to guide instructional interactions. I am thinking of something that would conform to Grice's cooperative principles. It would be nice if your transaction algorithms were implemented as modular agents and called upon by the discourse engine as the occasion arose. Thus there would be a general architecture which conformed to normal human expectations about "conversations" and then specific intelligent agents which would be called upon when a particular type of instruction was needed. Modularity would allow these agents to be built to various notions of "effectiveness" and be inserted or deleted as desired. In general, all instructional software has an implicit "theory of discourse" embedded in it, but all that I have seen are quite impoverished compared to what a human tutor can do (and I'm not talking about natural language processing).
Lastly, do you have any ideas about how to make KOs and Transaction Objects portable? Obviously your valve KO can be processed in many ways WITHIN YOUR SYSTEM, but will it work inside my system?