In many cases of deduction, the premeses have prior, independent acceptance of validity. System Engineering (SE) practices accept unvalidated1 assertions as premeses, provided that they are subsequently subjected to formal validation as part of the development process. In the context of requirement derivation, dealing with validation of the premeses is an important part of traceability to support bias mitigation.
By way of example, the classic deduction is as follows:
All men are mortal
Socrates is a man
Socrates is mortal.
A “prospective” version would be:
All men are mortal
If Socrates turns out to be a man
Socrates is mortal.
Prospective deduction can entail significant project risk2: such processes are deductive IFF explicit validation tasks are identified and committed in concert with the (prospective) derivation; otherwise, it involves no “logic” at all, and often leads to Verification by Wishful Thinking. The concept is, however, almost unavoidable when coordinating sets of requirements for multiple subordinate CI‘s: it is quite common for the validity of one CI’s requirements to be contingent on the satisfaction of requirements allocated to another one3.
The concept of prospective deduction should not be interpreted as a formal pattern of cognition. It’s really just a framework for restating a reasoning that isn’t deductive as a set of validation objectives that will 4become one.
Footnotes