Planning means reasoning about what could happen.

How the approach works

1. 01

   Start from a shared baseline.

   Parts, processes, suppliers, and commitments are connected, even when their records live in different systems. A useful planning model needs those relationships, the source of each fact, and the gaps in what is known.

   We call that structured model of relevant things and relationships an ontology. It is always partial. It describes what matters for the decisions at hand, and it has to be maintained as the real situation changes — a model nobody tends to stops being useful quickly.

2. 02

   Keep hypothetical changes distinct.

   Each proposed plan starts from the same baseline. Its changes and assumptions need to remain explicit so that one possibility does not silently become a fact in another.

   We think of each plan as an alternative state of the same world rather than an edit to a shared record. Two alternatives can disagree about the same part, and both remain legible, because neither has overwritten the situation they branched from.

3. 03

   Investigate with the right tools.

   Different questions call for different forms of reasoning. Specialized agents can investigate parts of a plan, while calculations and simulations can test questions that language alone cannot settle.

   Our design goal is to preserve the evidence and assumptions behind those contributions. A simulation answers the question it was set up to answer, under the assumptions it was given; an agent knows the dependencies it was pointed at. Keeping that provenance attached is what makes a contribution possible to challenge.

4. 04

   Compare before committing.

   The aim is a set of alternatives that can be compared against shared objectives, with their consequences and open questions visible. People remain responsible for the decision.

   Options that were rejected are useful outputs too, as are the ones that stayed unresolved. Knowing which paths were considered, and what made them unattractive, is part of understanding the decision that was finally taken.

5. 05

   From a decision to the work it requires.

   Over time, we want that reasoning to help prepare the downstream work: proposed process changes, revised instructions, or supplier actions. Consequential actions need explicit authority and review.

   This is a direction we are working toward, not something the software does today. Preparing a proposed change is a different problem from carrying one out, and the second demands a far higher standard of control.