オブジェクトQが所属するオブジェクト，つまり，オブジェクトが接続しているか，ないしリスト/チェーン接続しているようなオブジェクトをQの親オブジェクトPと呼ぶことにしよう．オブジェクトQは通常親オブジェクトPによって生成され，Pによって削除される．
チェーンとは同じ番号のスロットに格納されたリンクを使って直列に連結されたオブジェクトの集合を言う※．チェーンを構成するために用いるリンクには「接続」と「参照」がある．接続リンクは双方向リンクで親オブジェクトと子オブジェクトの親子関係を確立するために用いる．参照リンクはさまざまな用途に用いられる単方向リンクで参照先オブジェクトはそのオブジェクトを参照するリンクの個数（参照カウント）は知っているが，どこから参照されているかを知ることはできない．
※グラフ理論で全順序集合を意味する「チェーン」とは意義が異なる
このようなチェーンの中で特に「接続」によって繋がったチェーンを「リスト」と呼ぶ※．スロットゼロはリストを構成するためにのみ用いる専用のスロットである．リストは通常「リストクラス」に属する親オブジェクトによって管理される．チェーンの中で終端が始端にリンクして閉路を構成するようなものを特に「リング」と呼ぶことがある．
※もちろんこれは，プログラミング言語LISPの「リスト」とは関係ない
リストおよびチェーンは通常スロットを1個だけ使って構成されるが，2つ以上のスロットを用いて分岐のあるチェーンつまり，木（二分木/多分木）を構成することもある．リストはゼロスロットを専有するため，あるオブジェクトが複数のリストに所属することはできないが，拡張スロットを用いて2つまでのリストを限定的に用いることはできる．ゼルコバの木システムを構成するための機構部品はこれだけである．
オブジェクトが持っているスロットの個数を価数としてみよう．すべてのオブジェクトは親オブジェクトへのリンクを格納する「親スロット」と「スロットゼロ」を持っているので，少なくとも二価であると言える．ゼルコバの木システムのオブジェクトはすべてNODULEと呼ばれる基底クラスから派生したもので，NODULEは（拡張スロットなど特殊スロットを除外すれば）二価のオブジェクトである．NODULEは純粋仮想クラスで実装を持たないが，それから派生したnoduleはそのままあらゆる用途に使用可能な汎用オブジェクトである．
スロットの実体はオブジェクトへのリンクを格納しインデックスによってアクセスする配列だが，NODULEシステムの最大の特長はオブジェクトにアクセスするときの手段が，名前を持ったクラスメンバーへのアクセスという通常の方法と別に，スロット配列を使った無名オブジェクトへの一般的アクセスという方法があるという点にある．つまり，N個のオブジェクトを所有するオブジェクトをN＋2価の素子（モナド）として扱うことができる．スロット配列を使ったアクセスはNODULEないしnoduleの共通操作として完全に一般化されているので，アプリケーションのコードでは固有の動作部分を記述するだけでよい．
▲ZTシステム構成図7.ZELを#1 couplingで起動→終了してoperator deleteで参照カウントの残留が発生する 障害が起きているのはSIMPLENODE NODELISTの枝2からの参照が残っている
昨日の修正，blackflagの仕様変更がまだ収束していないためと思われる．この障害はアプリ終了→ CloseFamilyBase→ …SIMPLEGRAPH：Dispose→ …DATALIST::cancel→ LIST::deleteElement→ …nodule::operator deleteで起きている．LIST::deleteElementはまだ修正されておらず，dataCountDownが事後に実行されている．dataCountDownをdeleteの前に実行するという修正を「blackflagの論理逆転＠20201128」というオプションで入れておこう．⇒ダメだ．なぜだろう？⇒いや，違う．これは別の障害だ．
▲同上サンプルでoperator deleteの参照カウント残がNODEREFLIST #32811(3)→PAIRBOX #32810 で起きている．枝3はcurnod参照だ．やはり事前処理が欠けている．PAIRLIST自体はdataCountDownを持っていないが，deleteの直前でこれを呼び出さないと始末されない．⇒datacountが負になってしまった．⇒datacountはDATALISTが管理している．ここで操作すべきではない．
▲~PAIRBOXでgetcouplingが空を返している．昨日の障害がぶり返している．昨日の修正では「cancelでdeleteの代わりにRemoveを使う」となっているが，その修正が見当たらない．バージョンを間違えているのではないだろうか？いや，確かに昨日は一度バックアップに戻っている．昨日の修正は全部落ちていると考えるしかない．⇒対処した．
▲LIST::_removeで(toplist && !bottomlist())が起きている．⇒dataCountDownを事前処理として実行しているため，deleteが完了するまでは不整合が発生する可能性がある．この区間をremovingとして排除するようにした．
▲TRIBELIST::SortTribeListで(max != datacount)が起きている．max=21に対し，datacountは16．checkdatacountでチェックすると確かにdatacountの方が間違っている．SortTribeListの入口ですでに不正状態になっている．⇒LIST::_removeでdelete前にblackflagを上げていなかった．⇒blackflagを操作している箇所を総点検する．
▲TRIBEBOXの削除でoperator deleteの参照カウント残が出る TRIBELIST #32からの参照が2つ残っている枝4と枝5からTRIBEBOX #8183を参照している．broken（破壊された系列枠への参照）とstarttribe（基準ノードの属する始系列への参照）だ．現行ではTRIBEBOXのデストラクタからTRIBELIST::CleanSansyoの呼び出しを止めている．これを実行するとリストパラメータの不整合が起きてしまうためだ．上記参照をクリアするのは，むしろTRIBELIST：dataCountDownでなくてはならない．
▲~TITLEBOX→TITLEBOX::CleanSlot→clearslot(, true)で参照カウント不一致が発生した．参照が残っているのにカウントはゼロになっている．障害ノードはTITLELINK#7．どうもこれはNODEREFLIST#9の方が誤っているように思われる．⇒DATALIST::deleteElementに「blackflagの論理逆転＠20201128」に対応していない論理があった．
▲LIST::_removeで(toplist && !bottomlist())が起きた．障害が起きているのはPAIRLIST#13545で2つのノード対#32810と#34311がぶら下がっているというだけのものだ．削除対象は先頭の#32810で，処理終了時にはtoplistとbottomlistがともに#34311とならなくてはならないところだ．PAIRLIST::cancelでは冒頭でbottomlistを空にしている．これはまずいのではないか？従来論理では出口でそうしていたようだが…⇒これを修正しただけで動作するようになった．
▲同上サンプルを開いて，系統並び替えを実行したところ，COUPLING::TopologicalSort→TOPOLOGY::ResetExperimentでbottomlist不正で停止した．NODELIST::CleanSansyoでリスト要素を削除している．削除されているのはSIMPLENODE#31523でSIMPLENODEのデストラクタ中の動作だ．NODELIST#4278がその親リスト．⇒LIST::checkdatacountでremovingを見るようにして解消．