More  Detailed Orders of Ignorance (0OI)
Finer 5OI

In formulating the Five Orders of Ignorance, and reconciling the need for process, a need arose for subdivisions of the 5OI.  These are perhaps not as semantically precise as the original 5OI, but they do expose some other aspects of the pursuit of knowledge.

Zero Order Ignorance (0OI)

0OI is extant knowledge.  From its definition, we have 0OI when we know something and can provably demonstrate that we know this something.  In the book The Laws of Software Process I divided each of the lower four Orders of Ignorance into thirds (eg. "pure" 0OI, 0.1/3OI, and 0.2/3OI).  This notation is a bit cumbersome.  While there is a build relationship--in order to have "pure" 0OI, one must resolve the other two flavors of Zero Order Ignorance--but here I will use a "subset" notation, viz: 0OIa, 0OIb, and 0OIc which I hope will be a little more obvious than the original.

Zero Order Ignorance Prime (0OIa): I have 0OIa when I know something,...
...AND I also know how to prove I know something,...
...AND I know how to set up and execute a demonstration of that proof

A piano example: I have 0OIa about Beethoven's Moonlight Sonata on piano if:
(1) I know the piece...
(2) I know how to play the piano and...
(3) I know how to set up the environment to prove I have knowledge of Beethoven's Moonlight Sonata.

Using a negative-proof approach, we can see that each of these steps involve related but different knowledge and application:

• I might I know the piece theoretically [1] ,...

• ...but if I don't have the second step (2) I cannot demonstrate and thereby prove it.  The knowledge that separates these two parts is the knowledge of how to actually play the piano at all.

• ...but I might know the piece and know how to play it, but if I cannot arrange for a piano, at some time and location, and with an audience to whom I can prove I know the piece, I cannot render the provable element of 0OI [2] 

Zero Order Ignorance Secondary (0OIb): I have 0OIb when I know something, I know how to prove I know something, but I don't know how to exhibit that proof

Here, I might know the score, I can play it, but I am unable to prove such because of my ignorance of how to prove it.  So I can play for myself perfectly (as far as I am aware), but I can't play in front of someone who can certify I know the something [3] 

Zero Order Ignorance Tertiary (0OIc): I have 0OIc when I know something, but I don't know how to prove I know something (and, of course, I don't know how to set up and execute a demonstration of that proof)

And here, I believe I have knowledge of the score, but I can't actually play it on a piano.  And therefore any knowledge of how to set up a demonstration of proof is moot.  

0OI in Software Development

The source of these ideas originated in software development.  The difference between 0OIa, 0OIb, and 0OIc is perhaps somewhat clearer to practitioners in this environment. 

0OIa is fully factored knowledge.  The requisite knowledge is present in the program PLUS the knowledge of how to make the program actually execute is present PLUS the knowledge necessary to adjudicate the program knowledge is both present and executable.  In the software sphere these are: the program under test, the MAKE process [4]  needed to set the program up to execute, and the loaded and executable test system against which the program will run [5] .

0OIb is partially factored and static knowledge.  The requisite knowledge is, presumably, present in the source code, however, the programmer or tester has not yet acquired the knowledge of how to render the source code into an executable.  This requires further knowledge of the MAKE process (compiling, library linking, etc.)

0OIc is unprovable knowledge.  The required knowledge might be present in the program.  But the inability to get the program to actually run and the further inability to check the operation of the program in proving (or disproving) that the knowledge contained in the program is "correct" means that the knowledge is unvalidated.

Note that the necessary knowledge to get to 0OIa is distributed between the target program (which is the point of the system development), the MAKE process (which is only loosely coupled to the knowledge in the program and might be very similar across a range of different programs), and the test system (which is usually closely coupled to the knowledge in the target program).  

The knowledge in the program relates to the functional application for which the program was written.  The knowledge in the MAKE process relates largely to the environment in which the program will run.  The knowledge in the test system is a hybrid of these two knowledge types with an emphasis on the functional program knowledge.

Moving to 1OI

We can see that in 0OIb and 0OIc, we actually have significant 1OI present, albeit in a different form than having lack of knowledge of the functional requirements.  Presumably, we would know if we did not know how to make a program execute or how to build and run a test system.  So 0OIb and 0OIc are bridges to on the path to First Order Ignorance.  Which we will deal with next. 

FOOTNOTES 

[1]   It is quite common for members of the audience at a classical music concert to bring the orchestral score and "read along" with the playing.  However capable they might be at reading the score, and they might know exaactly how it should sound, what stress should be put on what parts of the score, when it should speed up and slow down, but they are likely quite unable to actually play it.
[2]  This is the knowledge of how to actually set up a demonstration.  Of course, it may be that I  do not need have all this knowledge if the concert is being set up by someone else such as a music professor assessing my proficiency or a promoter setting up a concert.  However, I would have to have the knowledge of who this person is and what they know (and can demonstrate).  In this case part (3) would simply be the contact information of this person.

[3]  ...and because of the Dunning/Kruger syndrome, I might be wholly self-deceived.  

[4]  A MAKE process is usually another computer program that collects all the necessary libraries and routines needed to make the target program actually run within a computer and renders the source code of the target program into an executable.   ...and because of the Dunning/Kruger syndrome, I might be wholly self-deceived.  

[5]  There are several layers to this test system.  Once the target program has been rendered as an executable, a test system will typically: 1. Set the program state and load the program inputs, 2. Initiate an executable cycle of the program, 3. Monitor the program's progress in executing, 4. Produce the required output from the program, 5. Evaluate the quality of the output against some proof criteria, and 6. Produce some analysis of the results.  Note, not all of these steps are present in all test systems, but there must be enough to qualify the target program as functional or non-functional.