Instrumentation can be made self-indexing if one simple rule is
(I probably should just stop there, but I've never been good at not explaining everything.)
This rule will ensure that every index that doesn't start with #00 (for Specialization) and that ends in #00 (for Creation) is automatically part of the index. This means that the #[01-FF][00-FF][00-FF]00 collection of cells will contain a self-documenting "Table of Contents" for the Specialization layer by default. We shall refer to the table as the Menu in this design for the sake of brevity. The Menu will consume 1/256th of the address space (16.7 million terms, but less than .4%). These terms will be distributed evenly across the entire address space so it won't create any noticeable gaps.
FYI: Indexes that start with #00 are part of the "Casual Conversation" area. The Casual Conversation area has its own rules and search strategies that simplify the use of everyday language. This is part of the plan to make the Casual Conversation area 'feel' separate from Specialization even though its really just another area. This 'mental separation' should keep people from confusing 'common' terms and Special terms even when they actually share six out of eight syllables. (Each common term shares its 'last' six syllables with 255 Special terms.)
This is the glyph for the topmost Menu of the index. Since one need not type any layer which is all zero's or does not change from the previous layer's values, This glyph is entered by clenching all eight fingers and both thumbs then releasing the (clenched) fingers and entering a final right thumb press. The "final right thumb press" signifies that this is a complete glyph (like hitting ENTER on a calculator).
More FYI: This is the second simplest fingering combination on the Specialization layer (after #00), so it is reasonable that it should be the entry to the Menu. Also, higher numbers have more elements within a layer so it is philosophically reasonable that they would would be more likely to represent the collection of knowledge whereas the fewer elements would indicate the selection of knowledge.
This concludes the arm-waving tap-dancing portion of the design
Does it look like a big spotty eyeball to you?
Maintaining this Table of Contents will require no additional (physical) effort beyond maintaining the #00 cells in the Blocks themselves (although, see the last paragraph in this section). Each 'Area' (the highest level) will contain 255 Division descriptions, each Division will contain 255 Block Descriptions and each Block will contain 255 terms. The only other usability requirement is that the lower value Divisions should contain the most iconic Blocks within their Specialty.
Conceptually it might be best to think of each Specialized Area
as 256 Divisions with sixty-four thousand terms each. This could
make the initial division of "Focal Vocabularies" more manageable
while leaving ample room for expansion as people become aware of
the potential utility of "active terms" and thereby develop more
Not all 256 Divisions need be assigned initially. The parts of the Divisional address space that have four (Articulation) spokes are the most thematically complex and (likely) least memorable. If a Layer has five or six elements it can be more easily classified by what it lacks.
The "Casual Conversation" area is an example of alternate organization within its 16.7 million terms. It is structured to reduce the number of things that the average use has to remember while allowing efficient combinations of things, actions, relationships and various modifications thereof. It does this by treating the articulation layer as a completely separate vocabulary. Other Areas could be also be created with alternate structures, but the Index would be require to compensate for them somehow.
We can think of a Specialized Index as containing three variable
numbers (the three outer layers) with a fourth constant number
(the inner spokes at zero).
Currently, changing the value of one of the three variable layers would move the user to a new part of the index, but it would not change any of the other layers.
An alternate strategy would be to set the 'lower' layers to zero when a 'higher' layer changes. With this method, changing the Articulation layer to any other number would set both the Description and Creation layers to zero. In effect, this would move the user back to the Description Index to facilitate their search. If the user changed the Specialization layer they would be returned to the Articulation Index and any layer change other than the Creation layer would set the Creation layer to zero. This 'alternate strategy' would probably be a selectable option within the Basic Command Mode block.
I can also envision an "Indexing Search Mode" where:
FYI: The "Articulation Index" does not have a defined default structure yet because it may vary wildly depending on the Specialization Area being indexed. I assume that a pattern similar to the Description Index will actually be used in most cases.
In general, I think that the extension rules for indexing should run as follows:
If the Description or Articulation layer has zero for an index, the resulting Creation block should contain links to the most important or most general blocks in the address space available within the zeroed layer. If both the Description and Articulation layers have zero for indexes, the resulting Creation block should contain links to the important Divisions in this Area (because this whole Division will contain all menu Blocks anyway).
The use of links is very efficient because a link only contains a
pointer to the actual term. A link does not contain all of the
information contained in the Instrumentation
data store. This avoids redundancy while making the term
available to other blocks. I assume that specialized terms like
"polynomial" or "Maslow's hierarchy of needs" might be useful to
If you wish to look something up using the Menu, you can
start at the top and work your way down.
There will be 256 Specialized Areas, and it should be possible to drill down through each layer of the glyph by choosing one out of 256 choices. The terminology for the full hierarchy of Menus is:
In practice it might make more sense to break each Menu
of 256 items into one sixteen item "Top Menu" and sixteen
"Bottom Menus" with sixteen items each (like the current "Drill Down" function.
The actual physical implementation will depend on the available
facilities (and screen space), but the 'trick' is to make each Menu
item representative of the tables below it.
The key point here is efficiency. The physical device can quickly
download 256 terms. This should be done for index Blocks
(which display all the indexes in a Division) and for all
the terms within a Specialized Block when you "lock a
The size of the term download would be:
If the Menu downloads are smaller than term downloads
this directory system will run more efficiently.
The difficult part is getting the most important (or iconic) Blocks
migrated to the #[0-F]0 items in the Articulation and Description
Menus. The 'standard' block
design uses this method because the #[0-F]0 key combinations
only use one hand and the pronunciations of those terms are only
one syllable long. Instrumentation tries to match the most
efficient locations within the address space with the most useful
or iconic terms.
FYI: The #FF term in each Block should be a link to the 'preferred' user interface for that Block, but that only matters when typing the Creation chord of the glyph. For example, the #FF term in a block used by writers would probably link to a glyph processor; the #FF term in a block used by programmers would probably link to an IDE; and the #FF term in a block used by engineers would probably link to a calculator of some type (any engineering block would probably have links to many calculator blocks, but #FF would be the default one).
The #FF term in a preferred user interface Block would
probably be the '=' or 'results' or <ENTER>, but now I'm
just making stuff up.
This is actually a pretty cut and dried subject, so I tried to show how it can be a solution within several problem spaces. I think that this is an important point because the Menu essentially makes Instrumentation internally self referential, which is the ultimate goal of any philosophical system or programming language.
Several things in this Menu design are speculative. Menus
will exist because they are too practical to be abandoned,
but testing is needed to finalize the arrangement and expected
function of the items within the Menus (especially the
Articulation and Description layers).