Preconditions or Intermediate Effects?

I think maybe I’m conflating Preconditions and Intermediate Effects.
In the attached diagram, all the Preconditions are something that I am in charge of doing, whether they are depicted in this diagram or not. For example, “The EEG results are in good shape.”
Should I be using Intermediate Effects for these instead?
Or Intermediate Effects for the two Preconditions that have arrows entering them (29 & 34), and Precondition for the one whose actions are not shown in my diagram (9)?

Hi John, and welcome to the forum!

Preconditions are things that are outside your control. They are the facts on the ground you have to work with, but you don’t make them happen. They never have predecessors. Also, preconditions may or may not end up actually being true when it comes time to execute the plan, so they can represent things that might be true at that time.

Intermediate Effects are the necessary results of Preconditions combined with the Actions you take. They always have at least one predecessor. Undesirable Effects combined with Preconditions and Actions may also feed into Intermediate Effects.

Actions are things you can choose to do that are directly under your control. Actions never have predecessors. The successors to Actions can be Intermediate Effects, Desirable Effects, Undesirable Effects, or Goals. You know you are eligible to take an action when all the other predecessors of the outcome the action produces (usually Preconditions or Intermediate Effects) are already true. Only once they are true can you take an action to make its outcome true.


Thanks! I can feel my mind expanding using your software and reading your books, along with Sheinkopf’s Thinking for a Change, and Dettmer’s The Logical Thinking Process.

Okay, this is helpful. I was taking this literally, I suppose. For instance, “I have a tea pot” is a precondition, but is also under my control (perhaps from the distant past). So I suppose there is some implied context or temporal constraints when developing these graphs.

“I have a tea pot,” would usually be a precondition, but it depends on the boundaries of the system as defined. That’s the “implied context” you’re referring to, except it shouldn’t be implied, it should be stated as part of the parameters of the proto-planning process. If something can probably be taken for granted, like still having a teapot you bought years ago, then it is a precondition.

Then there’s the “problem of air”. Do you have to specify as a precondition that the room has enough oxygen to breathe in it? Well it depends, if you’re describing a procedure on a space station then it might. If you’re describing making tea on earth, you can take it so much for granted that you don’t even bother to create a precondition entity for it. Again, it depends on the boundaries of the system you’re working with.

A good rule of thumb is to imagine explaining your plan to someone else. If they would agree that certain things are likely to exist as part of the status quo, then they’re preconditions.


Ah yes, making tea in a space ship :slight_smile:

This was very helpful, thanks again!

1 Like

As I’ve only read Dettmer’s The Logical Thinking Process (I’m only up to the Current Reality Tree) - just wondering where does the concept of Preconditions / Actions come from? I don’t think I’ve come across it yet.

@YTL When I was creating Flying Logic, I realized that entities fall into various categories. As a software engineer it struck me to think of these categories as “classes”, which is a common object-oriented software engineering term. As I reasoned about how entities should be categorized, I realized that some of them represent pre-existing conditions outside the planner/executor’s control (“preconditions”) while others represented “actions” that could be taken by the planner/executor, contingent upon whether specific prior preconditions were true and/or actions taken. So really, the idea of “entity classes” along with the specific names of the built-in classes are my own contribution to the field, for what it’s worth. :blush:


It’s a great concept and a valuable contribution!

From a new user perspective (new to the Flying Logic software, and also new to the TOC Thinking Process) - struggling to learn both at the same time is difficult, especially when trying to reconcile the differences between the different texts (for example your Thinking with Flying Logic book vis-a-vis Dettmer’s The Logical Thinking Process, etc).

I wonder if it may be worth calling out explicitly in your book (if you have already, apologies I must have missed it) the things or concepts that aren’t found in the other major texts but you’ve implemented in Flying Logic (and calling out all the good reasons that you’ve added it, like what you’ve written in your post).

That’s an excellent idea, and I have made a note to do it in the next edition of Thinking with Flying Logic. As a community, we can work together for continuous improvement!

If you haven’t already joined one of Wolf’s twice-weekly LIVE (yes, that’s him real-time) onboarding webinars, please do so - it might at least help you get over the hump with Flying Logic itself, and you can ask your own specific questions.

Here’s the scheduling link: