抽象グラフ検証系を外したベーシックなシステムの動作を再確認しておこう．グラフ検証系はZTシステムの肝とも言うべき重婚同類循環検定で用いられている機構で，ZTシステムの必須コンポーネントではあるが，それなしでも通常の系図を描画することは可能であり，どのような系図もたとえそれが最適なものではなかったとしても少なくともエラーなしで描画できなくてはならない．グラフ検証系がベーシックシステム自体の不良をカバーするものであってはならない．
MakeUpTreeの中で系列優先ノードを決定するDecidePrimaryNodeを全面的に書き換えた．これはある意味で，系列接続関係の仕様を根底から修正するものになっている．従来仕様では，従系列の系列優先仮ノードとそれが参照する主系列の優先実ノードは大概の場合は異なるカードの人名枠であることが仮定されていたが，改訂DecidePrimaryNodeではこの制限を大幅に緩和して，仮ノードと実ノードが同一人名であることがむしろノーマルであるような仕様になっている．
要は2系列の接点となるノードが決定できれば，その接続関係は問わないという立ち位置にシフトした．実際，系列優先ノード決定の時点では接続関係が確定していない配偶者ポジションにある2つのノードを結合するということが行われている．この関係は最終的にはBTWによって解決されているが，従来論理ではこのような選択は不可能だった．つまり，接続関係は後付けてよいというポリシー変更がなされたと解釈してよい．
▲グラフ検証系を外したZTベーシックシステムで，源氏物語全系譜6.1.ZELの全体図を#1 光源氏で開いて，出口検査のCheckPerfectTreeで「結婚枠内兄弟ノードの衝突」が検出されている．実際，NAMEBOX #615 藤壷の宮(0)と#605 末摘花(0)の人名枠が交叉している．水平交叉量は6で計算誤差として許容できる範囲を超えている．しかし，エラーを無視して描画するとこの交叉は解消してノーマルな状態で描画されている．これは検査関数の中で使われているCheckBrotherOrderが検査モードで呼び出されているにも関わらず，実動作を伴うものになっているためと考えられる．これはそれ自体不良なので調べておこう．
MARGBOX::CheckBrotherOrderは実行関数としてMARGBOX：checkBrotherOrderを呼び出している．この関数から呼び出しているCheckBrotherCrushがモードに関わりなく移動を実行している．⇒対処した．次の問題はなぜ，このエラーがメインループで検出されなかったか？という点だ．⇒どうも，検査ルーチンの中に実動作を伴うものがあるように思われる．⇒原因はTRIBELIST::CheckMaximalSegmentにある．セグメント検定はTRIBEBOX::CheckMaximalSegmentによって系列単位に実行される．障害が起きているのは一院系列 #1056なので，ここだけ見ればよいだろう．いや，障害はどうも複合的なもののようだ．
TRIBELIST::CheckMaximalSegmentの単独実行では発現しない．それに加えてtribelist->IsTribeCompleteを実行する必要があるようだ．この2つは実行順序を問わず，どちらを先に実行した場合でも発現する※．TRIBEBOX::CheckMaximalSegmentから呼び出されるTRIBEBOX：CheckMaximalCompactionは検査モードというのを持っていないが，それから呼び出されるMaximalCompactionには検査モードがある．便宜的にCheckMaximalCompactionの引数が空の場合は実行モード，そうでないときは検査モードであるとしてみよう．⇒この修正は意味があるが，現在の障害には影響を与えない．
※藤壷の宮(0)と末摘花(0)の人名枠の交叉はTribeRelocationの出口ですでに存在している．ただし，交叉量は4で許容誤差の範囲内にある．下記のMoveNeutralによる移動は実際にはわずか1しか移動していないが，IsTribeCompleteの中でもCheckMaximalSegmentが実行されているため，移動量1の動作が複数回実行されることにより，傷口が6まで拡大して発現に至るという状況になっている．
MAXIMALGRAPH::mergeUpperSegmentでBobject::MoveNeutralが実行されていた．MaximalCompactionから呼び出されるCountUpLooseBeltは検査モードを持っていない．この関数は本来検査専用と考えられていたものと思われるが，CountUpLooseBeltからMoveNeutralまではかなりの段数がある．
CountUpLooseBelt→ TRIBEBOX::CountLooseBelt→ MAXIMALGRAPH：JoinUpperSegment→ MergeUpperSegment→ mergeUpperSegment→ Bobject::MoveNeutral
中間の各関数は本来検査専用で，検査/実行を区別していない．mergeUpperSegmentでは対象結婚枠がZTYW婚の場合に限り，隣接人名ノードを接触位置まで移動するという操作を行っている．この動作を廃止するというのも一つの考え方であるかもしれない．
この処理を停止したら，今度はMARGBOX::CheckMarchainで「結婚鎖拡張チェーン不正」というエラーが起きるようになってしまった．上記修正とは本来まったく無関係であるようなところだが… 上の修正が妥当であるか否かは別として，これはこれでまた別の障害と考えるべきだろう．まず，こちらを先に片付けることにする．
▲上記のような条件の下で，TribeRelocationの【９】先祖並び自動オフで系列枠を線形物理配置というステージの「ZTYW婚の適正配置を実施する」という段で，CheckZeroPositionを実行して「結婚鎖拡張チェーン不正」というエラーが発生している．結婚チェーン上に並んだ2つの結婚枠が同じ配偶者を持っているとき，後ろの結婚枠のsiblingsが前方結婚枠を指していないというエラーだ．実際には空が入っている．siblingsというのは，「前方にある同じ母の子ども枠への参照：チェーンを構成する」というものなので，確かにどこかで間違えているように思われる．
- MARGBOX:#1725：#409 光源氏(0)＋#603 夕顔(0)→#419 玉鬘(0)
- MARGBOX:#343：#409 光源氏(0)＋#603 夕顔(0)→
どちらも光源氏(0)＋夕顔(0)の子ども枠で本人と配偶者が同じ結婚枠が子どもも1人しかいないのに2つあるという点が不審だが… 属性を見ると，前者はTOOYOUNGWIFE｜ERASEDYOUNGWIFE，つまり，ZTYW婚，後者はERASEDZEROGHOST｜GOODSIBLINGとなっている．つまり，「ZTYW本人を参照する仮ノードが存在する元の親枠」だ．
この2つの結婚枠は元々は一つのものだったのだから，「拡張子ども枠」のようなものでないことは明らかであり，siblingsを持っていないのも当然のように思われるが，このようなエラーはこれまで見たことがないような気がする．ZTYW婚というのはそれほどレアなものではないので，もっと頻発してもよさそうな気もするのだが…
最終的にはこのZTYW婚は消えてオリジナルのMARGBOX:#343だけが残り，玉鬘は夕顔の直下に配置されている．mergeUpperSegment→ Bobject::MoveNeutral の問題に戻ろう．下図で赤く塗りつぶしたところはZTYW婚で，この図面だけでもかなりの個数が使われている．
ZTYW婚の位置は不定なので，親ノードと同一セグメントにするのが難しいため，強制的に親ノードを隣接ノードの接触位置まで移動するという便法を取っているのだが，そのような強行手段（小細工）を取らなくても事実上問題は解決されているように思われる．この解法はひとまず保留として様子を見ることにしたい．しかし，これ以外でも検査モードで実動作が起きている可能性があるので，点検が必要だ．
予防措置としてTRIBEBOX::CheckMaximalSegment実行中はOnCheckMaximalSegmentが立っているので，このフラグがONのときは停止するようにしておこう．OnCheckMaximalSegmentを拡張してTRIBELIST::CheckMaximalSegmentの範囲まで広げておく．Bobject::MoveNeutral，Bobject::RelativeとBobject::originateでこのフラグをチェックするようにした．