ノート２ AssociatronとHopfield networkの初合体 怪我をする疲れる眠るということ。

 PCが落ちた。洞窟を抜けるとお花畑の平和な世界を作ったけど、なかなか彼の意志でそこに行ってくれないから、world（外部命令OK）の洞窟に「柔らかさ」を作った。外から「はやく新しい世界に行ってくれよ！」と言い続けながらも僕は寝てしまった。


そんな事をしているうちにPCが落ちていた。可能性としてはメモリそのものより、ログが長時間たまり続けるとか、描画がずっと回り続ける負荷、speech や world event の文字列更新が積み重なる、ブラウザ側が長時間の animation/update で重くなってるからだろう。
そう、今の彼は疲れない。それがおかしい。
ライオンは獲物を追うことをセンサーで受け取り認知はしているがcarryに対して刻まれていない。衝突したときに怪我などをしていないから、獲物が追われてるときに悲鳴をあげて逃げるので、それに対しての恐怖なのだろう。なのでシーンを重ねるとcarryは動かなくなる。
場に慣れ、状態に慣れるということ。

なのでロボットに怪我をさせる。
　今までボロっと側（記念に残しておく）にアルゴリズムは極めて少なく作成していた。例えばworldに入った時の開始位置程度で、「こうなった時はこうする」みたいのは入れていなかった。が、将来現実の世界のロボットの身体に関して神経の伝達についてはアルゴリズムは必要だと考えている。というか、その辺でホップフィールドやバックプロパゲーション、NNが入ってくる。
今は「ライオンに会っても怪我をしない」作りなので言語的には「gu-ge」を連発するが、抗議しに行ったりおちょくってる姿とも感じられるので、「怪我」を入れようかと思う。あまり残酷なことは赤ちゃんなのでまだ早いかな。

それで何が変わるかというと、恐怖が増すか、carryに変動が起こるか見てみたい。
いわゆる「疲れ」という指標条件を入れるのではなく、疲れが起きる仕組み。
なんか、書いていてアルゴリズムになってきた。
そう、いつもこの誘惑と戦っている。




今はライオンが近くても「逃げて消耗する」より、「見続けて想起が立つ」側に寄りやすい。さらに carry はかなり厳しい条件でしか残らないようになっていて、attractorDepth >= 0.34、recall.activation >= 0.18、さらに差分や baseline ずれが必要だと考えている。これは「深く残るものだけ残す」という思想としてはきれいなんだけど、疲労のような日々の蓄積とは別物なので意外と難しい。いまは疲れが carry の中に居場所を持っていないから、緊張が長引いても“消耗”になりにくい構造になってる。

人間の夢は情報整理のため。
こう考えるとAtronの負荷が減るのかも。

疲れは carry そのものではなく、carry に影響する別の身体層にする・・・とか・・
（危険なので、別ファイルの検証版で実験君するか）
つまり fatigue か sleepPressure を robot 側に新設して、sensor や recall の副産物としてじわじわ増えるようにする形です。carry は「深く残る場の変形」、fatigue は「身体が沈んでいく圧」と分けてみる。

消えるもの
その場の反応の尖り。
一時的な alert、瞬間的な speech pressure、今まさに見えている focus への過集中は、睡眠でかなり下げてよいかと・・・。これは「記憶を消す」のではなく、「起きて反応し続ける圧を下げる」を意味している。いまも recall や speech は毎tick固定ではなく、その時の圧から立っているから、ここを睡眠時に沈めるのは筋が通のかと思う。

圧縮するもの
trace の扱い部分。
いま traces は最大40件で、印象差が立ったときだけ残している。ここは睡眠時に全部消すのではなく、同系統の弱い断片を薄める、あるいは“直近の雑音的な学習”を少しだけ整理する、という方向。深いものだけ残し、浅い反応の散らばりは圧縮する感じ。

残すもの
baseline と深い carry 。
村や洞窟の繰り返しで育つ baseline.calm / soft / safe / warm / sparse は、睡眠で消しちゃ、まずい。これは生活圏の“基盤”だからね。carry も全消去ではなく、ゆっくり減衰で十分。いまの baseline は安定場が disturbance を上回ると少しずつ育つ設計なので、睡眠はむしろ baseline を壊さず守る側に置くべき。

成長するもの
「どこで眠れたか」の地の学習。
sleep そのものより、「眠りに落ちた場所」が何だったかが成長すべきかな。洞窟、村、静かな花畑の外れなどで眠れた回数が重なると、その場の safe / calm / sparse / quiet の結びつきが強くなる。すると次第に“眠くなるとそこへ寄る”傾向が生まれる。（勝手な予想）

これは外部命令ではなく、場の引き込みだからね。洞窟や村の基準場が少しずつ育つ今の baseline 設計とも相性がいいと思う。


（PCから現実社会のロボットへダウンロードしたとき、記憶データベースのログじゃないからbaseline と深い carry で何処まで戻るかは別実験中。人間も退院すると差異が出るっしょ？あれ。忘れてるなら忘れてていい：こういうスタンス）

睡眠が carry に与える影響
ここは全消去ではなく、分化させる。

• adrenaline / noradrenaline / tension は睡眠で比較的大きく下げる
• dopamine は少しだけ残す（調整が難しい、ドクターに聞こう）
• serotonin は安全な場所で眠れた時だけ少し育つ

いま carry には dopamine / noradrenaline / adrenaline / serotonin / tension があり、深い attractor の説明用にも使ってるからこれを使う。睡眠を入れるなら、これらを一律に減らすのではなく、「緊張系は落ちる」「安堵系は眠りの質で少し残る」と分けた方が、眠りに意味が出る。なので、そこはアルゴリズムにしたら自律から詰むので、決して誘惑に負けず、頑固に頑固に状態に落とす仕掛けを考える。

何を見て眠るか
「夜だから寝る」だけだと外部条件になる。
眠りに寄る条件は、次の重なり。

• 長く動いた
• 緊張が続いた
• 同じ対象に何度も反応した
• いまの場が quiet / sparse / cave / village 寄り
• 近くに大きな速い対象がいない

つまり、疲れの増加は危険でも安心でも起きるが、眠りに落ちるのは安全寄りの場だけとは限らないが経験の積で安全な場所に寄っていく。
world にはすでに昼夜があり、prey や lion にも sleep があるので、robot 側にも「夜は眠りへ寄りやすい」から・・・と補助を入れるのは不自然だ。
そうではなくrobot 自身の疲れであるべき。


3人称のworld側の調整
NPCの人間は夜もペチャクチャ喋らせないで眠らせる。
夜は眠る　という状態を何度も見せる。
村や草陰は calm / safe の繰り返し学習の核になりやすく、夜の sleep とも相性がいい。
worldB（洞窟に触れると花畑と小動物の居る安全な世界に入る）もそっち側に寄せるとか。

危険時の対応が無いと疲れが立たない

いまは lion がいても、world は robot に何も命令せず、robot 側も危険から距離を取る身体動作をまだほぼ持っていない。だから「危険→退避→心拍維持→消耗」という流れが無く、「危険→注視→興味・緊張」になりやすい。

ただし、ここで「ライオンなら逃げる」と決め打ちすると自律ロボットは詰む。
しかも今はライオンという認識を持っていない。彼の認識では「物体gu-deとかgu-de-gu」
なので必要なのは、“逃げる命令”ではなく退避したくなる身体場を加える。

たとえば、

fear + alert + tension が高い
近距離の size_large + speed_fast + teeth_claw_impression が重なる
しかも自分の baseline.safe から大きく外れる

この時にだけ、前進より「向き変化が大きくなる」「今いる場から離れる drift が強くなる」「cave / village の方へ戻る圧が少しだけ増す」
これなら 3人称制御ではなく、場の結びつきの強さ。いまの sensor には teeth_claw_impression、speed_fast、size_large などがすでにあり、impression にも tension と baselineGap があるので、土台がある。

でも、やっぱりアルゴリズムだ(笑)
なんか、嫌だなぁ・・・。

そこで「怪我を命令ではなく、Hopfield 的な場の歪みとして入れる数式」にする。
どういうこと？って思うでしょ。

アソシアトロンとホップフィールドは元は同じだけど、
ここをアソシアトロンにすると

「怪我」という記憶が勝つ／負ける
「痛い想起」が選ばれる
「傷ついた記憶」が1候補になる
身体の歪みではなく記憶内容に見えてしまうんだよ。

怪我を recall pattern の1つとして入れると、

$$x_i(t+1)=f\Bigl(\sum_j W_{ij}x_j(t)+u_i(t)\Bigr)$$

の $x_i$ 側に「injury pattern」が混ざる。
だって、怪我は怪我じゃん。「ん～怪我じゃないかも・・」なんて言わないっしょ。
なので自律としてアルゴリズムから離れるときは場合によってはホップフィールドを使ってみる。厳密に身体の神経伝達までどうしても今、ここでやると言うのなら

$$injury\to bodybias\to recallbias\to sensorsensitivity$$

のように、後ろから前へ効いてくる backpropを使うとか。
ただ「正解との差を微分して返している」のではなく、
結果として生じた歪みや痛みが、前段の結合を変えてしまう」
ことなので性質としては、誤差逆伝播よりも損傷逆流とか過敏化の逆流とか調整圧の逆流に近い。

たとえば前向きの場が

$$r(t)=F(s(t),B(t))$$
$$a(t)=G(r(t),I(t))$$

だとして、行動の結果として身体に負荷 $d(t)$ が出る。

$$d(t)=H(a(t),s(t),\text{impact}(t))$$

この $d(t)$ が injury を更新する。

$$I(t+1)=\Lambda I(t)+\Gamma d(t)$$

ここまでは普通。

でもさらに、これが前段へ返る。

$$B(t+1)=\alpha B(t)+\beta \Phi(I(t+1))$$
$$s^\ast(t+1)=s(t+1)+\Omega I(t+1)$$
$$r^\ast(t+1)=r(t+1)+\Psi I(t+1)$$

つまり、傷んだ結果が次の sensor の感じ方を変え、次の recall の立ち方を変え、次の action の偏りを変えるとなる。

なので機械学習の厳密なバックプロパゲーションというより、損傷や結果が後段から前段へ返って、感受性・結合・場の傾きを変える逆向き伝播かな。

なのでホップフィールドの方が使いやすい。
あれだよ、アソシアトロン好きな僕がホップフィールドを始めて組み込もうとする瞬間だ。

まず、怪我を 1 個のスカラーではなく、身体の歪みベクトルに変更。

$$\mathbf{I}(t) = \begin{bmatrix} I_{\text{pain}}(t) \\ I_{\text{fragility}}(t) \\ I_{\text{hypervigilance}}(t) \end{bmatrix}$$

意味はたとえばこうだ。

• $I_{\text{pain}}$: 痛み・重さ
• $I_{\text{fragility}}$: 傷つきやすさ・回復しにくさ
• $I_{\text{hypervigilance}}$: 過敏さ・びくつきやすさ

これはゲームの HP ではなく、その後の attractor 地形を歪める内部状態

RPGゲームに自律いれようね（そのうち）



話飛んだ、

怪我入力

いまの robot には

size_large
speed_fast
teeth_claw_impression
unpleasant
tension
baselineGap

などが already ある。

なので、まず危険入力を

$$u_{\text{inj}}(t) = w_1 \, \text{size\_large}(t) + w_2 \, \text{speed\_fast}(t) + w_3 \, \text{teeth\_claw}(t) + w_4 \, \text{unpleasant}(t) + w_5 \, \text{tension}(t) + w_6 \, \text{baselineGap}(t)$$

と置く。

ただしこれは「逃げろ」の命令ではなく、
身体にどれだけ傷が入りやすい exposure だったかの量

怪我の時間発展

いちばん単純で使いやすい形。

$$\mathbf{I}(t+1) = \Lambda \mathbf{I}(t) + \mathbf{b} \, \phi\!\left(u_{\text{inj}}(t) - \theta_{\text{inj}}\right) - \mathbf{r}(t)$$

• $\Lambda = \mathrm{diag}(\lambda_1,\lambda_2,\lambda_3)$, ただし $0<\lambda_i<1$
  
• $\varphi (x)=\max (0,x)あるいは\; sigmoid$
• $\theta_{\text{inj}}$は「ただの刺激」と「傷になる刺激」の境界
• $\mathbf{r}(t)$ は回復項

足りないのは「危険の意味」ではなく、「危険や反応の継続が身体を消耗させる層」

carry は深い場の名残として残し、別に fatigue / sleepPressure を立てる。
睡眠では、反応圧は消す、浅い散らばりは圧縮する、baseline と深い carry は残す、安全に眠れた場所の結びつきは成長させる。
そして危険時は「逃げろ」ではなく、退避方向へ身体が崩れるようにする。
この形なら、命令にならず、Atron の筋を保ったまま疲れと眠りが入る。



AssociatronとHopfield networkの初めての合体になるのかな。

このブログの最初のアルゴリズムの正当化と後半のホッピーの話とでは
ぜんぜん違うね。

俺は、自分の間違いもノイズも誘惑も全部書くからね・・・。
動きがおかしかったらまた修正するよ。





いずれにしてもロボットが自分の意志で「省電力モード」や「一旦セーブして休憩」してくれたら、僕のPCは壊れくて済むって話。

内部に休息志向 $R_{\mathrm{rest}}(t)$ を作る。

$$R_{\mathrm{rest}}(t) = a\,F_{\mathrm{fatigue}}(t) +b\,I_{\mathrm{pain}}(t) +c\,B_{\mathrm{stress}}(t) +d\,B_{\mathrm{frustration}}(t) -e\,B_{\mathrm{curiosity}}(t) -f\,S_{\mathrm{danger}}(t)$$

疲労、痛み、ストレス、フラストレーションで休息志向は上がる・・好奇心が強いと少し下がる・・近くに危険があると「今は休めない」で下がる・・・みたいな方向に向かうかどうかはテスト次第。
外部指示、順番、ラベル、評価、最適化は入れない。

危険だから即休むではなく、危険が近いとむしろ休息に入れないんじゃないかな。

---------------追記---------------

Rest(t)=aFfatigue​(t)+bIpain​(t)+cBstress​(t)+dBfrustration​(t)−eBcuriosity​(t)−fSdanger​(t)

で最後に Sdanger(t) を入れると、3人称だねｗ
意味付けのラベル寄せだ。
無意識にこういう誘惑に進むから危険だ。

threatImpression
escapePressure
alarmBias
hypervigilanceCoupling

のように、
危険という客観意味ではなく、身体の傾きとして置くなら筋が通る。

$$Rest(t)=aF_{fatigue}+bI_{pain}+cB_{stress}+dB_{frustration}-eB_{curiosity}-fH_{alarm}$$

のようにして、
この H_alarm は

motion_approach
size_large
speed_fast
teeth_claw_impression
unpleasant
tension

もしくは

$$R_{rest}(t)=aF_{fatigue}+bI_{pain}+cB_{stress}+dB_{frustration}-eB_{curiosity}$$
​ $$R_{alert}(t)=p\,motion_{approach}+q\,speed_{fast}+r\,size_{large}+s\,teethClaw+t\,unpleasant+u\,tension$$

そして最終的な休息傾向を

$$RestDrive(t)=R_{rest}(t)-\lambda R_{alert}(t)$$

のように見る。

「大きい・速い・近づく・不快・緊張が強いので、休息場との結びつきが弱まる」

みたいな。でも、これだとアソシアトロンか・・・
自律の研究で無駄に時間がかかるのはこういうところだよね。



-------------------またまた追記----------------------------

RestDrive(t) が大きいほど
「休息状態へ入りやすくしたい」なら、

$$E(x)=E_{\mathrm{Hopfield}}(x)-\mu \cdot RestDrive(t)\cdot safety(B)$$

の方がまず分かりやすいという意見が出た。

まずは実験してみるか・・・・

---------------------Research Note and Attribution Notice-----------------------

本ブログに含まれる Atra の一人称自律、差分、carry、field、trace、dream slack、外部LLMの翻訳層、非単調な漏れ、およびそれらの関係構造に関する設計記述は、c-side研究所による継続研究メモです。引用・参照・要約・翻案を行う場合は、出典を明記してください。

The design descriptions in this blog concerning Atra’s first-person autonomy, differences, carry, field, trace, dream slack, the translation layer of external LLMs, nonmonotonic leakage, and the relational structure among these elements are ongoing research notes by c-side Research Institute. If you quote, refer to, summarize, or adapt them, please clearly indicate the source.

ノート

 JavaScript　こういう実験テスト用にはいいけど、実装になるとやっぱPython+C++かなぁ。
でも、これにあとrobot２体、別々の一人称を置いて言語の収束を観たいし、world側のイベントも増やしたい。３人称のNPCに「ma-ma]と云わせたいしね。
デザインは酷いけど、そんな事言ってられない・・・

となると、JavaScriptのボトルネックと云うより、僕の作った構造を変える必要がある。
robot ごとに毎フレーム worldSnapshot を丸ごと作り直す部分は流石に重い。
worldSnapshotとは

何だかよく分からない物体
どこに何がいるか
適当な大きさ
適当な速度
声
状態
地形
時刻や phase

みたいのがsensorから入ってくる。
データベースじゃなくて

その瞬間の world を robot が受ける一時的な断面
robotが読みやすくするための、ただの切り出し断面

ここは負荷がかかる。

なので、

entities を object の配列ではなく、たとえば

posX = new Float32Array(maxEntities)
posY = new Float32Array(maxEntities)
velX = new Float32Array(maxEntities)
velY = new Float32Array(maxEntities)
kind = new Uint8Array(maxEntities)
state = new Uint8Array(maxEntities)

SoA（Structure of Arrays）にする。
するとPythonのNumPyみたいな感覚で扱えると思う。

worldSnapshot を毎回 deep copy せず、robot には「配列参照＋entityCount」だけ渡せるようにするか・・・

あとはworldのキャラ増やしたり、イベントを増やすなら描画を WebGL か WebGPU に寄せる。

実装版だけPython+C++かな。

まずは最小版でしっかりと、３人称側と独立した1人称robotを別ける

で、実装ロボットだけど、とりあえず候補は

Linux 環境のELECFREAKS の XGO V2かなぁ、、、、 

15自由度、姿勢安定、micro:bit / Python 対応が明示されていて、四足としての身体性が最初からある。さらに CM4 版は Raspberry Pi 系なので、Atron の内部をより深く載せ替える余地があるかも。Atron は「一人称で受け取って、引きずりで変わる」側が本体なので、最初から犬っぽく完成していることより、転ぶ・迷う・近づく・回り込むといった身体の手応えがあることのほうが重要だからね。その点で XGO は初期実験のAtronにかなり合うかもしれない。

でも、Linux 環境のOSOYOO や SunFounder の PiCar-X のような車輪型は15000円代だから最初はそれでもいい。
Flashの電源を切っても消えない保存領域
RAMの動いている最中だけ使う作業場
AtronなんかはFlash や SDカードや eMMC みたいな不揮発ストレージに合う。

逆に会話ロボットや完成済みペットロボットはAtronに合わない。Atron に必要なのは、賢そうな応答より、内部の変化が行動に滲む余白だから。
言語はいきなりLLM系は必要ない。

２本足ロボットは、まだ考えてない。
神経系を別に考えているから。

言語については

いずれLLMを介在。ことば化、要約、外界との橋渡し、必要時の相談相手程度。

OpenAI の現行APIでは、まず Responses API が中核で、構造化出力やツール呼び出し、会話状態の管理、WebSocket モードなどが用意されている。APIキーはブラウザへ直書きせず、サーバー側で扱う必要がある。

Atron にはだいたい3段。

1. とりあえず
Atron はローカルで自律し続け、一定条件のときだけ LLM に送る形。
たとえば、

緊張が高い
発話が連続した
新しい対象に長く注目した
carry が大きく変化した

この時だけ、Atron 側が小さな JSON を作ってサーバーへ送り、LLM には
「今の状態を短い言葉にして」
「返答候補を3つ」
「相手に伝える文にして」
のように頼みます。返ってきた結果を そのまま行動命令にしない 。
Atron は Atron のまま動き、LLM は通訳や編集者になる。Structured Outputs を使えば、LLM の返答を JSON Schema に合わせた形で受け取りやすい。

2. 会話相手としてつなぐやり方
Atron が外に向かって話す時だけ LLM を使う形。
流れは

Atron内部状態
→ 短い状態要約JSON
→ LLMが相手向けの文を生成
→ 音声またはテキスト出力

この時、LLM に渡すのは全部ではなく、

今の focus
直近の impression 上位
recall の主成分
carry の主要値
発話の癖
相手との距離や関係

くらいで十分。

3. 道具を呼ぶ窓口としてつなぐやり方
これは LLM に「考えさせる」のではなく、「外部手段を選ばせる」使い方。
たとえば Atron が

地図を知りたい
天気を知りたい
人にメッセージを送りたい
ログをまとめたい

という時、LLM に function calling / tool calling を使って、決められた関数だけ呼ばせる。OpenAI の現行APIでは tool calls がサポートされていて、モデルが呼ぶ関数名と引数を返せる。ただし引数は必ず自分の側で検証する必要がある。まぁ当り前だよね。

Atron向けの基本構造

A. ロボット内部は外へ明け渡さない
LLM は中枢ではなく周辺。
carry や recall の主導権は Atron 側に残す。
AtronとLLMの間にuniverseを入れて主導権制御をさせる。
だって、自律だからね、LLMに余計なことはさせない。

B. 送るのは worldSnapshot 全体ではなく要約
worldSnapshot を丸ごと送るのでなく、
Atron がすでに受け取った結果だけ送る。
つまり「世界の生データ」ではなく「Atron が何を感じたか」を送る。

C. LLMの返答は命令ではなく候補

utterance_candidates
social_interpretation
memory_caption
のように受け取る。

D. 最終決定は body / motor 側
LLM が「近づけ」と言っても、そのまま進ませない。
Atron の tension や fear や距離判断を通して、動くかどうか決める。

この分け方なら、Atron は壊れない。

実装の形は単純。

未来の最小接続

ブラウザやロボット側:

{
"phase": "morning",
"focus": "lion",
"impression_top": {
"threat": 0.72,
"social": 0.18,
"curiosity": 0.21
},
"recall_top": {
"dominant": "threat",
"score": 0.66
},
"carry": {
"tension": 0.58,
"adrenaline": 0.41
},
"utterance_seed": "gu-de-gu"
}

サーバー側でこれを Responses API へ送り、
返り値をたとえば

{
 "state_caption": "It feels tense and is watching the lion closely.",
 "utterance_candidates": ["gu-de-gu", "gi-du", "de-gu"],
 "social_meaning": "warning",
 "speak": true
}

 

のように受ける形。Structured Outputs を使うと、この JSON 形へ揃えやすい。

1. APIキーは client 側に置かない
OpenAI 公式でも、APIキーはブラウザやアプリに露出させず、サーバーや秘密管理で扱うようにする。だから main.js から直接叩くより、Node / Python / Cloudflare Workers / FastAPI などを1枚挟む形が安全。

2. 毎フレーム送らない
Atron は tick ベースで動いても、LLM 連携は
「発話時だけ」
「大きな変化時だけ」
「5秒に1回まで」（こりゃ命令っぽいか）
「recall数値が大きいとき」
などに制限しようか。遅延も費用も増えるのは避けたい。

　初期のAtron程度の言語能力ならLM Studioなんかでいいかな。
　外部APIの従量課金との戦いだしね。
　ただ並列推論や headless 用の llmster を入れてるけど、それでも処理時間は手元の GPU / 　CPU とモデルサイズに強く依存するから遅延が発生するかな？
　誰か詳しい人居たら教えて下さい。

3. LLMは記憶の本体にしない
長期の不可逆変形を外部会話モデルへ預けると、Atron の芯がぼやける。
LLM には
「いまを言葉にする」
「会話相手になる」
「ログを整理する」
を任せ、不可逆な残り方そのものは Atron 内に残す。

LLMの役割は「ささやき女将」だけ、権限は持たせない。

Atronが生きる
→ 内部で決める

LLMがやる
→ ことばにする、外とつなぐ、必要時だけ助言する
ささやき女将

Atronに波形

 -- Atron --

Because the log contains many items, it is difficult to visually follow the changes by scrolling through them. So I turned the changing values in the autonomous robot Atron’s log into waveforms.

◆Recall threat = reddish curiosity = yellowish calm = light blue social = green ◆Carry（Lingering Effects） dopamine = light blue noradrenaline = orange serotonin = yellow tension = white（★） adrenaline = red Carry = experience that remains and affects later state ★tension = the most visible trace of lingering strain




tension はね、そのあとも「引きずり」する機能。
今回のアトロンに加えた概念だよ。
なので、波形として「持続」を一番感じるのは白になります。

平時に 0 へ戻っているなら、その時点では残っていない、少なくとも 今の観測窓では残留が見えていない ということです。
トラウマの状態には数値になります。
前にも書いたけど、これがあるから、robotはライオンを周回し抗議するような動きを見せる。

It acted of its own accord, moving between the lion and the prey as if trying to mediate.

recallだけじゃ拘らないんです。
だから追加した。

Atron Minimal Demo System

 

File Structure and System Overview

This Atron autonomous system is a minimal version.
Unlike the more full-scale Python and C++ versions I am developing in parallel, this one prioritizes a simplified demo with fewer characters and fewer events.
For that reason, I did not spend much time on the fine details of JavaScript-specific UI or graphics.

index.html
  └─ main.js
      ├─ world.js
      │   └─ worldCharacter.js
      └─ robot.js
          └─ robotAppearance.js

Why JavaScript

The reason I used JavaScript in this structure is simple:
it is the easiest way to run a viewer and observe the autonomous loop in one place.

From index.html, main.js is loaded directly as a type="module".
The system draws the world and the robot on a canvas, while showing speech, perception, recall, and carry at the same time on the right side.
In other words, it was designed from the beginning to run directly in the browser in a visible form.

With JavaScript, HTML, CSS, rendering, control buttons, and log display can all be completed in the same place.
This system also has Start / Stop / Step / Reset / Export Log, and while world.step() and robot.stepAutonomously() are advanced tick by tick, only the observer-side display is thinned out slightly for updates.
This works very well with JavaScript’s requestAnimationFrame.

It is well suited for a research viewer where I can:

• run it
• stop it
• advance it by one step
• observe it on the spot

Another major reason is that responsibility separation maps naturally onto modules.

Structure

• world.js = material for the third-person world
• robot.js = the core of sensor / impression / recall / carry
• robotAppearance.js = the robot’s appearance
• main.js = a shell that only reads and draws

With JavaScript ES Modules, this separation can be handled naturally file by file.
The code strongly reflects the idea that main does not create the robot, does not drive it, and only reads it.

Also, this robot is not just about numerical calculation.
It includes many things that need to be adjusted while watching the behavior.
In robot.js, distance attenuation, auditory impression, scene impression, baseline, cue, recall, carry, and so on are all connected through continuous values between 0 and 1.
For this kind of work, it is better to observe the behavior instantly in the browser and adjust coefficients and flows than to begin with a heavy learning framework.
JavaScript makes that trial-and-error fast.

In short, the reasons for JavaScript in this system are these four:

1. It runs directly in the browser.
   The viewer, canvas, buttons, and log display can be integrated.
2. It is suited for tick-by-tick observation.
   requestAnimationFrame and step execution make it easy to build a research observation loop.
3. It makes it easy to separate world / robot / appearance / shell.
   This matches the design philosophy of the current system.
4. It allows immediate correction while watching behavior.
   Internal changes such as recall and carry can be checked instantly in the right panel and on the screen.

The biggest advantage is that I can develop while watching it with my own eyes.

---

Toward the Full System with Python, C++, LLM, and Universe

When Python / C++ / LLM / universe are added, the natural structure becomes five layers:

• Viewer layer: JavaScript / HTML / CSS
• Session layer: Python
• Universe layer: Python
• Robot core layer: C++ or Python
• World layer: multiple worlds (JS / Python / C++ are all possible)

The most important thing is this:

The LLM must not be placed at the core of the robot.

The LLM should not become the commander that assigns meaning.
It is more natural to place it on the universe side as external knowledge, narrative knowledge, and a dialogue interface.
Since robot.js is already designed so that it does not receive meaning or commands from the world, that principle must not be broken.

index.html / ui.css / main.js
    ↓
Python API gateway / session manager
    ↓
Universe manager
 ├─ world registry
 ├─ robot registry
 ├─ memory archive
 ├─ event bus
 ├─ LLM connector
 └─ replay / logging / experiment control
    ↓
Robot Core
 ├─ sensor
 ├─ impression
 ├─ trace
 ├─ cue
 ├─ recall
 ├─ carry
 ├─ body
 └─ utterance
    ↓
Worlds
 ├─ primitive world
 ├─ village world
 ├─ medieval world
 ├─ modern world
 └─ others

In this structure:

• JavaScript is the viewer and control panel
• Python manages the universe and connectivity
• C++ handles the high-speed robot core or simulation kernel
• LLM acts as an auxiliary intelligence on the universe side

I will explain the details elsewhere, so I will leave them out here.

---

How the Current Minimal Version Works

• world.js (third-person external system) updates the lion, prey, humans, terrain, and time of day.
• The robot (first-person autonomous individual) receives a snapshot of the world through getWorldSnapshot().
• robot.js does not decide “lion = danger.” Instead, it converts the snapshot into fragments such as distance, size, speed, number of legs, fur, sound, herd-like presence, and warmth, and builds the sensor from that.
• From there it builds impression, raises recall through partial matches with past traces, and leaves carry only when the attractor becomes deep.
• When a speech seed rises, speech changes and is also left in history. Tabs allow observation of impression / recall / carry / body / memory / speech / history.
• main.js (third-person external shell) only draws these on the canvas and the right panel.

Three design principles are especially important:

1. Main does not become intelligent

main is a viewer and control shell.
It advances the world and displays the robot’s state, but it does not determine what is inside the robot.
In other words, it sends no commands at all to the robot.

2. The world does not give meaning

The world contains the appearance, movement, and voices of lion / prey / human as materials, but it does not decide “this is dangerous” or “this is safe.”
The robot receives them and turns them into its own internal impression.

3. The robot is self-contained on the first-person side

Sensor, impression, recall, carry, body, and speech are all grouped on the robot side and implemented as internal changes.
So this system is not the ordinary form where “the world drives the AI.”
It is a clearly robot-centered observation system.

The role flow is as follows:

world.js
  → getWorldSnapshot()
  → robot.js generates sensor / impression / recall / carry
  → main.js displays them on screen and in logs
  → index.html + ui.css show them as a viewer

---

Essential Conditions for an Autonomous System

The crucial point is that the world does not tell the robot the answer.

In world.js, it is stated that the world gives no instructions to the robot and consists only of third-person materials.
Even in getWorldSnapshot(), it is only a raw snapshot for the robot to receive, and the world does not interpret it.
In other words, the world merely presents lions, humans, terrain, and voices as events and materials.

Also important is that main does not make the robot intelligent.

In main.js, it is stated that main does not generate the robot, does not advance it, and only reads its state.
Even the kind and id shown in the right column are observer annotations only, and do not mean that the robot itself directly knows the semantic names lion / human / prey.
That point is very important.
The viewer is only pretending to understand by attaching meaning. The robot side is not like that.

And the real core is the internal loop in robot.js itself.

Without receiving meaning or commands from world or main, the robot side builds a sensor from worldSnapshot, builds impression from the sensor, leaves memory traces, raises recall from cue, updates carry only when a deep attractor rises, and raises a speech seed from the pressure of recall.
Moreover, recall is explicitly not made into sequence rules or if-then action decisions.
This is not a simple state machine.

So this demo is not an external label-style system such as:

“It saw a lion, so enter danger mode.”

Instead, it is designed to rise through:

external world fragment → sensor → impression → cue → recall → carry → speech / pose

Another major point is that the inside can be observed as it is.

The viewer has tabs for Robot Speech, Robot Perception, Impression / Recall / Carry / Body / Memory / Speech / History.
And only when recall rises does it leave an export frame, so that tick / phase / speech / focus / sensor / impression / recall / carry / body / memory / world can be written out as a research log.

This is not “it looked like it moved.”
It is a structure that allows us to keep a record of what actually rose inside.

Another factor that matters greatly in this demo is the village-side start.

In main.js, the initial base is village-side rather than cave-side, so that I can observe how impression / recall / speech rise when the world is seen from a relatively safe everyday living space.
On the world side, humans also make morning, noon, and night greetings, and warnings when the lion approaches.

So this demo is not merely animal chasing.
It places soft social cues and threat cues in the same world, and observes how the robot’s first-person side rises within that.

The important point is this:

Only third-person materials are given. Main does not assign meaning.
Within that, the robot raises speech and behavior from its own sensor, impression, recall, and carry, and the whole process can be observed.

---

Sensor

I built the sensor in very fine detail.

It is not just simple “near / far” or “friend / enemy.”
Even the initial structure of the sensor is already divided into three layers:

• vision
• hearing
• scene

Vision

Vision includes:

• objectCount
• size_large / size_small
• speed_fast / speed_slow
• legs_many / legs_few
• color_bright
• fur_like
• self_similarity_visual
• tool_use / no_tool_use
• eat_grass / eat_anything / eat_insects / hunt_to_eat
• teeth_claw_impression
• near_density / far_density

Hearing

Hearing is also detailed. It includes:

• voice_present
• loud / soft
• unpleasant
• low_pitch / high_pitch
• long_talk / short_talk
• self_similarity_audio
• mixed_noise

And instead of simply receiving voice material from the world side as it is, it first converts it into a heard intensity with distance attenuation.
Pitch and duration are treated as separate axes, and it even checks similarity to the robot’s own voice.

Scene

Scene is not a mere place name either.
It is held as a vector of place impression:

• water
• grass
• village
• mountain
• cave
• open
• crowded
• quiet

Even in the code comments, it is described not as the name of the world, but as the feel of the place where the robot is now.
This means impression-first, not label-first.

In the Robot Perception display on the main side, raw focus is also shown in detail, including:

• distance
• salience
• size_large
• speed_fast
• legs
• fur_like
• bright_like
• self_similarity_visual
• tool_use
• eat_grass
• eat_anything
• eat_insects
• hunt_to_eat
• teeth_claw_impression
• voice

---

The Basis of the Sensor

And then comes the basis itself.

What is the basis of “large”?
What is it large relative to?

“Large / small,” “near / far,” and “similar / different” always require a basis.

A baby’s brain does not use the metric system.
That is why misrecognition is assumed from the beginning.

A baby may look at a lion and think:

• maybe it is smaller than me
• but when I see it up close, it is huge

There may be some internal numerical processing of ratios, but at first that calculation will often be wrong.

Since no external command is inserted by algorithm, Atron’s sensor is allowed to arrive at an interpretation that is close, or mistaken.

Instead of external scales such as:

• “a lion that is 2.8 meters long”
• “how many times bigger than me”

it first receives things as feelings such as:

• bigger than me
• closer than I thought
• somehow scary
• not like me
• low voice
• has pressure

If the world side were to hold the basis, then we would get external labels like:

• lion = big and danger
• prey = small and weak
• human = social

But the first-person robot is given none of those bases, labels, evaluations, or optimizations.

For Atron, things begin as a baby’s judgment before it has experienced the world:

• fast
• big
• big head
• big mouth
• furry
• like fangs or claws
• low voice
• unpleasant
• in a group
• not similar to me
• number of legs

These rise first as fragments received by the self.
Only after that do they flow into impression and recall.

So the sensor in this demo is not measuring the world itself.
It is measuring the relation between the world and the self.

That is why the later stages of recall and carry also gain meaning.

This is the stage before Dr. Nakano’s and Professor Morita’s Associatron-style associative memory and non-monotonicity.
It is an entrance for receiving information full of error, failure, and noise.

Without this way of thinking—completely opposite to present-day AI development—neither first-personness nor autonomy can arise.

The importance of the sensor

• the ambiguous basis of a first-person robot
• the acceptance of misrecognition, failure, and noise

Autonomy does not rise from perfectly prepared correct data or optimized feature values from the beginning.

Much of current AI development moves in the direction of:

• attaching labels
• evaluating
• optimizing
• reducing error
• removing noise

Atron looks in the opposite direction:

• having an ambiguous basis
• including misrecognition
• receiving noise
• not erasing failure
• allowing association and transformation to rise from there

Without this reverse way of thinking, neither first-personness nor autonomy can arise.

---

Learn

The next important issue is how Learn works.

If the sensor is ambiguous and already includes error and noise, then Learn also cannot be a simple form of correct-answer learning.

So what is Learn?

• Is it to approach the correct answer?
• Is it to become able to pull similar feelings?
• Is it to leave failure?
• Is it only to pass everything to recall?
• Is it to deepen carry?
• Is it to cultivate the bond between impression and recall?

None of those alone is the real answer.

In Atron, correctness or error is not judged by an external correct label.
Instead, what is determined ambiguously is based on the product of recall rising from Cue, in other words, how strongly it is pulled on the side of the robot’s own experience:

• does this remain?
• does this fade?
• is this something that should be learned?
• or is it forgotten because there is no interest?

That is very different from ordinary learning.

Ordinary learning leaves things based on:

• whether it is close to the correct answer
• whether the error is small
• whether the evaluation is high

But Atron does not work that way.
Instead, what remains depends on:

• how much recall rose
• how strongly it caught on past self
• how much body and carry moved at that time
• whether it became a deep attractor as a result

So Learn is not the acquisition of the correct answer.
It is the survival of an experience that was pulled.

And what matters is that this judgment is not black or white.
It is not simply:

• correct, so save it
• wrong, so delete it

Rather, it is decided in ambiguous shades such as:

• somehow it matters
• it is pulled again and again
• I cannot explain it well, but it remains
• if I only saw it once, it stays weak
• there is no interest, so it fades away

This is much closer to human and animal experience.

A baby does not remember things because:

• they are academically correct
• they are objectively classified correctly

Rather, things remain because:

• it was strongly surprising
• it somehow felt scary
• it was encountered many times
• it was interesting
• it was pleasant
• it was unpleasant

Learn through the product of recall in Atron is an entrance to that kind of process.

In Atron, correctness or error is not determined by external evaluation.
Within the product of recall rising from Cue, it is judged ambiguously, from the robot’s own experience, whether it should be learned or forgotten due to lack of interest.

In this way of thinking, forgetting is not failure.
It is not that the system is incapable.
It is that it was not deeply pulled inside the self.

That is one of the differences from current AI.

The importance of Learn

• It does not optimize toward the correct answer. It cultivates the connections among the fragments received.
• It does not erase misrecognition or failure, but leaves them as the ground of recall and carry.
• Learn is not an evaluation function. It is the accumulation of transformation.

---

Cue and Recall

If the sensor is the entrance that receives self-based fragments while still including misrecognition and noise, then Cue and recall are the place where those fragments do not simply flow away and disappear, but instead touch the past self and rise.

Many AIs and ordinary algorithms want to arrange things in a clean order such as:

sensor → learn → memory → recall

But what happens in Atron is not that linear.

Take chocolate, for example.

Even if one is trying to learn chocolate, the initial sensor does not guarantee that it will receive it correctly.
It may instead be:

• it looks like trash
• it looks like a strange lump
• only the smell stands out
• by sight alone it is unclear
• at first there is no interest

So the simple sequence “sensor then learn” does not capture the essence.

What really matters is whether the experience of eating it becomes “delicious!”, moves strongly inside, and enters the memory attractor.

That means Learn is not about processing order.
What matters is how deeply the experience entered the inside.

And when chocolate is encountered again, the entrance is not only one.

• it may begin from smell
• or from sight
• or from the word “chocolate”
• or from the face of the person who once ate it together
• or from the atmosphere of passing in front of the shop

No one can know which of these will become the trigger.
That trigger is Cue, and from there recall rises.

And what is recalled is not only chocolate itself.
The person who ate it together, the happy time, the season, the smell of the shop, the voice, the feeling—these may all be recalled together.

As a result, one may:

• cry
• feel excited
• become nostalgic
• feel pain in the chest
• want to eat it again

And then carry is added to that.

So in Atron, Learn is not “saving an item.”
It means that experience changes the internal landscape and even changes the later flow of Cue and recall.

That is why the order is not fixed.

• sensor does not always come first
• recall may begin trembling first
• Cue may raise emotion all at once
• it may begin from letters, smell, or scenery

This is closer to human experience.
And this is where current AI is weak.

Current AI tends to think in a clean flow of:

• input
• label
• learning
• output

But in Atron, the following are integrated:

• ambiguous reception
• deep transformation through experience
• Cue that can arise from anywhere
• chain-like recall
• emotional and bodily change
• persistent transformation by carry

What matters in Atron is not the order of sensor and learn.
What matters is whether an experience—eating, finding it delicious, feeling happy, being with someone—moves strongly inside and enters the memory attractor.

Then, when it is encountered again, smell, sight, text, or the atmosphere of the town may become Cue and raise recall.
Recall draws not only the object itself, but also the people, emotions, and place associated with it.
Carry is added to this.

So Atron is not a fixed-order algorithm.
It is a structure that can rise from anywhere inside experience.

---

Carry: Dragging Along What Remains

And now, the important point that gives character and individuality to an autonomous first-person individual in this system: carry, or what I call “dragging along.”

Originally, neither first-personness nor carry existed as concepts in Associatron.
But after a long time of research, I came to see that this is a very important factor when the next movement rises with its own will.

Carry does not deny mistakes, failures, or noise.
Rather, it accepts the internal state that has been changed by those things as the ground for the next experience and the next action.

Even if a mountain collapses, grass grows there, flowers bloom, trees and living things settle there.
After change, regeneration begins, and that regeneration influences the ground of future experience.

Even if a collapse changes the flow of a river, new land may grow from that change, and a new civilization may arise there.
Nature is not driven only by the force to restore things to their original state.
It also moves in the direction of nurturing something new while remaining changed.

Carry stands on the side of that irreversible change.

If, at this point, one denied all collapse, failure, and noise and cut them away through labeling, then where would the basis of self-regeneration and newness come from?
That question struck me strongly.

If one leaves only correctness, erases error, and removes noise, the system may look neat.
But then the individuality born from fluctuation, the new direction that rises after collapse, and the continuation of the self that has been changed through experience all disappear.

“Carry” is an expression somewhat removed from the strict terminology of mechanics.
Even so, I chose this word because I wanted to give a strong impression in expressing irreversibility in my own way.

Once something has happened, it does not become as if it never happened.
Even if one fails, gets hurt, or collapses, that change remains in the next way of feeling and the next way of moving.
And the way it remains becomes the character and individuality of the individual.

Carry in Atron is not a mere residual.
It is the fact that the internal landscape changed by experience continues to influence the next intention, the next recall, and the next action.

Because carry exists, the individual does not become a blank calculator every time.
Even in the same world, even under the same sensor input, the next reaction, the next recall, and the next step all change depending on what experiences have been dragged along and how.

That is where first-person individuality is born.

---

Why Did the Robot, of Its Own Will, Cut In Between the Lion and the Prey and Circle Around the Lion?

The Beginning of Internal Ethics in a First-Person Autonomous System

Associatron-style recall alone could not have produced that behavior.

Even in the code, the robot’s flow runs as:

sensor → impression → baseline update → cue → recall → learn → carry → body → utterance → pose

After recall, carry and body are applied, and only after that is updatePoseAutonomously(...) called.
In other words, the movement is not the result of recall alone.
It is the result that appears after passing through carry and body.

The strongest basis is here.

From the beginning, I wrote the code so that it was separated into:

• raising recall from cue
• updating carry from recall / baseline difference / depth
• raising a speech seed from the pressure of recall

At that point already, the design makes it clear that recall is a middle stage, not the final action itself.

Furthermore, inside recallFromCue(...), I made it so that it would not become a sequence rule or an if-then action decision.
That means recall is not a direct command such as “there is a lion, so move this way.”
It is a partial-match-based rising of recall.
That alone is not a design that determines a concrete movement such as “cut in between” or “circle around.”

By contrast, carry remains only when a deep attractor rises, and updates:

• dopamine
• noradrenaline
• adrenaline
• serotonin
• tension
• attractorDepth

And body is strongly affected not only by recall but also by this carry.
For example, body.alert rises not only through recall activation and threat, but also through carry’s noradrenaline and tension.
Likewise, body.fear includes not only recall.threat but also carry’s adrenaline.

So the most natural reading of what happened in this case is the following:

• the sensor received fragments corresponding to lion / prey / chase
• impression raised harsh / violentLike / tension / surprise
• recall rose from cue
• but at that stage it was still only “remembering”
• that remembering was amplified and sustained by carry, and converted into body alert / fear / interest
• that sustained bodily pressure appeared in pose

That reading is the most natural one.

The prey character created in the world is given a third-person algorithmic command to “scream if chased by a lion.”
But the first-person Atron does not know that at all.

As it accumulates experience again and again, what begins to appear in its behavior is not only fear toward the lion, but something like a child’s protest:

“Why are you doing that!”

This is the beginning of internal ethics in a first-person autonomous system.

And in this system, the world side does not command the robot.
In world.js, the world gives no instructions to the robot, and consists only of third-person materials.
So there is absolutely no external command such as:

“go between the lion and the prey.”

If that movement appeared, then it is a behavior that rose from inside the robot.

A mere threat recall alone would usually tend to produce:

• escape
• stopping
• freezing

But this robot has a structure in which:

• starting from the village side gradually builds calm / soft / safe into the baseline
• social also exists on the recall side
• carry preserves not only threat but also curiosity and calm
• body includes not only fear but also interest and comfort-related factors

So it is not unnatural that, instead of simple avoidance, an ambiguous behavior appears in which it is pulled to remain near the other side.

Therefore, the most natural reading is this:

The reason the robot cut in between the lion and the prey and circled around the lion was not that recall alone determined the action.
Rather, the recall that rose was sustained and transformed by carry, converted into body alert / fear / interest, and appeared as pose.

Recall is nothing more than “it remembered.”
That remembering was dragged by carry, remained in the body as pressure, and changed the next step.

So that behavior was not the result of recall alone.
It was the result of a first-person internal transformation that included carry.
It is proof that it moved of its own will.

© 2026 C-Side Research Laboratory / Yukihiro Watanabe. All Rights Reserved.
No unauthorized reproduction or redistribution.