Menu

AI Organic Ecosystem - Nuts and Bolts

Daniel Zviel Girshin

 

Contents

General

Aim

Until now, within the framework of studies of information and knowledge systems, and in particular AI Ecosystems of this type, two extremes of the abstraction spectrum have generally been studied:

  • Theory
  • Implementation language

Here we will concentrate on the intermediate level – the technology of developing a distributed information system, while:

  • Applying theory
  • By means of a programming language

Distributed Information System – The Problem

Developing a truly distributed information system is one of the difficult tasks.

The concept itself contains an internal contradiction:

  • System – distribution

A system is something unified and coordinated, whereas distribution is the breaking of the system apart and the creation of isolation.

Most AI Ecosystems are not balanced between organization and distribution.

Examples of AI Ecosystems that are not properly designed:

  • Internet sites – although apparently they are client–server, there is actually no genuine information system here, but rather two parties between whom there is no real cooperation.
  • Intelligent agents – each one acts independently.

Properly Designed Distributed Information System

A properly designed distributed information system is one that combines:

  • Maximum organization
  • Maximum distribution

Each component must be independent and at the same time exploit the advantages of the system as a whole.

The system is more than the sum of its components.

Organic System

A properly designed distributed information system will be called “organic”.

The name may hint at:

  • Organization
  • Imitation of living organisms
  • Sophistication and complexity
  • Intelligence

Above all, one must remember that we are speaking of systems that are:

  • Complex in terms of structure and behavior and therefore –
  • Non-algorithmic

Therefore their development is also:

  • Complex
  • Non-algorithmic

The Technology

There exist only:

  • Guidelines
  • A collection of tools that can be used

Learning takes place:

  • During development
  • By way of trial and error

The project is:

  • Individual work
  • Independent thinking
  • Inventiveness
  • Development of “know-how”

General Characteristics of an Organic System

  • Intelligence
  • Development
  • Learning
  • Organization
  • Distribution
  • Large knowledge base

Basic Components of an Organ

  • Knowledge base (data, meta-data, procedures)
  • Feedback
  • Mechanism for acquiring information (interfaces and communication)
  • Learning mechanism (deriving new knowledge from the information and its processing)
  • Development mechanism (changing all the components, beginning with the knowledge base, in light of the new knowledge)
  • Interfaces:
    • Environment (local):
    • Subjective (user)
    • Objective
    • Communication (network environment):
    • With the center
    • With another organ
    • With others on the network
  • Execution mechanism (goals, procedures, motivation, emotions)

Applications

An example that will serve us repeatedly will be a tutorial program intended to teach the English language.

For convenience of demonstration we will not take the whole English language but only one basic topic – the numbers up to (and including) 20.

Below we will describe the implementation of the tutorial when it is implemented in the simplest and least sophisticated way from the standpoint of software structure.

Minimal Program

Algorithm

Show the pupil all the numbers up to 20 in numeric form and in word form.

Pseudo-code

WordList =

    Null
    One
    Two
    Three
    Four
    Five
    Six
    Seven
    Eight
    Nine
    Ten
    Eleven
    Twelve
    Thirteen
    Fourteen
    Fifteen
    Sixteen
    Seventeen
    Eighteen
    Nineteen
    Twenty

for all i <= 20
    print "i - "
    print WordList[i]
    print newline

In C language

#include <stdio.h>

void main()
{
    char* WordList[] = {"one", "two", "three", "four", "five", "six",
                        "seven", "eight", "nine", "ten", "eleven", "twelve",
                        "thirteen", "fourteen", "fifteen", "sixteen",
                        "seventeen", "eighteen", "nineteen", "twenty"};

    for (int i = 0; i < 21; i++)
        printf("%d - %s
", i, WordList[i]);
}

End of Part 1 – next parts will continue from “A More Practical Program”.

A More Practical Program

A more practical program will include not only presentation of the learning material.

The system will then also contain components such as:

  • A test
  • Saving and reporting to the student the results of the last test and previous tests
  • A menu

Algorithm

While the student does not wish to quit:

  • Show menu
  • Check the student’s choice
  • If the student’s choice is to learn – show the pupil all the numbers up to 20 in numeric form and word form
  • If the student’s choice is to take a test – test the student, show the test results, save the test results
  • If the student’s choice is to see her test results in previous tests – show test results of previous tests

Pseudo-code

While not student_wishes_to_quit do

    Show_menu()

    Read students_choice

    Switch (students_choice)

        Case "learn":
            for all i <= 20
                print "i - "
                print WordList[i]
                print newline

        Case "test":
            correct = 0
            errors  = 0

            for all i <= 20
                print "i - "
                read input
                if input == WordList[i]
                    correct = correct + 1
                else
                    errors  = errors + 1

            print newline
            print correct
            print errors
            print_to_file correct
            print_to_file errors

        Case "test results":
            while not end_of_file do
                print_from_file test_id
                print_from_file correct
                print_from_file errors
                print newline

        Case "student_wishes_to_quit":
            print "bye"
            Exit

Modular Program

The minimal program will be composed of modules. At the top level, we will separate at least the following (and split them into functions):

  • The information
  • The logic (the code that implements the processing algorithm)
  • The interface

The main units will be divided into files:

  • Menu file
  • Processing file
  • Learning-material file
  • Test-results file

We assume here a functional design and therefore each module will be a function.

The pseudo-code will now consist of functions. The main three functions will be:

  • menu();
  • teach();
  • test();
  • report();

Auxiliary functions will be, for example:

  • save();
  • write();
  • read();
  • quit();

Pseudo-code

While not student_wishes_to_quit do

    menu()

    read(students_choice)

    Switch (students_choice)

        Case "learn":
            teach()

        Case "test":
            test()

        Case "test results":
            report()

        Case "student_wishes_to_quit":
            quit()

Each module itself is composed of more specific modules. For example, in our case the function teach() can include teaching functions for a specific single word:

teach(0)  – teach the English word for "zero".
...
teach(20) – teach the English word for "twenty".

Then the function teach() can look like this:

void teach()
{
    for (int i = 0; i < 21; i++)
        teach(i);
}

Program with Feedback

In the general procedure:

  • After several cycles of the main loop,
  • and the user’s choosing the next action that the system should perform,
  • the chosen order of actions is recorded,
  • and from then on it is carried out automatically.

Only if the user informs the system that they want to change the order, does the system do as requested – it changes the order in memory accordingly, and continues from that point on to perform the new sequence automatically.

It is, of course, necessary to add here an additional data structure in which the order of actions chosen previously by the user will be remembered. Let us assume that the data structure is an array named sequence.

The feedback can be:

  • Explicit
  • Implicit

Explicit Feedback

Here the user is explicitly asked what is the order desired by them.

// ask user what sequence of actions he desires
ask_for_sequence()

// remember the sequence
initialize_sequence()

counter = 0  // start at the beginning of the sequence

While not student_wishes_to_quit do

    counter = (counter + 1) modulo sizeof(sequence)
    // go to next index in the sequence

    students_choice = sequence[counter]
    // the action to perform

    Switch (students_choice)

        Case "learn":
            teach()

        Case "test":
            test()

        Case "test results":
            report()

        Case "student_wishes_to_quit":
            quit()

More Modular Version

A more elegant way to do the same thing is:

  • To hide the initialization operations in a function,
  • and to simplify the control structure of the main loop.
init()

While not student_wishes_to_quit do

    // start from beginning
    for (int i = 0; i < sizeof(sequence); i++)
        // perform once the entire sequence
        call(sequence[i])

Implicit Feedback

Here the user is not explicitly asked what is the desired order. The sequence of actions is determined by the system from the user’s choices in the past.

// INIT

for (int i = 0; i < sizeof(sequence); i++)
    // init to NULL
    sequence[i] = NULL

// MAIN LOOP – till user quits
While not student_wishes_to_quit do
{
    // while not wishes_to_change the sequence loop
    While not student_wishes_to_change do

        if (sequence[last_index] == NULL)
            // if the sequence is not filled
            menu()        // ask user
            read(students_choice)
            sequence[i++] = students_choice   // remember

            // perform
            Switch (students_choice)

                Case "learn":
                    teach()

                Case "test":
                    test()

                Case "test results":
                    report()

                Case "student_wishes_to_quit":
                    quit()

        else
            // if the sequence is filled
            While not student_wishes_to_change do
            {
                // perform the sequence
                i = 0
                for (int i = 0; i < sizeof(sequence); i++)
                    call(sequence[i])
            }

    // IN CASE STUDENT WISHED TO CHANGE:

    menu()
    read(students_choice)
    sequence[i++] = students_choice

    Switch (students_choice)

        Case "learn":
            teach()

        Case "test":
            test()

        Case "test results":
            report()

        Case "student_wishes_to_quit":
            quit()

    // END OF CHANGE AND START PERFORM THE NEW SEQUENCE
}

The same code in a more modular form:

init()

While not student_wishes_to_quit do

    While not student_wishes_to_change do

        if (sequence)
            call(sequence[next])   // if all choices already known – perform
        else
            ask()

    change(sequence)   // change sequence if asked

Program with Feedback in the Teaching Function

Here the more important change is in the function teach().

The function will change such that only words the user did not know in the test will be presented in the future.

For this purpose the following changes will be made:

  • An additional data structure will be added to store the words that still need to be taught (for example an array wrong).
  • The function test() will change so that it also stores in wrong the words for which there was a mistake.
  • The function teach() will change so that it presents only words from wrong.

The function test() will from now on also:

  • Insert words for which there was a failure into wrong[i].
  • Increase the counter of words in the array, number_of_wrong (an auxiliary measure to know which part of the array is in use).

The function will look as follows (the change is highlighted conceptually):

void test()
{
    correct         = 0
    errors          = 0
    number_of_wrong = 0

    for all i <= 20
        print "i - "
        read input
        if (input == WordList[i])
            correct = correct + 1
        else
        {
            errors = errors + 1
            wrong[number_of_wrong++] = WordList[i]
        }

    print newline
    print correct
    print errors
    print_to_file correct
    print_to_file errors
}

The function teach() will now look like this:

void teach()
{
    for (int i = 0; i < number_of_wrong; i++)
        teach(wrong[i])
}

Program with Feedback in Teaching Rules

More important feedback will allow also changing the teaching rules.

For example, earlier we decided that exactly the words that the user did not know in the last test are the ones that will be presented in the future. We burned this rule implicitly into the code of the function teach() and into the function test().

But it would be possible to keep a rule written explicitly and open to change, which will determine:

  • The policy
  • The strategy
  • Regarding which words will be presented

Then the function will refer to the rule and, in light of it, will fill the list of words that will be presented in the next round.

Let us examine an example.

For brevity we will call:

  • Words for which the user failed in the previous round and gave wrong answers – “wrong words”.
  • And those for which they gave correct answers – “correct words”.

Let us assume that the rule is of the type: “for every certain number of wrong words present one correct word”.

The rule can be implemented using a number – the number of wrong words after which one correct word should be presented.

Let us assume that this number is called RATIO.

Option A

The function test() will from now on also:

  • Insert words for which a correct answer was given into correct[].
  • Use RATIO.
void test()
{
    correct         = 0
    errors          = 0
    number_of_wrong = 0

    for all i <= 20
        print "i - "
        read input

        if (input == WordList[i])
        {
            correct      = correct + 1
            last_correct = WordList[i]
        }
        else
        {
            errors = errors + 1
            wrong[number_of_wrong++] = WordList[i]
        }

        if (errors mod RATIO == 0)
            wrong[number_of_wrong++] = last_correct

    print newline
    print correct
    print errors
    print_to_file correct
    print_to_file errors
}

Of course, the same rule can be implemented in quite different ways.

Option B

Another possibility is to change the function teach(). Randomness can also be introduced.

We will hold an additional array in which correct words will be stored and call it correct[].

The function teach() will look as follows:

void teach()
{
    for (int i = 0; i < number_of_wrong; i++)
    {
        teach(wrong[i])

        if (i mod RATIO == 0)
            teach(correct[random(sizeof(correct))])
    }
}

A more specific teaching rule will be a complete sequence of correct/wrong. That is, the entire sequence of questions will be characterized in advance by a determination for each of the questions, of which type it will be.

An example of such a sequence:

    correct
    wrong
    wrong
    wrong
    correct
    wrong
    wrong
    wrong
    correct
    wrong

The implementation can come, for example, in an array of bits (we will call it RULE), where the notation will be:

  • 0 – wrong
  • 1 – correct
    1
    0
    0
    0
    1
    0
    0
    0
    1
    0

The function test() will fill two arrays:

  • Words on which a wrong answer was given
  • Words on which a correct answer was given

The function teach() will go over the array RULE and, according to what is written in the index pointed to by current_rule, will choose the type of word. The specific word will be chosen by the function from the relevant array out of the two:

  • correct[]
  • wrong[]

Program with Feedback in Teaching Strategies

Up to now the teaching rules have been fixed. For example, the ratio between wrong and correct in the next teaching round and the order in which they were presented were fixed in the examples above.

Only with respect to the words themselves was there feedback – the system learned which words belong to which category and filled the positions determined by the fixed rules in accordance with this feedback.

But we did not have feedback that changes the rules themselves.

Such feedback can be called “second-order feedback” and its rules – a teaching strategy.

Let us examine an example of such an algorithm.

Its principle will be implemented in the following loop:

  • From time to time:
  1. Create a new random rule.
  2. Examine the learner’s achievements when learning according to this rule.
  3. If it is better than the old rule – replace the old rule with the new one.

This is an example of a trial-and-error algorithm, a “hill climbing” algorithm.

Examination of the learner’s achievements can be done in many ways. For example, it can include time or not – both with respect to learning time and with respect to testing time.

The most basic criterion is, of course, the number of words learned.

Accordingly, the performance score can be, for example, any of these:

  • The number of words learned after three teaching cycles
  • The number of cycles it took to learn 80% of the words
  • The number of cycles it took to learn all the words
  • The time it took to learn all the words
  • The number of cycles per word learned
  • The time per word learned

The examination can be of active knowledge (translating into the new language) or of passive knowledge (understanding the new language). This distinction illustrates, to some extent, the difference between:

  • Convergent thinking – choosing from possibilities
  • Divergent thinking – creating possibilities

AI Ecosystem with Feedback in Teaching Strategies

The previous program, when standing alone, is not as powerful as an AI Ecosystem of such programs can be.

The idea is that each local program learns from the experience of all programs that are running.

Let us examine an example of such an algorithm.

The principle of its feedback stage will be implemented in the following loop:

  • Once every several cycles:
  1. Download the old “best rule” from the central server (together with its score).
  2. If it is better than the local one – it is the old rule; otherwise upload the local rule to the server, and the local rule becomes the old rule.
  3. Create a new random rule.
  4. Examine the learner’s achievements when learning according to the rule.
  5. If it is better than the old rule – replace the old rule with the new one and send the new one to the server (together with its score).

It should be noted that timing issues already arise here.

For example, we checked the up-to-dateness of the local system against the central one twice – both at the beginning and at the end of the loop. This is because of timing reasons.

For example:

  • A considerable amount of time may pass between step 1 and the last step, and during that time the server may have been updated.
  • Or it may happen that the last time the local system performed feedback it did not succeed in updating the server because of:
    • Technical communication problems, or
    • Its own failure or the server’s failure, or
    • User intervention.

The communication does not have to be with the server or with the server alone. For example, there may be communications:

  • With a neighbor on the network, or
  • With a group of local programs.

This depends on:

  • The architecture of the network
  • The organization of the AI Ecosystem.

Inductive System

The AI Ecosystem that we have built above has at least two disadvantages:

  • Too much information
  • Information that is not sufficiently reduced

On the one hand, it is doubtful whether there is a need for millions of systems that will report to the server. On the other hand, the question arises of the relevance of information regarding a particular user for a user who is completely different from them in all respects.

One possible solution is:

  • Adding information about the user, and using it to
  • Divide users into a large number of groups, such that
  • Within each group alone, the information of users belonging to it will be used.

The main loop will be identical to the system above, except that we add a learning stage (in feedback, both explicit and implicit) of the local system about the user.

Here will come:

  • General information about the user
  • Information about their way of learning

General information will include, among other things:

  • Mother tongue
  • Knowledge of other languages
  • Age
  • Education
  • Occupation
  • Personality
  • Learning habits

Information about learning will include, among other things:

  • Motivations for learning
  • The time devoted to learning
  • At what hours
  • At what frequency
  • Preferences

Ways of collecting the information:

  • Part of it will be collected by direct questions already at the beginning,
  • Part while learning and from time to time,
  • Part not through questions at all but from the learning process itself.

The principle of the feedback stage here will be implemented in the following loop:

  • Once every several cycles:
  1. Find out information about the user and classify them.
  2. Download from the central server the old “best rule” regarding relevant user types.
  3. If it is better than the local rule – it is the old rule; otherwise upload the local rule to the server and the local rule is the old rule.
  4. Create a new random rule.
  5. Examine the learner’s achievements when learning according to the rule.
  6. If it is better than the old rule – replace the old rule with the new one and send the new one to the server (together with the user-type label).

This is an example of inductive thinking and of case-based reasoning.

It is also possible to refine the classification process by involving the users in it.

For example:

  • Ask the user to suggest attributes which they think are relevant for classifying themselves as a learner, or
  • Offer them to choose attributes that seem to them relevant from a very extensive list, or
  • Ask them to tell about themselves.

This information can be processed locally, but it is particularly important to send it to the server in order to offer it to other organs. The server itself can perform statistical processing here as well.

Probabilistic System

Assuming that not much information is found about users exactly of the type of the local user, it is possible to settle for partial matching. The more partial the match, the more we speak of analogy.

In mathematical language we then speak of probability and statistics.

On the server, statistical analysis will be performed according to individual attributes and groups of attributes (clustering).

Guidelines for Development

Up to this point we have illustrated ideas through one concrete example. We now move to a more general level and outline principles for developing complex organic information systems within an AI Ecosystem. These principles are not recipes but rather a collection of technological guidelines and ways of thinking that can be combined in many variations.

  • Non-algorithmic approach
  • Use of deep models
  • Feedback at multiple levels
  • Induction
  • Annealing – occasional radical change
  • Classical software engineering disciplines, especially modularity

Non-Algorithmic Approach

In classical computer science, influenced by mathematics, the central ideal is the algorithm: a finite procedure that always terminates and always yields a correct result. This ideal has enormous value, but it does not always fit the messy realities in which AI Ecosystems operate.

Sometimes:

  • No exact algorithmic solution is known.
  • An exact algorithm exists but is too expensive in time or memory.
  • The environment is open, changing and uncertain, so “correctness” itself is relative.

In such situations it is preferable to look for:

  • Heuristics.
  • Approximate solutions whose quality can be measured.
  • Procedures that improve with experience.

Thus, instead of asking only “Is there an algorithm that always works?”, we also ask: “What can be done here, given realistic resources, evolving data and partial knowledge?”.

Examples of Solutions

A few simple examples clarify the spirit of non-algorithmic solutions:

  • Numerical approximation. Computing the square root of 2 does not require a closed-form formula. An iterative procedure that gradually converges to the desired accuracy is usually sufficient.
  • Everyday decision-making. Deciding whether to take an umbrella is never based on full certainty. We work with probabilities, risk assessments and personal preferences.
  • Search in huge spaces. In large combinatorial spaces there is no hope of exhaustively checking all possibilities. Instead we use local search, heuristics, randomization and learning from experience.

The common theme is that we accept partial knowledge, admit uncertainty and trade exactness for robustness, adaptability and resource awareness.

Deep Model

DATA + META-DATA = KNOWLEDGE

A deep model is more than a table of values. It captures:

  • Structure (entities, relationships, hierarchies).
  • Semantics (meaning of the data and its constraints).
  • Procedures (how data is created, changed and interpreted).

Different modeling languages offer different kinds of depth:

  • Relational schemas and entity–relationship diagrams.
  • Logic-based representations (predicates, rules).
  • Markup languages (XML, HTML, domain-specific tags).
  • Decision trees, state machines, graphs and networks.
  • Object-oriented models, including classes and inheritance.

In an organic AI Ecosystem, several modeling approaches may coexist and complement one another: some more declarative, others more procedural; some focused on static structure, others on dynamic processes.

Feedback

Feedback means that the system observes the results of its own operation and uses them to modify itself. In an organic AI Ecosystem, feedback may affect:

  • Parameters (such as difficulty levels and pacing).
  • Policies (such as which user groups receive which strategies).
  • Structures (such as which rules, modules or models remain in use).

Feedback can be:

  • Direct – explicitly specified performance measures are monitored.
  • Indirect – the system infers patterns from logs, traces and interaction data.
  • First-order – modifies operational behavior.
  • Second-order – modifies the mechanisms of modification themselves.

Educational organs, for example, can adapt to each learner by changing:

  • The sequence of tasks.
  • The form of explanations.
  • The distribution of practice and testing.
  • The kinds of hints and encouragement messages.

Induction

Induction is inference from particular cases to general regularities. In the context of our AI Ecosystem, induction underlies:

  • Clustering of users into types and profiles.
  • Deriving teaching strategies from observed successes and failures.
  • Learning rules and patterns from usage logs and interaction histories.

The process is inherently probabilistic and provisional: new data can confirm or challenge current generalizations. Therefore, inductive knowledge must be continuously checked, revised and sometimes abandoned.

Annealing

Systems that learn only by gradual adjustment may become stuck in local optima – habits or configurations that are good but not the best available.

Annealing is the practice of occasionally making larger, even random changes in order to escape such local traps. For example:

  • Trying an entirely different teaching strategy for a short experimental period, even if the current strategy works reasonably well.
  • Introducing a new representation or model and letting it compete with the existing ones.
  • Randomly resetting some parameters (within safe limits) and observing the effects.

The system must, of course, combine annealing with evaluation so that harmful changes are filtered out and beneficial ones are preserved.

Software Engineering – Especially Modularity

Despite the emphasis on non-algorithmic behavior, classical software engineering is not abandoned; on the contrary, it becomes even more important. Without disciplined structure, an organic AI Ecosystem collapses under its own complexity.

Key principles include:

  • Clear separation of concerns (data, logic, presentation, communication).
  • Layered architectures.
  • Interfaces and contracts between organs.
  • Incremental development and refactoring.

Modularity

Modularity is the recursive decomposition of the system into components:

  • Each component has a clear responsibility.
  • Each exposes a limited, well-defined interface.
  • Internal details are hidden and may change without affecting the outside world.

In the context of organs in an AI Ecosystem, modularity allows:

  • Local experimentation without destabilizing the entire environment.
  • Replacement of underperforming modules by better ones.
  • Parallel development by independent teams or agents.

At the lowest level, a module may be:

  • A single function implementing a straightforward control structure.
  • A small cluster of functions cooperating around one responsibility.

Documentation – Comments and Help

Complex organic systems are not transparent; documentation is essential for both human developers and users. Documentation should accompany:

  • All stages of the project – from initial design through deployment and evolution.
  • All levels – from high-level models down to individual modules and functions.

We distinguish between:

  • Internal documentation – comments in the code, design notes, explanations of interfaces and invariants.
  • External documentation – user guides, help pages, tutorials and explanatory messages that appear during interaction.

Both kinds of documentation should reflect the same underlying conceptual model of the system, so that the way the system is explained matches the way it really behaves.

Characteristics and Tools

Technological Emphasis

When dividing knowledge into three layers—Theory, Technique, and Implementation—the practical work of building an organic AI ecosystem must emphasize the technological and practical middle layer. Too much focus on implementation alone may lead to superficial quick fixes; too much focus on theory may detach the project from concrete goals.

Abandoning the Algorithm

There is no requirement to know, or even to possess, a complete algorithmic solution. A chosen approach does not need to stop at a full, always-correct result. Non-algorithmic methods are acceptable and often preferable for complex, evolving systems.

Deep Model

Greater understanding should be captured as meta-data within the chosen modeling language. A deeper model includes structure, semantics, and processes rather than shallow data alone.

Multi-Level Feedback

Feedback shapes the system at all levels: content, logic, behavior, and learning. Feedback is not only a cybernetic foundation but the central mechanism driving improvement. Integrating feedback thoroughly is essential.

Development

Continuous change is fundamental. The system evolves after each action, feedback cycle, and introspection stage. Development is explicit and ongoing.

Non-Determinism

Conceptually, non-determinism reflects a non-algorithmic approach. Practically, it means creating multiple possibilities and exploring options instead of following a single fixed execution line.

Annealing

Also known as “random walk.” To avoid becoming confined to narrow behavioral patterns, the system occasionally performs random or exploratory steps. These may appear to contradict logic in the short term, but in the long term they expand the system’s space of possible solutions. Brainstorming is a familiar example of this principle outside computer science.

Natural Science Approach

A natural-sciences mindset—not a strictly formal mathematical one—is necessary for non-algorithmic systems. Emphasis is on experiment, observation, generalization, and explanation rather than definition, logical derivation, and proof.

Realism

Organic AI ecosystems must operate under real-world constraints, noisy environments, partial data, and uncertain interactions. Realistic assumptions guide better system design.

Errors

Since errors are an inevitable part of reality, the system must allocate design effort and resources to dedicated mechanisms for dealing with them. Here we are not speaking only of mistakes made by the designer or programmer, but of errors as an inherent component of the world. In any non-trivial organic AI ecosystem it is impossible to prevent all system-level errors, but it is possible and necessary to build mechanisms that detect, contain and respond to them.

Checks and Balances

The different mechanisms and perspectives in the system must be sufficiently diverse and complementary so that the system is not dragged too far toward one extreme, into danger, or into paralysis. Checks and balances reduce the risk that a single flawed component, method or worldview will dominate and distort the behavior of the whole ecosystem.

Environment

The environment is a decisive factor and an integral part of the system. Input never ends: the system is not closed. It should even deliberately generate stimuli that will provoke feedback from the environment. A continuously updated model of the environment is a vital component of the system’s knowledge.

Trial and Error

Many techniques are based on the principle of trial and error, and this principle is indispensable in any practical system. In an organic AI ecosystem, trial and error applies not only to parameter tuning but also to rules, strategies, representations and even architectural choices.

The Human

The human being is part of the system. Many operations must explicitly take into account human participation. This is not a flaw but an essential feature. The designer continues to participate, and so do the users. The system is not “just a computer” but a constellation that includes humans with their decisions and interpretations, as well as other environmental factors that influence the system not only as inputs but also as processing and decision modules in their own right.

Systemic View

A systemic view sees the AI organic ecosystem as more than the sum of its parts. There are emergent mechanisms that belong to the system as a whole, and additional mechanisms specifically dedicated to organizing and maintaining it as a coherent system. These “meta-mechanisms” require explicit design attention.

Composition

A large number of relatively simple inference mechanisms can, when composed correctly, produce very advanced capabilities. Quantity can turn into quality: many small, local operations combined through careful composition can yield global intelligence.

Declarative and Procedural

Many mechanisms tailored specifically to a problem and close to its declarative side may also arise from facts and knowledge. It is important to provide a mechanism that can translate procedures into knowledge and knowledge into procedures. The ability to move back and forth between declarative and procedural forms supports explanation, adaptation and reuse.

Abstraction

Multiple layers of increasingly general views are a key element both in constructing and in operating the system. Abstraction enables the ecosystem to reason about families of situations, not only about specific cases, and to organize its knowledge at different levels of granularity.

Gestalt

High-level rules, auxiliary principles, the motivations of the system, and its guiding paradigms can all be grouped under a concept taken from cognitive science: gestalt. This gestalt component plays an important role in almost every aspect of an organic system, shaping which patterns are recognized, which goals are pursued, and how conflicts are resolved.

Duality

Every organ and every knowledge component has two different aspects:

  • As a system made up of smaller, less complex parts.
  • As a single component within a larger system beyond the organ itself.

The ability to view each element “from the inside” and/or “from the outside” is a powerful tool for design, debugging and explanation.

Induction

Induction is a central tool in the non-algorithmic approach, just as deduction is a central tool in the algorithmic approach. Induction underlies learning from examples, recognition of regularities, and the formulation of new rules from experience.

Introspection

Introspection is sometimes also called “reflexivity”. It is the ability to examine the processes of examination themselves. The system is able to know something about its internal mode of operation and to change it. In a certain sense, this can be seen as the ability to change its own “program”.

Organs

Agents can be seen as one example of organs of a certain type. Organs, however, are both more and less complex than agents:

  • More complex, because they have internal organization and are embedded in an external organization (the larger ecosystem).
  • Less demanding, because they do not require as much autonomy – they can rely on the resources and decisions of the organization.

Organs are typically less algorithmic, and fewer rigid requirements are imposed on them. They can serve as an abstract model only, where the implementation is very different (e.g., different objects in the same program, different threads, or even different aspects of the same software component). They can also be implemented more literally, so that the relevant “atoms” in the system are organs, shifting from object-oriented design and programming to organ-oriented design and programming. Here, the organ is a richer object including connectivity to the organization, communication, goals and intelligence.

Sociality

Sociality and cooperation, inspired by human societies and other collectives, have become a common approach in computer science. Marvin Minsky’s influential book “The Society of Mind” emphasized such ideas. Technologies like “ant programming” and swarm-based methods are rooted in this social view.

The Organic World

Learning by analogy from the organic world—biology, sociology and more—is an important tool both for designers and for the system itself during operation. The structures, processes and evolutionary patterns in organic systems offer rich inspiration for AI organic ecosystems.

Sophistication

In addition to having many simple mechanisms, the system needs more sophisticated mechanisms as well. These can emerge from suitable organization of the more basic components. For example, very complex inductive mechanisms can include not only drawing conclusions but also revisiting them, actively searching for counterexamples (as emphasized by Karl Popper).

Organization

Within the system there are also control and management mechanisms and specific inference procedures that are complex and non-linear, such as sophisticated search engines or planning modules. Organizational concerns pervade every component and action in the system, including the feedback mechanisms themselves.

Developmental Aspects

Evolution and natural selection, in both their broad conceptual sense and their more technical formulations, are valuable tools and mechanisms for inference, control, organization, coordination and scheduling. Developmental processes allow the system to refine itself over generations of variants and interactions.

Knowledge Engineering

Knowledge engineering is a whole discipline, with a wide variety of techniques, that can contribute numerous tools, especially in the area of meta-data. Many representations and elicitation methods from knowledge engineering are directly applicable to building organic AI ecosystems.

Formalisation

Formalisation is an important tool but must remain partial, convenient and flexible. Overly rigid formality can conflict with the need to handle noisy, evolving and ambiguous reality. The goal is to gain the benefits of formal precision where it helps, without imprisoning the system in brittle structures.

Semantics

Semantics may be more crucial than syntax, though never a replacement for it. The system must continually move between information and knowledge, between reality and model and back again. Working in parallel on both sides—semantic and syntactic—is what yields the best results.

Interfaces

Interfaces between organs, between organ and human, and between organ and environment must be as convenient and natural as possible. Good interfaces reveal the right amount of internal structure, enable rich interaction and reduce the cognitive load on human participants.

Interactivity

Dialogue (as opposed to monologue) is central in the system’s contact with humans, users and the environment. But the system must also change in light of the ongoing “dialogue” with its own data and knowledge. Interaction is not a one-time event but a continuous process.

Multidisciplinarity and Interdisciplinarity

Many disciplines provide useful perspectives and tools for an organic AI ecosystem, including:

  • Knowledge engineering
  • Psychology
  • Sociology
  • Biology
  • Ecology
  • Neurophysiology
  • Language theory and linguistics
  • Philosophy of science
  • Information theory

Probability

A probabilistic and statistical outlook, together with concrete techniques from these fields, is a key component. Many decisions in an open AI ecosystem cannot be made deterministically and must rely on likelihoods, confidence measures and distributions instead.

Information vs. Knowledge

We must distinguish between information and knowledge, yet also see them as two sides of the same coin. Information can be viewed as raw, context-poor data, whereas knowledge is structured and interpreted information. The system constantly transforms one into the other.

Knowledge and Processing

The relationship and distinction between knowledge and processing are not always clear-cut. Sometimes it is useful to distinguish them; at other times it is better to treat them as a single whole. In organic AI ecosystems, processes may themselves be encoded as knowledge, and knowledge may be activated as processes.

Analogy

Analogy—drawing parallels—is a central and very important inference mechanism in realistic systems. The associative connections that underlie analogical reasoning are a core mechanism in how the system generalizes and transfers experience from one domain to another.

Logic Programming

The approach in logic programming is deductive but not algorithmic in the classical sense. The problem is not solved by prescribing a sequence of steps, but by describing it in a formal logical language. The system then processes this description automatically and derives solutions. Prolog is a classic example. This approach is well suited to expert systems and, more generally, to knowledge-rich systems.

Rule Creation

There are many tools for creating explicit rules, such as decision trees. An example of an algorithm for inducing such trees is C4.5. These tools translate empirical data into structured, human-readable rules that can be inspected, modified and combined with other knowledge.

Data Mining

Data mining is a family of tools, rooted in machine learning, for inferring generalizations from large information repositories. The overall approach is largely statistical: patterns, clusters and rules are discovered by scanning and analyzing the data in multiple ways.

Software Engineering

Software engineering techniques are extremely important for any system and especially for building an organic system. Modularity, in particular, plays a critical role in managing complexity, enabling evolution and supporting experimentation.

Project Model

The project itself requires a non-linear, complex mode of thinking. Project models, parallelism, layering, distributed communication and the presence of many cooperating organs all demand a sophisticated development methodology. Planning and execution must account for feedback, iteration and partial results.

Context

Context—association, connectivity, similar situations and relevance—is both a central and a difficult component. The same data item can have very different meanings in different contexts; managing these shifts is a major challenge.

Relevance

Relevance can be viewed as the process of encoding and problem-solving:

  • From the total set of facts to those that might be relevant.
  • From this set to a small enough subset of the most relevant items for the moment.
  • Process this focused subset thoroughly.
  • If no solution is found, change the subset (for example, relax or shift relevance criteria) and repeat.

Since the active subset is small, the processing itself does not have to be very sophisticated: it could even examine all possibilities, including in exponential time if needed.

Dynamic Recognition

Dynamic recognition means identifying entities not only by a static property or by membership in a fixed group but according to their process and history. Something that looks very different today from how it looked before can still be recognized as “the same thing”. This is one of the strengths of natural language and of organic cognitive systems.

Inference

The inference mechanism at the high conceptual level does not have to be identical to the mechanism at the implementation level. Different aspects of inference correspond to those of any formal system or paradigm:

  • The technical method of inference (algorithms and representations).
  • The criteria for evaluating the result (axioms, constraints, acceptance conditions).
  • The goals guiding the process (which, in a very formal sense, may also be treated as axioms; in a broader, less formal sense they can be seen as meta-knowledge, knowledge outside the system, gestalt).

Types of Inference

A main division is between deep models and shallow models, and between deductive and inductive approaches. This dichotomy is well known in computer science and in other disciplines, but our inclusive, flexible approach makes it possible to move toward deep models that combine several types of inference.

Continuous and Initiated Work

The system continues to work even when no external request is made. It constantly develops itself and acquires knowledge. The simple loop of “temporary solution and feedback until a solution” is replaced by a more complex loop:

  • Knowledge is acquired and a temporary solution is produced in light of it.
  • Feedback and checking against other knowledge lead to a local solution.
  • At the same time, the system acquires additional knowledge for future improvement.

Guided Inference

At every level of generality, in addition to the rules at that level, there is a gestalt—a higher-level rule system that guides the system’s work. This allows the system to choose between conflicting rules or to determine which small subset of rules and facts is currently relevant.

Strategies

Beyond a collection of specific rules (and a hierarchy of rules), the system develops strategies: patterns of action and decision across many situations and at different levels of abstraction. The processes of abstraction and reduction are among the most important in building these strategies.

Learning Engineering

Learning engineering concerns the design of smart learning processes. At least four fundamental aspects underlie decisions about learning:

  • The goal of learning.
  • What to teach (topics, domains).
  • Which general pedagogical approach to use (behaviorist, gestalt, inductive, deductive and so on).
  • The strategy: which actions to take, when, how to combine them, and how to respond to feedback.

A lesson plan, for example, should include all these aspects at an appropriate level of detail for its purposes and intended audience. Strategies themselves can be represented at different levels of detail and abstraction.

A strategy can be technical, precise and highly detailed, sitting only one level above basic actions. We should remember that there is no action so basic that it cannot be decomposed further, yet we can still treat actions like:

"display on screen: '1 - ONE'"

as basic or atomic for many purposes.

Among the basic (atomic) external actions we may include:

  • display – show information on the screen or through another channel;
  • ask – request a response from the learner or environment;
  • test – all feedback-related actions, not only grading the learner’s answers but also collecting reactions from parents, other teachers, or peers learning together;
  • evaluate – present an evaluation or summary.

These are external actions, in contact with the environment. Basic internal actions include:

  • remember – add information;
  • analyze – derive new knowledge.

A simple strategy might be: present, ask, and evaluate all the material, until the learner asks to stop.

A more sophisticated strategy: present only material that was not previously known; ask only the more difficult questions in each group; assume that a correct answer implies that the entire group has been mastered and need not be taught again; evaluate with encouraging feedback (even if not fully objective, such as “excellent”, “better than others”, or emphasizing successes and downplaying errors); stop after a high success rate (there is no need to aim for 100%).

Flexibility

Flexibility is closely tied to interactivity. The system must allow the user to influence, to the greatest possible extent, the flow of information and actions, to obtain rich information about the system, its operation and its current state, all via convenient and intuitive interfaces. This initiative should not merely be tolerated but actively encouraged.

Knowledge Structure

In implementation we must distinguish between the structure of knowledge and the structure of data; that is, between the model and its implementation. It is better to think in terms of a scale rather than two extremes: a discrete but rich set of levels between pure conceptual models and concrete data structures.

Model and Mechanism

The model can have a structure that matches, resembles and corresponds to the structure of the semantics and of reality—both statically (structure) and dynamically (algorithms acting on that structure). Data structures can, in turn, be chosen to match the model.

For example, if in reality there are several factors each with a quantitative weight (such as storing proportions of substances), then the model might be a DNA-like representation or a vector, with a corresponding genetic algorithm; an appropriate data structure would be an array.

If the reality is an organization with a strict hierarchy, then an appropriate model is a tree, and the implementation might be an efficient tree representation such as a red–black tree or a B-tree.

If the domain consists of multiple entities with complex and changing relationships, a graph is more appropriate, and the implementation can use adjacency matrices or adjacency lists. For natural language, a natural model might be a semantic network. For relatively rigid systems with simple roles assigned to each element, a natural model might be a neural network, implemented with matrices or objects.

Development of the Organ

An organ is a changing, developing entity. Its level of development can be determined according to different criteria. As with any organic entity, it has an age and develops over time. Age can reveal much about its developmental state and properties. Age may be measured as elapsed clock time or as “life time” in terms of active operation.

The level of development is determined primarily by the quality and quantity of the organs that make up the organ itself. Inference rules and change and development techniques can be divided into:

  • General – shared by all organs.
  • Specific – tailored to the particular organ.

Intermediate cases are also possible, such as rules shared by a group of organs.

Organic Project Model

In general, we can speak of a loop of acquiring knowledge about how to support self-development (including knowledge about the domain itself and not only about the system):

  • Development; acquisition of additional higher-level knowledge as a result of system behaviour; further development (relative to an existing system, acting as “teacher” rather than “parent”).

This overall loop can be unfolded into several nested loops:

  • Needs–Information–Knowledge loop during the specification stage: defining the final goal and temporary intermediate goals.
  • Capabilities–Information–Knowledge loop during the design stage: designing the knowledge base (meta-data and core information) and identifying essential components for development: feedback, acquisition of data, acquisition of meta-data, creation of new abstraction levels, introspection.
  • Tools–Information–Knowledge loop during the implementation stage: producing a working system that can be evaluated, grow and develop.
  • Results–Information–Knowledge loop during the testing stage: examining technical achievements.
  • Results–Information–Knowledge loop during the maintenance stage: examining substantive achievements (goals reached) and directions for system development, and acquiring additional developer knowledge that will allow better outcomes in the next cycle of the loop.

Types of Organs

Types of organs include:

  • Local organs – serving a single user.
  • Group organs – aggregating several local organs. The group may also contain organs that do not serve any particular single user but function as auxiliary mechanisms, servers for the entire group, such as a central information repository, centralized processing, or responsibility for communication among organs.

Non-local (central) organs reside on a central server. However, a significant portion of the knowledge will remain also (or only) in local organs, such as everything specific to a particular user and enough general knowledge to allow nearly normal functioning even if communication fails and the local organ is temporarily isolated.