Instrumentation Development Environment


This is all way out on a limb, but I had a few thoughts and I wanted to write them down before I forget.

Parts of this design are 'simplified' in an effort to make the plan understandable to everyone. If you are a programmer, you may find that some of my definitions seem a bit incomplete, fuzzy or blurred. For example, the dividing line between Storage and Memory is more philosophically than physically (hardware) defined.

On the other hand, it might just be that this design is incomplete, fuzzy and blurred, like wayward thoughts hanging from a gnarled limb and twisting in the wind ...


An "Integrated Development Environment" or IDE contains everything needed by designers and programmers to create an application. This design is an attempt to organize the functions of a programming language and the operating system that supports it into a single vocabulary so that user macros, shell commands (or Job Control Language) and program code could be written using the same commands. I'm basically attempting to follow the BeOS® model where the user interface is just an extension of the application programming and system programming interfaces.

This design should have all of the same facilities available in any fully developed IDE, but those facilities will be organized according to the Instrumentation philosophy. The order of the types below is not the order that I originally chose. I would have made Programming the dominant (Supremacy) type, but that didn't fit the apparent internal/external nature of this Instrumental design.

This design can be considered a part of the Circular Desk. This design should contain the low level facilities needed to implement the functions in the "Application" column of the "Tech Support" table. We are also documenting the further evolution of the Problem Solving, Program Design, Glyphic Editor, User Interface, Programming Design Patterns, Information Theory and Units of Control technical expansion series.

You may notice an absence of programming terms like 'and', 'or', 'xor', 'if', 'else', etc. This is because these 'programming primitives' already exist within the Syntax Block. Links will exist between different parts of the Specialization index, but it would be wasteful to use a four-chord Specialization term to represent a one-chord Articulation term.

Beyond Demographics and Privacy

If Instrumentation becomes the "One True Universal Interface" (do you hear voices singing?) there will be an enormous opportunity to collect demographic data from a global source. This can be a source of valuable information about local and global preferences that can help Instrumentation and all of the services that use it to improve their "User Interfaces". 

The flip side is that personal information should never be taken from an individual without their consent. In case you are worried, the current free application does not collect or report any information at all.

Instrumentation usage and preference information should be 'bought' openly from the users. The payment need not be money, it could be technical support or some other client/provider relationship enhancement. The user should know exactly what information is being collected and be able to disapprove the addition of new parameters to the monthly(?) secure update (or quit altogether). 

The compiled statistics should be available to psychologists, sociologists, linguists, gossips and the general public. The data should be partitioned by language, country and geographic region for comparative studies.

This process must be completely open and established with the user at the beginning of the opt-in relationship (however that relationship develops). The whole relationship should be as transparent as the Debian popularity-contest.

Realistically the user 'term usage' statistics would look something like this:

Usage count

We really don't care what you are saying, we mostly just want to know which words aren't being used so that we can optimize the basic vocabulary. If you don't upload your usage statistics, your favorite words may get shipped up-level to the vast Specialization wilderness.

Preference data would look something like this:

Allow statistics uploads
Of Course!

If the preferences are backed-up online, the user should also be able to download and reinstall them if they get stomped.

The user should be able to view their most recent data update and their total usage statistics to date. This data should be maintained by user GPC within the user's hardware, but aggregated to maintain user anonymity before it is shared with others. Security would be handled with double key encryption. Trust must be established and maintained for this system to work.

If updates to the user interface are driven by user interaction statistics, the whole system can evolve more quickly and surely. "Beyond Demographics and Privacy" lies mutual advantage, one would hope.

Other Considerations

These are features that I have mentioned in other designs. I'm collecting and organizing them here to make sure that all my designs appear to have a vague semblance of cohesion. The taxonomic hierarchy below is only one possible view of a vast, complex and extensively interrelated structure. We start with the Client because that is where the money is.

This design uses the following eight Types:

External Interfaces:

User Interface

This is where commands originate and results go to die.

The User Interface includes video, audio, keyboard, mouse, joystick, game controller etc. These are the facilities that translate formats and handle the user interface. This is in the Supremacy slot because the user should be the alpha and omega of system design and operation.

Communication In/Out-put

This is your portal to the outside world.

Everything coming in and going out should be checked for problems by the system "border guards". All input should go to a quarantined Storage area until it has been completely pacified and 're-educated'. Any downloaded executable entity should be initially run by a restricted shell in a protected "sandbox" until it's behavior has been adjudicated as safe.


Begging for access and promising to be good.

The System stops you from doing things that are hazardous to the system (hopefully). This is where you obtain resources (CPU load sharing, memory, threads, environmental variables, etc.) needed to accomplish your task.

Storage (persistent)

Storage contains files, data bases, serialized objects, etc. These contain the results of your past work and the data needed for your future work.

This is the Peril slot because of the potential for data corruption, data theft, and data loss. Storage should be well protected and have multiple redundant backups.

Internal Facilities:


Making the system deliver what the user wants.

This covers the Programming commands for things like sequence, selection, iteration, alternation and parallel. This is the part of a program that tells the system which part of that program will run next.

Programming also covers the use of source, executables and modular libraries for actually running a system.

Memory (ephemeral)

Organizing information that only exists for the life of a program.

This covers program 'variables' like integers, strings, arrays, linked lists, trees, maps, vectors and other temporary data structures including the non-static parts of objects. This data may be read from and written to Storage, but it requires dynamic resources (such as RAM) while a program is running.

This is the passive part of the meta-data storage and code classification (design patterns) functions. (see Glyphics)


Manipulating Glyphs as active variables and functions rather than passive numbers or terms or graphics. The entire system is designed to operate on Glyphs by means of Glyphs, so Glyphs will also be used as passive data, but this type is focused on 'flexibility' rather than 'value'.

I have to admit, this is somewhat of a blank space at the moment because the framework is still so new, but I'm assuming that his will be the Artificial Intelligence (AI*) part of the IDE. Since each Glyph has a documented function, the system can guide the user through program creation.

This is the active part of the meta-data maintenance and code reuse functions.

Math & Logic

These are the most basic bit manipulation facilities.

This is the reason computers were created in the first place. Gaming, email and word-processing weren't even considered and the internet didn't exist. Nowadays, this is the invisible (to the end user) under-carriage upon which everything else rides.

This block would require the Business, Science, Sport, Leisure, Education and Art laths. That would put it somewhere in the #DD Specialization area.

The terms are organized into four tables, each containing four sub-tables (or banks) which consist of sixteen cells. Each cell contains a term,  command, a keyword or a link depending on usage.  The headings before the four tables below and the (unique) element combinations that define each sub-table's purpose show the External Interfaces divisions. The four dark rows within each table separate the the sub-categories or banks and contain the (repeating) four Internal Facilities element combinations that define the meaning of each individual cell.

This design only shows positive terms. Negative terms would be the opposite of each 'passive' term listed below. If the term is 'active', the negative form will invoke the function or be used to capture the state or current Value.

Cell #00 contains the name of this block of terms, it is used to create the Specialization "Table of Contents". If you select cell #00, you will lock-in this block of terms and you will need to unplug Command Mode to exit, even if these terms aren't commands. I can't think of a reason to select cell #00 that doesn't involve using the Table of Contents to lock-in this block of terms, so I don't see this as a problem.

The "Basic" sub-table is the default because that is where the most common terms should reside. These are the "Left Hand Only" indices (#0[0-F]). The "Right Hand Only" indices are the first (#[0-F]0) terms in each sub-table. Notice also that '5' and 'D' are the most awkward finger combinations so they are used for less critical events (ideally).

These tables are incomplete because I am still looking for the 'best' terms and organization (and this is all just a mock-up anyway).

Basic Facilities

The first table does not have either the Communication In/Out-put or User Interface Types. This table contains terms related to basic programming idioms and facilities.


(no elements)

Math & Logic
Glyphics Both

#00 - Instrumentation Development Environment #01 - Operators #02 - Helpers #03 - Units of Control
#04 - Public relations guidelines #05 - binary logic
#06 - ternary logic #07 - Clock and Calendar
#08 - Imperative #09 - Object Oriented
#0A - Functional #0B - Visual
Both #0C - Procedural #0D - Recursive #0E - Adaptive #0F - Performance considerations



Math & Logic Glyphics Both

#10 - Storage Index #11 - dynamic access (DMA)
#12 - garbage collection
#13 - formats and protocols
Memory #14 - tape backup
#15 - channels
#16 - de-fragmentation
#17 - cloud (distributed storage)
Programming #18 - disk storage
#19 - RAID #1A - journaling
#1B - Caching
Both #1C - memory sticks
#1D - stack #1E - heap #1F - off-site versioning



Math & Logic Glyphics Both

#20 - System Index #21 - ALU
#22 - dashboard #23 - Problem Solving
Memory #24 - storage access
#25 - Vector graphics
#26 - service framework #27 - 
Programming #28 - processor access
#29 - sensors #2A - device functionality #2B - Remote device access
Both #2C - user privilege
#2D - resource limits
#2E -  #2F - resource priority



Math & Logic Glyphics Both

#30 - Object Index #31 - method inventory #32 - method compatibility #33 - method taxonomy
Memory #34 - Event objects #35 - API objects #36 - User Interface objects #37 - Application objects
Programming #38 - Community #39 - Design #3A - Develop #3B - Distribute
Both #3C - Inheritance #3D - Constructor Functions #3E - Entities #3F - application development

Communication, Privacy and Security

The second table has the Communication In/Out-put Type. This table contains terms related to Communication, Privacy and Security.


(no elements)

Math & Logic
Glyphics Both

#40 - Address book
#41 - kill-file #42 - messaging #43 - quoting
#44 - internal 'favorites'
#45 - publish #46 - encrypt #47 - recall message
#48 - external 'favorites'
#49 - subscribe #4A - decrypt #4B - create message
Both #4C - Password management
#4D - Bayesian filter
#4E - connection optimization
#4F - real time conversation



Math & Logic Glyphics Both

#50 - Bookmark Index
#51 - Favorites #52 - Bookmark  Sanitation #53 - Bookmark Usage Statistics
Memory #54 - Bookmark Management
#55 - PHP Management #56 - Bookmark Annotation
#57 - Bookmark Removal
Programming #58 - Bookmark Creation
#59 - Bookmark Search
#5A - Bookmark (Automated) Verification
#5B - 
Both #5C - Bookmark Graveyard
#5D - Label Statement #5E -
#5F - Bookmark Suggestion



Math & Logic Glyphics Both

#60 - Encryption ON/OFF
#61 - data formatting
#62 - "Friend Of A Friend" #63 - GPC*
Memory #64 - trust protocols
#65 - Digital object identifier #66 - trust network
#67 - public key
Programming #68 - bearer #69 - steganography #6A - Whirlpool #6B - private key (encrypted)
Both #6C - Triple DES
#6D - Data Type Conversions #6E - code obfuscation
#6F - key management



Math & Logic Glyphics Both

#70 - Quarantine Index #71 - virus detection #72 - data visualization
#73 - source reputation tracking
Memory #74 - data classification #75 - sandbox allocation
#76 - local scope checking #77 - global scope checking
Programming #78 - data sanitation
#79 - program execution
#7A - masquerade detection #7B - 
Both #7C - metadata collection #7D - active intrusion measures
#7E -  #7F - 

User Interface

The third table has the User Interface Type. This table contains terms related to the User Interface.


(no elements)

Math & Logic
Glyphics Both

#80 - View Preferences
#81 - Audio #82 - Kinesthetics #83 - Video
#84 - Null Values #85 - Personal Vocabulary
#86 - Internal Pointers
#87 - External Pointers
#88 - status discovery #89 - status scheduling #8A - status update #8B - user metrics
Both #8C -  #8D - privacy #8E - AI* #8F - User Feedback



Math & Logic Glyphics Both

#90 - Input ON/OFF #91 - Audio #92 - Kinesthetics #93 - Video
Memory #94 - button (1D) #95 - linear (2D) #96 - spacial (3D)
#97 - Quarantine
Programming #98 - Import (reformat) #99 - Torrent
#9A - Keyboard shortcuts #9B - Streaming
Both #9C - source code #9D - Statement interpretation #9E - Voice #9F - Multimedia



Math & Logic Glyphics Both

#A0 - Output ON/OFF #A1 - Audio #A2 - Kinesthetics #A3 - Video
Memory #A4 - Flags #A5 - Graphics #A6 - Scene Graphs
#A7 - executables
Programming #A8 - Export (reformat)
#A9 - Torrent
#AA - Keyboard feedback
#AB - Streaming
Both #AC - byte code #AD - Statement formation #AE - Speech #AF - Multimedia



Math & Logic Glyphics Both

#B0 - Help Index #B1 - function documentation
#B2 - facilitated search
#B3 - Information Theory
Memory #B4 - Blogs #B5 - application documentation
#B6 - facilitated documenting
#B7 - Knowledge Base
Programming #B8 - Discussion Boards #B9 - system documentation
#BA - facilitated design #BB - Code examples
Both #BC - Community interface
#BD - domain documentation
#BE - Turing (test) Interface #BF - technical assistance

Artificial Intelligence

The fourth table has the Communication In/Out-put and User Interface Types. This table contains terms related to the Artificial Intelligence. The four sub-tables (or banks) are explained below this table.


(no elements)

Math & Logic
Glyphics Both

#C0 - Memory index
#C1 - recent URLs
#C2 - Method binding #C3 - prototype matching
#C4 - Storage index #C5 - recent files
#C6 - metaphor
#C7 - SQL
#C8 - intranet index #C9 - recent programs
#CA - simile #CB -
Both #CC - internet index #CD - recent actions
#CE - holistics #CF - Domain Navigation



Math & Logic Glyphics Both

#D0 - Match input #D1 - class extension
#D2 - auto-callback alerts #D3 - heuristics
Memory #D4 - save matches
#D5 - argument classification
#D6 - Image matching
#D7 - holography
Programming #D8 - system state
#D9 - pointer evaluation
#DA - Regular Expressions #DB - homeopathy
Both #DC - Voice Recognition
#DD - return value classification #DE -  Programming Design Patterns #DF - pattern recognition



Math & Logic Glyphics Both

#E0 - axiom webs #E1 - variable identification
#E2 - lowercase and uppercase consideration
#E3 - 
Memory #E4 - axiom trends #E5 - data dictionary
#E6 -  #E7 - 
Programming #E8 - Scripting #E9 - Low Level #EA - High Level #EB - Systems
Both #EC - scope determination
#ED - length generalization
#EE - ambiguity removal
#EF - 



Math & Logic Glyphics Both

#F0 - 'new' Axioms #F1 - variable manipulation
#F2 - undefined variable expansion
#F3 - Smart facilitation
Memory #F4 - component selection
#F5 - lambda expression manipulation #F6 -  #F7 - 
Programming #F8 - component modification #F9 - anonymous function manipulation
#FA - recursive execution
#FB - Program Design
Both #FC - Dynamic Generation #FD - random variation #FE - domain expert generation
#FF - genetic programming

The Four Internal (Yin) Articulation functions Delineated

I have touched upon these concepts from another angle, but I think that this design is where the rubber really starts to meet the road. 

I'm skipping the four external I/O functions because they are basically the same as any other system ever (with or without glyphs), and the Communication table handles them nicely.


A general AI would have to manipulate tautologies. All systems of tautologies should have some similarities in the ways that an individual axiom forms interconnections with other individual axioms and with interconnected groups of tautologies.

Instrumentation can reduce a basic axiom to three glyphs (or less) and thereby efficiently encode an interconnected ontology. Since all glyphs are (theoretically) inherently and numerically classified into their own connotative domains (as Areas, Divisions and Blocks), developing strategies for generalizing and extending relationships should be simplified.

The (inspiration), (imagination), (codification) and (classification) tags show how the major processes interact with one another.

Eventually the system can build a knowledge ontology for a specific domain by asking the user to describe objects and relationships and then asking the user to validate extrapolated axioms. This (lengthy) process should result in a system that can predict the behavior of the various objects within that domain.

In essence, 'learning' requires the same types of data collection and organization whether the student is a person or a machine. This process should be seen as "getting to know a new friend".

If axioms were included in the statistics upload, a global decision support system could be developed that would greatly reduce the time required to 'train' the system to accommodate a new 'friend' by providing an initial ontology of "common knowledge".

Nothing bad can ever possibly come of this.


back to the home page.