[Whitepaper] Awesome.AI: A Dynamics-Based Framework for Thought Simulation

Version: Prototype

Document Type: Technical White Paper (Draft)

Author: Joakim Jacobsen

Repository: https://github.com/copenhagen-ai

Website: https://www.copenhagen-ai.com

Note: This system is experimental and subjective by design.

1. Introduction

This document represents, not a complete solution, but a progress that aims to convey an idea/vision and the framework which arose from that idea.

Personal experience, led me to the idea that thoughts could have mass. We see this when dealing with trauma and talk daily about heavy thoughts.

Assuming that thoughts have mass, or index from which mass, force etc can be deduced. Gravity then pulls towards heavy thoughts.

Gravitation can be simulated with classical mechanics to produce useful dynamics.

These ideas has led to a highly autonomous agent, which can be used for controlling other AI systems.

1.1: The Mission

The Awesome.AI framework proposes a new approach to simulate dynamics of the mind, using concepts borrowed from classical and modern physics.

It aims to:

• Present a new class of cognitive control architectures

• Simulate will, emotion and motivation using dynamics

• Create a simulated thought as smooth and continuous as in a biological system

1.2: The Overview

• Its a thinking engine, a highly autonomous agent. Does the thought go up or does it go down and from this more advanced systems emerge.

• The setup provides a mechanics that produces controlled randomness. From this, the output is mapped or modulated to processes of the mind.

• This produces dynamic thought patterns and emergent behavior.

1.3 The Concept in ONE line

Awesome(.) structures the stochastic, disorganized states of UNIT and HUB space into stable patterns.

UNIT: an abstract multi-purpose candidate, decision, action, or thought, that the system evaluates at each step.

HUB: the contextual state associated with each UNIT, providing it with context necessary for evaluation.

• S_t = {U_t, H_t}

• S_{t+1}=Awesome(S_t)

• U_{curr, t} = Select(S_{t+1})

• U_{act} = mode({U_{curr, t} | t ∈ [0, 500]})

Where:

• U_t = current state of UNIT space

• H_t = current state of HUB space

• U_{curr, t} = UNIT selected at time t

• U_{act} is the dominant UNIT across 500 cycles

The state evolves over time through repeated updates influenced by selected UNITs.

2. Core Concepts

One can think of HUBs as the context/problems and UNITs as answers/solutions.

2.1 UNIT

A UNIT is a single representation of a thought.

interface Unit {
    guid: string;         // unit id
    unit_vec: vector; 	  // Vector with 2 named axes, in the range 0.0 and 100.0 in UNIT-space
    hub_index: number;    // Value between 0.0 and 100.0 on a axis in HUB-space
    data: string;         // Static/chosen or Generated (LLM) according to unit_index and hub_index (HUB subject)
    credit: number;       // Score between 0.0 and 10.0
    ticket: string;       // Used for matching UNIT with external object
}

• A UNIT is a single representation of a thought.

• UNITs has a vector with 2 named axes in UNITspace, more axes can easily be added.

• UNITs has an index in current HUBspace.

2.2 HUB SPACE (Context/Group)

interface HubSpace {
    get_index: number;
    get_subject: string; // (e.g., "work", "having fun", "friends")
    get_units: Units[];
}

HUBspace is a set of local spaces selected by Occupasion*.
These local spaces contains HUBs/subjects, like: "work", "having fun", "friends".
Subjects can overlap under multiple Occupasions*.

Select Subject
Let:
- H = {h1, h2, ..., h_n}
- H_occ ⊆ H
- u.hub_index ∈ [0,100]

Each HUB has a weight:
- w_i ∈ [0,1]

Sum weight:
- W = ∑_{i ∈ H_occ} w_i

Each HUB is assigned a normalized area:
- a_i = (w_i / W) * 100
- ∑_i a_i = 100

Cumulative areas:
- A_k = ∑_{i=1..k} a_i

Such that the assigned HUB (h_k) satisfies:
- h_k ∈ H_occ such that A_{k-1} ≤ u.hub_index < A_k

Thereby tying a HUB/subject to a UNIT or grouping UNITs under a HUB.

needs done

• Subjects should be semantically ordered, as of now this is done manually.

2.3 UNIT SPACE

• First axis is always "will".

• Other axes are named for the property mapping they represent (Base-Prop*).

• In order to continuously better itself, the system dynamically adds and adjusts unit_index of UNITs.

• UNITs have a radius (ALPHA) around a coordinate in UNIT-space. This radius can be arbitrarily narrow, and therefore still adds up to an infinite number of UNITs.

Update:

Let Unit i have named indexes
- Ui(t) ∈ [0, 100]^k ⊂ R^k

- Uij(t) ∈ [0, 100] ⊂ R

Let the current set of UNITs at time t be:
- U(t) → {U1(t), U2(t)....UN(t)}
where
- U(t) is UNIT set and N is total number of Units

New UNITs can appear, and obsolete ones may be removed:
- Uadd(t) → new units to add
- Uremove(t) → units to remove

Each current UNIT evolves according to a stochastic directional step:
- Ui(t+∆t) → Ui(t) + α 𝜂 di(t)
where
- α ∈ [0,1] (stochastic step size from mech velocity)
- 𝜂 ∈ [0, 1] (user defined)
- di(t) = direction vector of current UNIT at time t

Updated UNIT Set
- U(t+∆t) → {Ui(t+∆t) | Ui ∈ U(t)} ∪ Uadd(t) \ Uremove(t)

There are two ways to view this system:

• as an agent, comprised of competing micro-agents, called UNITs. Each UNIT represents a candidate thought that competes for becoming an actual thought.

• as an infinite statemachine, UNITs being states and nonlinear or nondeterministic mechanics for navigating these states.

NOTE: Since the data in the system, should be auto generated by Third Party. "Thoughts/UNITs" can be viewed as abstract (index in UNITspace and HUBspace).

2.4 Discrete vs Continuous Architecture (by ChatGPT)

Awesome.AI models thought as discrete UNITs—atomic cognitive elements—each anchored to a coordinate in a continuous "UNITspace". This embedding enables the system to apply Newtonian-style dynamics (forces, velocity, acceleration) to the simulation over time. The physics operates in continuous space, while discrete UNITs act as semantic attractors that the trajectory can settle on.

3. Mechanics

The mechanics are metaphores for the dynamics of the mind.

These are tested to be working, others may exist.

Here will be described some of of the mechanics found.

The main reason for the mechanis is to create noise/randomness, which will be mapped to processes of the mind.

These can be extended to other physics domains, such as Thermal Systems, Electrical Systems etc.

Examples:

• Tug-Of-War (mechanical)

• Ball-On-Hill (mechanical)

• Circuit-2 (electrical, pinknoise, experimental)

• RocketEscapingBlackHole (mechanical, experimental)

3.1 Tug Of War (mechanical)

Definitions:

• Newtons 2. law → F = ma

• unit_vec ∈ [0, 100]^k ⊂ R^k

Formula:

• û → 100 - unit_vec[will]

• motor_sta → 2 / 3

• motor_dyn →

• {tanh(0.01û * 1.8) if v(t) < 0

• {0.01û * 0.8 if v(t) ≥ 0

• mtotal → C1

• Fmax → C2

• Ffric(t) → 𝛾 ∙ fcredits() ∙ -sgn(v(t))

• Fsta(t) → motor_sta * Fmax

• Fdyn(t) → motor_dyn * Fmax

• Fnet(t) → Fsta(t) + Fdyn(t) + Ffric(t)

• ∆v(t) → Fnet(t) * ∆t / mtotal

• v(t + ∆t) → v(t) + ∆v(t)

Friction

• In order to calculate the friction of Mech Stochastic, the system uses the dynamic credits of UNIT, to find the friction coeficient.

• Now the actual force for the mechanics can be calculated.

Randomness (by ChatGPT)

• At early stages, the interaction of forces can resemble a stochastic “tug-of-war,” similar to Brownian motion. But as UNIT-space becomes more organized over time, the stochastic output is increasingly constrained. What begins as loosely structured variability gradually transitions into coherent, patterned activity, forming the basis for emergent, thought-like behavior.

3.2 Mappings (by ChatGPT)

These are not exact mappings, but should be taken as descriptive.

Parameter	Base-Prop
delta velocity	Will (by author)
velocity	Attention
momentum	Commitment
acceleration	Adaption
kinetic energy	Activation
force (net)	Influence

3.3: Metaphors

Mech One, Tug Of War

• Two cars connected by rope or chain, they are going opposite directions. Car one drags with constant force, while car two drags with variable force.

• This produces the randomness (velocity), centered around ~0.0.

• This approximates the motion of a will-like drive in the system.

Mech Two, Ball On Hill

• This setup simulates a ball balancing on top of a hill. The ball can go down the sides. The hill can be more or less steep. By pushing the ball up the hill, the game is to keep it from falling down the sides.

• Like Mech One, this produces the randomness (velocity), centered around ~0.0.

• Like Mech One, this approximates the motion of a will-like drive in the system.

• In later versions of the system, one can imagine entire landscapes of hills and valleys.

3.4 Common Pattern in All Mechanics

The similarities for these mechanics, are that there is a static force dragging one direction and a variable force dragging or pushing the other way. ie. the car with a constant pressure on the the pedal (Mech One) and gravity (Mech Two).

This means the system only need to do calculations for one direction.

From these mechanics the system gets a velocity/current, if its accelerating the thought goes up and decelerating the thought goes down.

4. Filters, Selection and Internal State

Pseudocode, see Appendix B

4.1 Filters

the main filters are:

Credit

• Prevents overuse of any single UNIT.

• Credit is continuesly updated.

• Credit must be > 1.0 for a UNIT to be valid in UNIT-space.

• Current UNITs credit reduces (fast) and refills when not "current UNIT" (slow).

LowCut

• Removes the heaviest UNITs from selection (UNIT-space).

• This can be used to hide certain UNITs.

• Hidden UNITs are not subconcious thoughts, but lowcutted possible thoughts. Meaning, currently (long term) not available to the system.

• The idea of this dynamics was such a thought/UNIT.

4.2: Selection Of Current Unit And The Corridor

note: probability could be used for selection method, but omitted for simplicity

After applying filters, the current UNIT is selected by:

• determining a coordinate (near) in UNIT-space, that satisfies balancing the mechanics

• direction_vector → same if Down.No, otherwise reverse

• if direction_vector is same as previous

• -- near = unit_vec

• if direction_vector is reverse

• -- near = unit_vec.Reverse

• selection method: from valid UNIT-space, choose the UNIT closest to "near" coordinate (Pythagoras)

Corridor

• once the near UNIT has been found, a corridor (rectangle) in UNITspace is mapped from current UNIT to near UNIT

• UNITs within this corridor are stored in a ordered list, starting with near UNIT and ending with current UNIT, for later use (as of now unused)

• current UNIT and corridor UNITs are updated with new values

4.3: Handling Internal State (UNITspace)

Initially UNITs are scattered randomly across UNIT-space.
While selecting current UNIT, the state of UNIT-space is also updated.

Add UNIT

• if criterias are met, the system adds a new UNIT in an arbitrarily narrow area (ALPHA) around "near" coordinate

Criterias are:

• number of UNITs in HUB is less than CONST.MAX_NUM_UNITS

Adjust Index:

• note: weights/bias per axis could be used, but omitted for simplicity

• direction_vector → same if Down.No, otherwise reverse

• updates current UNIT by:

• unit_vec += MyRandomDouble * ETA * direction_vector

Criterias are:

• a new UNIT was not added

4.4: Handling Internal State (HUBspace)

Trace

• Trace is updated for all UNITs per cycle, by:

for each unit
    if current UNIT then
        unit.trace = unit.trace * DECAY + 1.0
    else
        unit.trace = unit.trace * DECAY + 0.0

Reward

• reward is given when the system has made a long decision, by:

• -- reward += 1.0 * trace

• UNITs are removed from the system if reward is below EPSILON

Update Index

• When current, apply reward to GAMMA like:

• -- GAMMAeff = GAMMA * (1.0 + reward_norm)

• Then hub_index is incremented/decremented towards index of HUB.subject, like:

• -- UNIT.hub_index ±= GAMMAeff

Update Weights

• current HUB weight is incremented by:

• -- weight += GAMMAeff * 0.1

• all HUBs on current axis (occupasion) are decremented by:

• -- weight -= GAMMAeff * 0.01

• LongDecision* UNITs does not trigger an update, meaning they are fixed in HUBspace.

5. Feedback, Properties And Algorithm

5.1 Feedback

The system operates a self-modifying feedback loop globally.

Feedback Loop

• The system forms a feedback loop globally. After each cycle, the UNIT selection and resulting adjustments to UNIT-space, in turn influences the properties of future mechanics. This creates a closed dynamical system where past activity shapes future computation with a self-modifying feedback loop.

5.2 Properties

a. Besides Base-Props the mechanic produces Mod-Props, these are Base-Prop + variations.
b. Mod-Props can be used for simulating: brainwave properties, communication properties, temperament properties etc.
c. Base-Props are the mappings of the DE.
d. Base-Props are in reference to an axis in UNITspace, thereby influencing UNIT selection, variations remain calculated.
d. Base-Props and Mod-Props are connectors for controlling other AI systems.

Modifiers And The Matrix

• Mod-Props are calculated by passing a Base-Prop through a set of modifiers and an update matrix.

• The update matrix allows for the properties to influence each other.

• Mod-Props include attributes like:

• -- for communication: Base-Prop → opinion → temporality → abstraction

• -- for brainwaves: Base-Prop → attention → readiness

• -- for temperament: Base-Prop → mood → ...

• Properties can be extended as needed.

• Properties should exhibit emergent behavior.

Example: Temperament is guided by a PatternGenerator (changes every ~10 seconds. Should later be by external/internal input like Pinch, Tickle etc.)
Is the Sine going from, eg:

• -1 to 1 (GENERAL)

• 0 to 1 (GOOD)

• -1 to 0 (BAD)

5.3 Overall Algorithm

It is build on the notion: many (eg. 500) impressions, produces one thought.

// this pseodocode is conceptual

Initialize system state
For i = 1 to N:
    Apply Mechanics
    Update Down and Mod-Props
    Apply filters (credit, lowcut)
    Find current UNIT
    Update UNIT-space (global feedback)
Return most frequently selected UNIT
Repeat From Top

• After N iterations, it finds the statistically dominant UNIT, aka actual UNIT.

• Actual UNIT should exhibit emergent behaviour.

6. Down and the Quantum Connection

Pseudocode, see Appendix D

Pseudocode, see Appendix F

6.1 Down

• Down handles representation of direction (YES/NO).

• When delta velocity (will) is below 0.0 → Down.YES.

• The meaning of Down, is that the system decides No or Yes to going down.

6.2 Changing Direction

1. Inertia and momentum cancels out some of the direction changes.

2. Shares delta velocity (will) across agents.

Mode	Description
One Agent	Uses delta velocity to calculate a probability for flipping Down (changing direction by multiplying by -1).
Multi Agents (Social Coupling)	When in proximity of other agents, a shared delta velocity is used to calculate a probability, then flips awesomeagent.Down and simpleagent.Down accordingly (changing direction by multiplying by -1).

6.3 Social Coupling (by ChatGPT):

This operator models subconscious awareness between agents. Inspired by how humans react to subtle cues like micro-expressions or body language, an agent’s directional update can be influenced by another agents state. When agents become aware of each other, their updates are no longer independent. Instead, they exhibit shared coupling, leading to alignment, divergence, or sudden shifts in direction. The strength of this effect is controlled by an awareness parameter. This is a simple way to simulate emergent social resonance through correlated behavior.

6.4 Controlled Inconsistency (by ChatGPT):

Some aspects of the system deliberately introduce what might appear as inconsistensies. For example, the DOWN state evolves independently of UNIT selection, allowing the system to assign directional outcomes that are not strictly derivable from its chosen thought. This controlled inconsistency is intentional: it enables richer dynamics, models cognitive contradictions, allows for external or subconscious influence, and creates an illusion of agency. Rather than a flaw, it is a designed mechanism to simulate the non-deterministic, sometimes contradictory nature of human thought.

7: Index vs Position

There are destinctions between the two.

Index:

• is used by the mechanics.

• is the placement of UNITs in UNIT-space (x-axis).

Position:

• is used by the mechanics.

• is the actual distance in meters, calculated by the mechanics. Normalized to a range 0.0 to 10.0.

• is used to shut down the system, by passing the position variable through either Reciprocal(position) or EventHorizon(position).

8. Systems

• The next sections will concentrate on Systems

• Systems are addons or modifiers, and not strictly part of the core framework

• Those described here seem natural to the framework, but others could exist

9. Occupation and UNIT-space

INFO: the system produces a MyRandom, which is used for this feature.

What has been described so far is the core of the framework. The core is focused on a fixed UNIT-space, but with occupation (-of the mind), UNIT-space is divided into portions of valid UNITs, thereby letting the system have trails of thought.

Occupation defines a named mental activity with a list of HUBs:

interface Occupation {
  name: string; // what is the systems current occupation
  max_epochs: number; // a number indicating how many epochs (max) is spend on this Occupation
  hubs: Hub[]; // a list of HUBs associated with this Occupation
}

9.1 Internal

• uses MyRandomto pick a number below max_epochs

• uses MyRandomto pick a Occupation

• for a unit to be valid, it checks if current UNIT->HUB is contained in current Occupation hubs, this determines if the UNIT show up in UNIT-space

9.2 External

to be valid in UNIT-space, a simple tag/ticket matching feature has been implemented.

• external objects are decorated with a tag, -a string like those used as HUB subjects

• the system will then check if the ticket of a UNIT matces an external tag

• if there is a match, the UNIT is valid in UNIT-space

10. Monologue

The monologue has two modes, the default is deterministic.

10.1 Deterministic Mode

• This mechanism uses static texts.

• The texts are chosen based on a combination of Mod-Props and HUB-subject.

• If texts are both positive or both negative, they are combined with "..and..", if different then "..but.." - (XNOR).

• It then plays "Connect the Dots" by removing first sentence and adding new sentence to the end.

• This produces the flow in the monologue.

10.2 Random/Latin Mode

• Sentence format: [MP, SUB] xxxx xxxx xxxx

• Random latin wordgenerator creates two sentences from a combination of Mod-Props and HUB-subject.

• If texts are both positive or both negative, they are combined with "..and..", if different then "..but.." - (XNOR).

• It then plays "Connect the Dots" by removing first sentence and adding new sentence to the end.

• This is for illustration of how to use Mod-Props and subject for sentence generation.

• GPT or similar, should handle sentence generation

• This produces the flow in the monologue.

11. Decisions

These are some ways decisions are made within the system:

• While the the system mostly does "idle thinking" - manages UNITspace, decision commitment can be triggered by LONGDECISION or QUICKDECISION UNITs.

• These can be internal or externally injected.

• The answers are stored/come from the data field of UNIT.

• Decisions are used, eg when Awesome.AI starts or answers a chat conversation.

• This makes the agent both reactive and proactive.

11.1 Quick Decisions

• uses current UNIT

• Quick decisions are made within an epoch (~500 cycles or less)

• Activates system state QUICKDECISION

• Clears UNITspace and injects a number of QUICKDECISION UNITs

• UNITs are removed as they are visited

• Returns a binary Yes/No decision based on the position in UNITspace of last UNIT (above/below 50.0)

• Restores UNITspace

11.2 Long Decisions

• uses actual UNIT

• Keeps track of actual UNIT index (10 epochs)

• Calculates an action ACTION, DECLINE, (NOACTION), based on average (trend) UNIT index

• Run across multiple epochs, with two possible solution paths:

State 1:

• Example 1: depending on current UNIT data, return a Yes/No answer

• Example 2: depending on current UNIT data, proceed to next state or decline

State 2:

• Example 2: If DOWN.Period = No, return current UNIT data. If DOWN.Period = Yes, decline decision

---

12. Usecases

These should be seen as thought experiments.

Parts needed:

• EnvironmentSystem, handles a timeline for generating state data (games, real world data)

• ControlSystem, a Specialized ANN for handling settings

• Awesome.AI, for handling goals, decisions, motivation, context (hubs, units)

• ThirdPartySystems (LLMs etc)

These are some usecases:
("→" means controls)

1. Awesome.AI → ThirdPartySystems

2. ControlSystem → Awesome.AI → ThirdPartySystems

3. EnvironmentSystem → ControlSystem → Awesome.AI → ThirdPartySystems

This makes Awesome.AI a cognitive control layer that can be designed or learned, and delegates execution to existing AI systems.

13. Limitations

These are some limitations:

• no consiousness (only dynamic will/motivation).

• no memory (or less than seconds).

• no feeling; but simulated emotion may be achieved through Base-Props and Mod-Props.

• no free will; but the illusion of free will. The heaviest UNITs are LowCutted, therefore the system does not experience the pattern from the mechanics. Hence the illusion of free will.

14. Possibilities

Further development:

• letting UNITs connect to multiple HUBs

• adding a GoalSystem

• adding a EnvironmentSystem, handles a timeline for generating state data - could come from games, real world data

• adding a ControlSystem, a Specialized ANN for handling settings for Awesome.AI

• MemorySystem - ie. making occupasions + UNITs active/deactive

• instead of directly jumping to near, a shortest path could be implemented through UNITspace (and UNITs along that line become a selection of current UNITs?)

15. Implications

The biggest problem is..

• the idea is quite simple, but hasn’t been tried implemented before

• what has been holding this idea back, is that it was a lowcutted thought

• should this idea remain hidden? (the argument, lets see what happens)

• is the idea generel or specific to my thought?

• this setup only needs validation for the idea to be correct?

16. Mentions

16.1 Stop function

• When some stop condition is met, the system ceases to apply Fdyn

• This means position goes towards zero

• The system then uses a reciprocal-style asymptote as stop function, like:

• -- Stop(position) = f(1 / (position + ε)), position → 0

• -- Terminate if Stop(position) ≥ threshold

• Other functions with asymptote like behavior can be used, like:

• -- EventHorizon

16.2: Closing Thoughts

• the system produces a random number, from velocity.

• maybe the definition for this system is not "a dynamics of the mind, but rather "a dynamics of the will of the mind".

• this is my subjective vision of how the dynamics of the mind should be modelled.

• this is a prototype.. and therefore not the final version.

17. Inspired By

Inspired By — Reference Guide (by ChatGPT)

Plato (The Cave)
Key idea: Reality is filtered; we only see shadows.
Connection: UNITs evolve in an internal simulation, representing an internal “shadow world” of thought possibilities.

Descartes (Idea World / Cogito)
Key idea: Structured reasoning can exist independently of the physical world.
Connection: UNIT-space models a self-contained idea-space where thoughts unfold according to internal rules.

Simulation Hypothesis (Bostrom / Modern Thought)
Key idea: Complex reality can emerge from computation.
Connection: Justifies a fully self-contained thought simulation, where internal dynamics alone drive outcomes.

Spinoza (Illusion of Free Will)
Key Idea: Freedom is an illusion; all actions follow natural causes.
Connection: Heavy UNITs/thoughts are filtered by the LowCut filter, creating the appearance of choice while the system remains unaware of the underlying mechanics.

Jean-Paul Sartre (Existential Freedom)
Key idea: Freedom includes the ability to refuse — to say "no."
Connection: The Down mechanism represents rejection of direction - to negate trajectory rather than continue it.

Newton (Classical Mechanics)
Key idea: Objects move under forces with velocity and predictable dynamics.
Connection: Velocity-driven mechanics provide the metaphor for how thoughts evolve and interact internally.

Yin–Yang
Key idea: Opposing forces maintain dynamic equilibrium.
Connection: Push–pull interactions and oscillatory dynamics in the simulation reflect balanced internal tension.

Psychology / Cognitive Patterns
Key idea: Thought dynamics can reflect diverse cognitive states.
Connection: Social Coupling simulates complex, unpredictable patterns reminiscent of cognitive variability observed in psychology.
Note: Metaphorical — not a clinical claim. Intended to map system dynamics onto recognizable cognitive patterns.

18. Glossary

Term	Description
UNIT	Individual data node representing a thought or decision
HUB	Persistent container grouping UNITs by theme or problem space
Mech Stochastic	Core mechanic producing oscillating dynamics (soul/will)
Delta Velocity	Change in system movement that guides directional transitions
LowCut	Filter removing most "massive" thoughts temporarily
Credit	A decay-based score regulating UNIT reuse
Will-Prop	Value representing direction, in the range -1 to 1
Base-Prop	Value derived the mechanics; guides Mod-Props
Mod-Props	Variations of Base-Props, defined by modifiers and a update matrix
UNIT-space	Abstract "space" where UNITs exist and interact. Defines relational geometry rather than storing data
Cycle	One internal update step where UNITs exchange forces and update states
Epoch	A group of cycles representing one full reasoning phase before evaluation

19. Appendix

Appendix B

• Pseudocode: UpdateCredit

function UpdateCredit(): 
    if mind.z_current ≠ "z_noise": 
        return 
 
    if not UNIT.OK(mind.unit_current): 
        return 
 
    list ← mind.mem.units_all() 
 
    for each u in list: 
        if not UNIT.OK(u): 
            continue 
 
        if u.root = mind.unit_current.root: 
            continue 
 
        cred ← CONST.UPD_CREDIT:
        u.credits ← u.credits + cred 
 
        if u.credits > CONST.MAX_CREDIT: 
            u.credits ← CONST.MAX_CREDIT 
 
    mind.unit_current.credits ← mind.unit_current.credits - 1.0 
    if mind.unit_current.credits < CONST.LOW_CREDIT: 
        mind.unit_current.credits ← CONST.LOW_CREDIT

Appendix D

• Pseudocode Down, Modifiers And Matrix

struct MyModifiers: 
 
    function Mod_A(value, prop): 
        base ← -0.05 
 
        if prop = "opinion":        # stronger damping for opinion 
            base ← base * 2.0 
 
        if prop = "temporality":    # stronger damping for temporality 
            base ← base * 2.0 
 
        return base * value 
 
    function Mod_B(value, prop): 
        base ← -0.5 
 
        if prop = "opinion":        # stronger damping for opinion 
            base ← 1.0 
 
        if prop = "temporality":    # stronger damping for temporality 
            base ← base * 1.5 
 
        return base * value 
 
    function Run(value, prop): 
        value ← Mod_A(value, prop) 
        value ← Mod_B(value, prop) 
        return value 
 
struct MyMatrix: 
    data ← dictionary<(string, string), double>() 
 
    function get(key1, key2): 
        if (key1, key2) in data: 
            return data[(key1, key2)] 
        return 1.0 
 
    function set(key1, key2, value): 
        data[(key1, key2)] ← value 
 
    function Run(val, key2): 
        res ← 1.0 
 
        for each entry in data: 
            key1 ← entry.key.item1 
            res ← res * get(key1, key2) 
 
        return res * val

Appendix F

• Pseudocode: Changing Direction (Continous)

function Continous(prop): 
    agent ← SimpleAgent(mind) 
 
    d_curr ← mind.mech_current.mp.d_curr 
    d_norm ← mind.mech_current.mp.d_100 
    d_save ← mind.mech_current.mp.d_100 
 
    down1 ← (d_curr ≤ 0.0) 
    down2 ← (agent.simulate_direction() ≤ 0.0) 
 
    d_norm ← mind.calc.normalize(d_norm, 0.0, 100.0, -1.0, 1.0) 
    d_save ← mind.calc.normalize(d_save, 0.0, 100.0, -1.0, 1.0) 
 
    if CONST.Logic = LOGICTYPE.CLASSICAL: 
        throw "Down, Continous" 
 
    if CONST.Logic = LOGICTYPE.PROBABILITY AND down1.probability(mind): 
        d_norm ← d_norm * -1.0 
 
    if CONST.Logic = LOGICTYPE.QUBIT AND down1.qubit(down2, mind): 
        d_norm ← d_norm * -1.0 
 
    if prop = "noise": 
        SetError(d_save ≠ d_norm) 
 
    d_norm ← Mods.run(d_norm, prop) 
    d_norm ← Matrix.run(prop) 
 
    SetProp(d_norm)