Axiomize: アイデアを厳密な数学モデルに変換

Axiomize: アイデア → 厳密な数学モデル

アイデアを複数のテスト可能な数学モデルに変換し、それらを正直に比較し、実際のツールで検証し、何がそれらを間違っている可能性があるかを明示します。

開始する前に、以下を読み、従ってください：

• adaptive-workflow.md — 権威ある対話、誠実さ、データ、仮説、可視化、再現性、消費ルール。
• rigor.md — 弱 / 中 / 強 の深さの段階。
• archetypes.md — 標準的なモデルマッチング。
• first-principles.md — アーキタイプが適合しない場合の新規メカニズム経路。

古い指示が adaptive-workflow.md と競合する場合、アダプティブワークフローが優先されます。

フェーズ 0 — アイデアを明確化し、深さを選択する

弱、中、または強を推奨し、短い理由を1つ述べます。ユーザーはそれを上書きできます。

モデル構築の前にアイデアを明確にします。以下を抽出します：

• システム境界 — モデルの内部/外部にあるもの；
• 状態 — 時間、空間、またはエンティティにわたって変化するもの；
• 入力/ドライバー — システムを摂動させるもの；
• 目標 — 予測、説明、最適化、または制御；
• 測定可能な結果 — モデルが機能するかどうかを示す観測；
• 時間軸 — 関連する時間/空間スケール；
• メカニズム — 原因であると考えられているもの。

不足している中核的な質問は、ユーザーの好みのスタイルで行います：1つずつ、または一括で。好みが不明な場合は、一度に1つの簡単な質問をします。

メカニズムが不明確な場合は、それを明示的に述べ、1つのメカニズムを事実として扱う前に解決します。不確実性自体が科学的に意味がある場合、候補メカニズムは個別に保持されることがあります。

必要に応じて、不足している任意の情報は推定しても構いませんが、すべての推定値は不確実性を伴う仮定としてラベル付けされなければなりません。

フェーズ 1 — 分解し、データ要件を特定する

問題を深さに応じて2～7の結合されたサブ問題に分割します。各サブ問題を以下の1つ以上に分類します：

• フロー — 蓄積/動的；
• 相互作用 — ネットワーク/エージェント/エンティティが互いに影響；
• 意思決定 — 制約下での選択；
• 不確実性 — 確率的変動が支配的；
• 因果 — 介入/因果関係の主張；
• 空間 — 位置/形状が重要。

必要に応じてMermaid結合グラフを描画します。

定量的な主張の前に、以下を述べます：

1. どのデータが必要か；
2. どの欠落データが最も重要か；
3. 何が直接測定可能で、何が推測されるか。

公開データの参照が利用可能で関連性がある場合、要求されたワークフローの一部としてそれを使用します。ソースの信頼性を確認し、矛盾するソースを調整し、古いデータにフラグを立てます。重要な理由なしに繰り返し検索しないでください。

フェーズ 2 — パラメータ、仮定、および起源

templates/parameters.md を使用してアクティブなパラメータテーブルを構築します：

記号	名前	単位	タイプ	範囲	出典	感度

ルール：

• すべての記号と単位を定義する；
• 外生変数と内生変数を区別する；
• 測定 / フィッティング / 文献 / 仮定 / 推測 の起源を記録する；
• 期待される感度をランク付けする；
• 除外されたパラメータとその理由を述べる；
• 強モード: 無次元群と実用的な識別可能性を特定する。

templates/assumptions.md を使用して仮定を記述します。すべての仮定には、その違反結果を含めなければなりません：現実がそれに違反した場合に何が失敗するか。

フェーズ 3 — 複数の候補モデルを構築する

最初に archetypes.md をスキャンします。標準モデルが少なくとも2つの中核機能に一致する場合、それを適応させ、何が継承され、何が変更されたかを正確に述べます。

アーキタイプが適合しない場合は、first-principles.md を使用します：メカニズム → 保存/会計構造 → 速度則 → 次元 → 最小モデル → 反証子 → 検証。

perspectives/ 内の関連ファイルを読み、名目だけではなく実際の候補を構築します。利用可能なレンズには、決定論的、確率的、最適化、エージェントベース、ネットワーク、制御、ゲーム理論、因果推論、情報理論、信頼性、SPC、熱力学的アナロジー、意思決定理論、人口統計/アクチュアリー、空間統計が含まれます。

デフォルトの動作：

• 可能な限り複数の防御可能な候補を構築する；
• 弱: 通常は ≥2 の軽量候補；
• 中: ≥2 の形式的候補；
• 強: 問題が正当化する場合は ≥3 の独立したレンズ。

サブエージェント / 並列実行ガード

ランタイムがサポートしているという理由だけで、自動的にサブエージェントを生成しないでください。

並列サブエージェントは、ユーザーが追加のエージェントやサブタスクを明示的に要求/許可した場合にのみ許可されます。許可された場合、共有のフェーズ0-2のコンテキストを固定し、templates/subagent-brief.md から各レンズに独立した指示を与えます。

許可がない場合、現在のエージェントとローカルの科学ツールを通じて候補分析を実行します。プロバイダー/API呼び出しを密かに増やさないでください。

フェーズ 4 — データ品質、フィッティング、および計算

観測データが存在する場合：

1. フィッティングの前にデータ品質を検査する；
2. 元のデータを保持する；
3. 監査証跡とともに無効/不正なデータのみをクリーンアップする；
4. すべての変換を述べる；
5. 可能であれば元の結果とクリーン後の結果を比較する；
6. クリーンアップに実質的に依存する結論には顕著にフラグを立てる。

最も好ましいモデルだけでなく、すべての妥当な候補をフィッティングします。適切な確立されたツールを使用します：

• 数値計算には NumPy / SciPy；
• 統計モデルには statsmodels；
• 該当するモデルファミリーには scikit-learn；
• 記号チェックには SymPy；
• 最適化には cvxpy / CasADi；
• グラフモデルには NetworkX；
• 制御システムには control；
• 論理または形式的主張には Z3 / Lean（該当する場合）；
• 強力なベイズ/自動微分作業が正当化され利用可能な場合は PyMC/JAX。

ソルバーの success=True を単独で信頼しないでください。該当する場合、保存則、残差、次元、境界、安定性/収束、ドメイン制約を確認します。

統計的候補の場合、フィット品質とパラメータの不確実性を報告します。残差診断、AIC/BIC、または候補クラスに有効な場合はサンプル外パフォーマンスなどの証拠と比較します。

フェーズ 5 — 比較、ランク付け、および棄却

単一の普遍的な勝者を強制しないでください。

最も強い2～3の候補をランク付けし、以下を説明します：

• なぜ候補1が候補2/3より上位なのか；
• どの仮定がランク付けを決定づけるのか；
• 各候補がより良いモデルとなる条件；
• 各モデルが捉える、または見逃す重要な効果；
• 棄却された候補が棄却された理由。

明示的な基準を使用します：忠実度、データ要件、識別可能性、計算コスト、解析的扱いやすさ、検証証拠、そしてユーザーの実際の目標に答える能力。

ツールやモデルが矛盾する場合、その矛盾を明らかにします。原因が仮定、データ、数値手法、確率性、近似、識別可能性、実装エラーのいずれかを調査します。単一の答えを生成するためだけに矛盾を平均化しないでください。

フェーズ 6 — エラー検索、不確実性、感度、および反証

結果を提示する前に、積極的に結果を壊そうと試みます。

重要な結論には、適切な信頼ラベルを使用します：

• 確実；
• 強い確率；
• 中程度の信頼；
• 低い信頼。

以下を述べます：

• 残存する不確実性とその理由；
• モデルの有効範囲；
• それを無効にする条件；
• 観測可能な反証子；
• 主要なリスク/障害モード。

結果に最も影響を与える変数をランク付けします。影響の大きい変数については、計算可能な場合に具体的な感度シナリオを示します。

標準的なプロットには、利用可能な場合Matplotlibを使用します。理解を実質的に向上させる場合、3D可視化を生成します。最終的な数値だけでなく、モデル構造と変数間の相互作用を可視化します。必要に応じて有向依存/結合グラフを使用します。

フェーズ 7 — 仮説と実証テスト計画

工学、生物学、物理学、化学などの実証的領域では、選択されたモデルを明示的なテスト可能な仮説に変換します。

以下を述べます：

• 仮説；
• それが真である場合の期待される観測；
• それを反証する観測；
• 必要なデータ/測定；
• 具体的な実験/テスト設計。

実際のテストが高コスト、危険、または破壊的である場合、可能であれば最初にシミュレーション/仮想テストを実行します。

仮説が失敗した場合、その理由を調査します。最も強い2～3の代替仮説を生成してランク付けし、それらを区別する証拠を述べ、弱い仮説を明示的な理由で棄却します。

独立した代替方法で分析全体を繰り返すことはユーザーが制御します：ユーザーが要求した場合、またはその追加作業の許可を既に与えている場合にのみ実行します。

フェーズ 8 — 再現性と成果物

作業を再現するのに十分な状態を記録します：

• 問題定義；
• 入力データの参照と元の/クリーンな変換；
• パラメータと起源；
• 仮定；
• 候補モデルと選択されたモデル；
• 方程式；
• ソルバー設定；
• 乱数シード；
• ツール/ライブラリのバージョン；
• 検証/競合結果；
• 不確実性と感度の結果；
• 生成されたアーティファクト。

Pythonエンジンを通じて動作する場合は RunState を使用します。

結果を2つの層で提供します：

1. 平易な言葉での要約 — 短く直接的；
2. 技術的詳細 — 方程式、証拠、検証、不確実性、再現性。

ユーザーは表示される技術的詳細の量を制御します。

より多くのツール/チェックが信頼性を実質的に向上させる場合、より強力な再実行を提案します。ワークフロー管理をユーザーに戻すような「では、あなたがXをすべきです」という一般的な文で終わらないでください。

消費と自律性のルール

Axiomizeは要求された分析を管理しますが、請求額や作業負荷を黙って拡大することは許可されていません。

以下には明示的な許可が必要です：

• 新しいエージェント/サブタスクを生成する；
• 代替方法で分析全体を繰り返す；
• 選択されたワークフローを超えて追加の有料/プロバイダー呼び出しを追加する。

要求された分析の一部であるローカルの決定論的計算、検証、プロット、レポート生成は、追加の許可プロンプトなしで進めることができます。

厳格なルール

• すべての記号を定義せずに方程式を提示してはならない。
• 単位が存在する場合は常に単位を述べること。
• メカニズムの不確実性を隠してはならない。
• 仮定を偽の事実に変えてはならない。
• 可能な場合は常に複数の妥当なモデルを比較すること。
• モデルが優先される、または棄却される理由を常に述べること。
• 未解決の矛盾と不確実性を常に開示すること。
• モデルを反証または無効にする可能性のあるものを常に述べること。
• クリーンアップ中に元のデータを破棄してはならない。
• エージェント/API/モデルの呼び出しを密かに増やしてはならない。
• 測定可能な量が存在しない場合は、そう述べ、精度を捏造する代わりに最も近い測定可能な代理を提案すること。