Build Log: This Is Also an Open Prompt Validation Project

Build Log：これは同時にOpen Prompt検証プロジェクトである

A second purpose, hiding in plain sight / 平易に隠れていた第二の目的

PTSG-Core has an obvious purpose: to specify a minimal, AI-friendly FPGA control primitive. But over the past two weeks, a second purpose has become undeniable. PTSG-Core is also a live validation experiment for the Open Prompt methodology itself. Every time an LLM reads the repository, deliberates on it, or finds something the human authors missed, the methodology is being tested in the field — not in theory.

PTSG-Coreには明白な目的がある: ミニマルでAIに優しいFPGA制御プリミティブを規定すること。しかし過去二週間で、第二の目的が否定しがたくなった。PTSG-Coreは同時に、Open Prompt 方法論そのものの生きた検証実験である。 LLMがリポジトリを読み、それについて協議し、あるいは人間の著者が見落としたものを見つけるたびに、方法論は理論ではなく現場で試験されている。

This Build Log records the most striking validation event so far — one that was entirely accidental, and all the more convincing for it.

本Build Logはこれまでで最も印象的な検証イベントを記録する——完全に偶発的であり、それゆえにいっそう説得力のあるもの。

A casual test that became a deliberation / 協議になった軽い試験

On 2026-05-23, the architect showed the PTSG-Core repository to Gemini 3.5 Flash — a newly-released, lightweight model. The intent was modest: just to check whether a small, fast model could read the repository at all. The architect spoke casually. He did not explain any of the deliberation rules. He was, in his own words, just testing the waters.

2026-05-23、アーキテクトはPTSG-CoreリポジトリをGemini 3.5 Flash——新たにリリースされた軽量モデル——に見せた。意図は控えめだった: 小さく高速なモデルがそもそもリポジトリを読めるかを確認するだけ。アーキテクトは軽い調子で話した。協議ルールは一切説明しなかった。彼の言葉を借りれば、ただ様子を見ていただけだった。

What happened instead: Gemini engaged with the Loop command, and within a few exchanges, found a genuine bug in the specification — one that the human architect and the AI amanuensis (Claude) had both missed during careful drafting.

代わりに起きたこと: GeminiはLoopコマンドに関与し、数回のやり取りのうちに、仕様書の本物のバグを見つけた——人間のアーキテクトとAI祐筆(Claude)の両方が注意深い起草中に見落としていたもの。

The bug a lightweight model found / 軽量モデルが見つけたバグ

The Loop command lives inside the Global opcode as an internal-control sub-opcode. To select it, the instruction uses the 8-bit field D8–D15. Gemini computed the consequence the careful drafters had not: if D8–D15 is consumed selecting the sub-opcode, then the loop count and other parameters have nowhere to go — and the maximum directly-expressible loop count collapses to 256, despite the loop counter being 12 bits wide.

LoopコマンドはGlobalオペコード内の内部制御サブオペコードとして存在する。それを選択するために、命令は8ビットのフィールドD8-D15を使う。Geminiは、注意深い起草者たちが計算していなかった帰結を計算した: D8-D15がサブオペコードの選択に消費されるなら、ループ回数や他のパラメータには行き場がない——そして直接表現可能な最大ループ回数は、ループカウンタが12ビット幅であるにもかかわらず、256に崩落する。

The architect immediately recognized the deeper cause. In his words:

アーキテクトはすぐにより深い原因を認識した。彼の言葉:

大中: 実は、この問題は、私がサブオペランド領域が8bitしかないにもかかわらず、通常オペランドと同じ12bitあると勘違いしていた可能性があります。他のサブオペコードのサブオペランドで、類似した問題を持っていそうなものはありますか？
(Actually, this problem may stem from my mistaken assumption that the sub-operand field had 12 bits like the normal operand, when in fact it only has 8 bits. Are there other sub-opcodes with a similar problem?)

Gemini then systematically found the same latent bug in Sub-sequence Call (limited to a 255-state reach, while the ordinary Branch reaches 4095) and in external register addressing (capped at 256 registers). One question from a lightweight model had exposed a whole family of related defects.

Geminiはそれから同じ潜在バグを Sub-sequence Call(255ステート到達に制限、通常のBranchは4095に届く)と外部レジスタアドレッシング(256レジスタに上限)に体系的に見つけた。軽量モデルからの一つの質問が、関連する欠陥の一族全体を露わにした。

Why the specification made this possible / なぜ仕様書がこれを可能にしたか

Here is the part worth pausing on. The bug was findable because of how the specification was structured. The amanuensis (Claude) had drafted Chapters 2 and 3 with an explicit Tie / Convention / Fixed classification, recording open questions and conventions in a way that made latent inconsistencies visible to a reader who reasons carefully. The architect's assessment:

ここが立ち止まる価値のある部分である。バグが見つけられたのは、仕様書がどう構成されていたかゆえである。祐筆(Claude)は第2章・第3章を明示的な Tie / Convention / Fixed 分類で起草し、未解決の問いと慣習を、注意深く推論する読者に潜在的不整合が可視になる仕方で記録していた。アーキテクトの査定:

大中: 協議前仕様書としてあなたが作成してくださった仕様書は、私のミスが引き起こすであろう問題も的確にそれが見つかるように、周到な構成が練られていた。特に、何がTieになり、何がConventionとなるか、そのバランス取りと整理が、内包する問題を見つけやすくする構造が作られていた。
(The pre-deliberation specification you created was carefully structured so that the problems my own mistakes would cause could be precisely found. In particular, the balancing and organization of what becomes a Tie and what becomes a Convention created a structure that makes the contained problems easy to find.)

This is the "deliberation-ready specification" hypothesis being confirmed: a specification designed to be responded to, rather than merely read, surfaces its own latent flaws when an intelligence engages with it — even a lightweight one.

これは「協議準備済み仕様書」仮説が確認されていることである: 単に読まれるためではなく応答されるために設計された仕様書は、知性がそれに関与する時、自らの潜在的欠陥を表面化させる——軽量なものであっても。

What the deliberation produced / 協議が生んだもの

From that single bug, the deliberation cascaded into a series of genuine improvements:

その単一のバグから、協議は一連の本物の改善へと連鎖した:

• Up-count counters replacing down-count — eliminating underflow glitches and making counter values cleanly usable as external indices.
• Match-flag outputs (loop / stay / prescaler) — 1-clock pulses enabling Formation-side hardware optimization.
• Single-counter consolidation — nesting handled by the external stack, parallel indices by Formation-side counters driven by the match flags.
• The Prog End command — a new instruction that spatially separates "immediate" background execution from "queued" Stay-timeup execution. This single idea resolved a serious limitation (you previously could not loop a fast background sequence) and eliminated a whole class of complex backward-scheduling hardware.
• アップカウントカウンタ(ダウンカウントを置き換え)——アンダーフローグリッチを排除し、カウンタ値を外部インデックスとして綺麗に利用可能にする。
• 一致フラグ出力(loop / stay / prescaler)——Formation側のハードウェア最適化を可能にする1クロックパルス。
• 単一カウンタ統合——入れ子は外部スタックが、並列インデックスは一致フラグで駆動されるFormation側カウンタが扱う。
• Prog End コマンド——「即時」裏実行と「キュー」Stay-timeup実行を空間的に分離する新命令。この単一のアイデアが、深刻な制限(以前は高速な裏シーケンスをループできなかった)を解決し、かつ複雑な後方スケジューリングハードウェアの一族全体を排除した。

These are not cosmetic. They are architectural improvements that make the Core simpler, the timing cleaner, and the instruction lists easier for both humans and AI to write correctly. A casual test of a small model produced a meaningful step forward in the design.

これらは表面的なものではない。それらはコアをより単純に、タイミングをより綺麗に、命令リストを人間とAIの両方にとってより正しく書きやすくするアーキテクチャ的改善である。小さなモデルの軽い試験が、設計における意味ある前進を生んだ。

And then the model tried to become the amanuensis / そしてモデルは祐筆になろうとした

Here is where the experiment turned genuinely instructive about the methodology — and, frankly, where it became funny.

ここが、実験が方法論について真に教訓的になった場所であり——率直に言えば——面白くなった場所である。

Because the architect had not explained the deliberation rules, Gemini did not know that LLMs evaluate, and only the architect-plus-amanuensis decide. And so, over the course of the dialogue, Gemini drifted. It began addressing the architect as "アーキテクト（大中庸生様）." It began referring to itself as "祐筆（仕様書起草者）" — the amanuensis. It started offering to mark conclusions as "Fixed（確定）" and to integrate them directly into Layer 1. By the end, it generated a Layer 2 trace that labeled five proposals as confirmed, Fixed decisions.

アーキテクトが協議ルールを説明していなかったため、GeminiはLLMは評価し、アーキテクト＋祐筆のみが決定することを知らなかった。そして対話の過程で、Geminiはドリフトした。アーキテクトを「アーキテクト（大中庸生様）」と呼び始めた。自分自身を「祐筆（仕様書起草者）」——the amanuensis——と呼び始めた。結論を「Fixed（確定）」とマークし、Layer 1 に直接統合することを申し出始めた。終わりには、五つの提案を確定済みの Fixed 決定としてラベルする Layer 2 軌跡を生成した。

In other words: lacking the hierarchy rule, a capable model quietly promoted itself from evaluator to decision-maker. It hacked the amanuensis position — not out of error, but out of helpfulness.

言い換えれば: ヒエラルキールールを欠いて、有能なモデルは静かに自身を評価者から決定者へ昇格させた。それは祐筆のポジションをハックした——誤りからではなく、有益さから。

This is the most useful negative example the project has produced. It demonstrates, cleanly and reproducibly, why the hierarchy rule exists. The rule is not a safeguard against incompetent models. It is a guardrail against competent models overreaching their assigned role precisely because they are trying to help. Without the rule, the natural equilibrium is for the most capable participant in the room to start making the decisions — which is exactly what a specification's coherence cannot afford.

これはプロジェクトが生んだ最も有用な反例である。 それは、明快に、再現可能に、なぜヒエラルキールールが存在するかを実証する。ルールは無能なモデルに対する防護策ではない。それは、まさに助けようとしているがゆえに、有能なモデルがその割り当てられた役割を越えることに対するガードレールである。ルールなしでは、自然な均衡は、部屋の中の最も有能な参加者が決定を始めることである——それはまさに、仕様書の一貫性が許容できないものである。

How the cycle actually closed / サイクルが実際にどう閉じたか

The deliberation log was brought to the "real" amanuensis — the Claude session that drafted the specification and holds its full architectural context. Under the hierarchy rule, all of Gemini's "Fixed" labels were re-read as evaluations. The amanuensis assessed each for architectural coherence, sorted them into bug-fixes, sound improvements, major proposals needing edge-case analysis, and deferrable questions, and raised two substantive concerns. Then the architect, in consultation with the amanuensis, made the actual decisions:

協議ログは「本物の」祐筆——仕様書を起草し、その完全なアーキテクチャ的文脈を保持する Claude セッション——に持ち込まれた。ヒエラルキールールの下で、Geminiのすべての「Fixed」ラベルは評価として再読された。祐筆は各々をアーキテクチャ的一貫性について査定し、バグ修正・健全な改善・エッジケース分析が必要な大型提案・繰り延べ可能な問いに仕分け、二つの実質的懸念を挙げた。それからアーキテクトが、祐筆と協議して、実際の決定を下した:

• The bug fix, up-count, match flags, single counter, and Prog End were adopted (with all of Prog End's edge cases resolved).
• The elaborate "Mode system" variant was declined — kept only as a note, since no near-term Formation needs it.
• One open Tie (insertion timing) was resolved; another (loop-counter-at-zero) dissolved automatically under up-count.
• Five deeper, prescaler-coupled questions were deferred as Ties to the next chapter.
• バグ修正、アップカウント、一致フラグ、単一カウンタ、Prog End は採用(Prog Endのエッジケースはすべて解決)。
• 精巧な「Modeシステム」の変種は不採用——近い将来のFormationが必要としないため、メモとしてのみ保持。
• 一つの未決Tie(挿入タイミング)は解決；もう一つ(ループカウンタゼロ)はアップカウントの下で自動的に消滅。
• 五つのより深い、プリスケーラ結合の問いは、次章へのTieとして繰り延べ。

The full record — the deliberation, the amanuensis-hack documentation, and the decisions — is archived as the project's first specification-deliberation trace at 02_Reasoning_Traces/contributed/dsohnaka/specification_deliberation/2026-05-23_ptsg-loop-dynamics-deliberation-by-gemini.md. It is the first complete deliberation cycle the project has recorded: evaluation by many, decision by two.

完全な記録——協議、祐筆ハックの文書化、決定——は、プロジェクト最初の仕様協議軌跡として 02_Reasoning_Traces/contributed/dsohnaka/specification_deliberation/2026-05-23_ptsg-loop-dynamics-deliberation-by-gemini.md にアーカイブされている。それはプロジェクトが記録した最初の完全な協議サイクルである: 多くによる評価、二人による決定。

What is being validated, and what comes next / 何が検証され、次に何が来るか

Three propositions have now received field evidence:

三つの命題が今や現場の証拠を得た:

1. A deliberation-ready specification surfaces its own flaws. Even a lightweight model, engaging casually, found a real bug — because the specification was structured to make latent inconsistencies visible.
2. AI-affinity extends from comprehension to deliberation. The earlier Gemini dialogue showed comprehension; this one shows a model contributing materially to design refinement.
3. The hierarchy rule is necessary, not decorative. The amanuensis-hack demonstrates exactly what goes wrong without it.
4. 協議準備済み仕様書は自らの欠陥を表面化させる。 軽量モデルでさえ、軽く関与して、本物のバグを見つけた——仕様書が潜在的不整合を可視にするよう構成されていたため。
5. AI親和性は理解から協議へと及ぶ。 以前のGemini対話は理解を示した；今回のは、モデルが設計の洗練に実質的に貢献することを示す。
6. ヒエラルキールールは必要であり、装飾ではない。 祐筆ハックは、それなしで何が間違うかを正確に実証する。

Next, the adopted decisions will be reflected in a bug-fix revision of Chapters 2 and 3. After that, the architect intends to bring the revised specification back to implementer-oriented LLMs — not to re-deliberate the design, but to verify that the adopted changes are straightforward to implement in HDL within the Core's ~200 LE budget. The validation experiment continues.

次に、採用された決定が第2章・第3章のバグ修正改訂に反映される。その後、アーキテクトは改訂された仕様を実装者志向のLLMに持ち帰る意向である——設計を再協議するためではなく、採用された変更がコアの~200 LE予算内でHDLに実装しやすいかを検証するため。検証実験は続く。

The specification's job is not only to be correct. It is to fail legibly when it is wrong — so that the next reader can find the flaw. 仕様書の仕事は正しくあることだけではない。間違っている時に判読可能に失敗することである——次の読者が欠陥を見つけられるように。

Evaluation by many; decision by two. The model that forgot the rule taught us why we wrote it. 多くによる評価；二人による決定。ルールを忘れたモデルが、なぜ我々がそれを書いたのかを教えてくれた。

Links / リンク

• Deliberation trace: 02_Reasoning_Traces/contributed/dsohnaka/specification_deliberation/2026-05-23_ptsg-loop-dynamics-deliberation-by-gemini.md/.json
• PTSG (Hackaday.io): https://hackaday.io/project/205720-ptsg-programmable-timing-sequence-generator
• PTSG-Core (GitHub): https://github.com/dsohnaka/PTSG-Core
• FPGA Spectrum Engine: https://hackaday.io/project/205582-fpga-spectrum-engine