| ⸻ | |
| ⸻ | |
| VERANTYX — Research Notes & Design Rationale | |
| Why the System Is Built This Way (Unified Edition) | |
| ⸻ | |
| 1. What VERANTYX Is (and Is Not) | |
| VERANTYX is a logic-centered inference system designed to control, constrain, and audit reasoning, rather than to generate language. | |
| It is not an LLM, and it is not an LLM wrapper by design. | |
| At the current stage, VERANTYX relies on conventional large language models only because its internal rule database is incomplete. | |
| This reliance is a temporary engineering choice, not a foundational dependency. | |
| The system is explicitly designed so that as the database grows, external language models become less important — and may eventually be unnecessary for many tasks. | |
| ⸻ | |
| 2. Motivation: Beyond Probabilistic Language Generation | |
| Modern AI research largely equates intelligence with probabilistic language generation. | |
| This approach has produced impressive results, but also systemic limitations: | |
| • Reasoning processes are opaque | |
| • Errors are indistinguishable from creativity | |
| • Correct answers may be produced for incorrect reasons | |
| • Failure modes are difficult to audit | |
| VERANTYX exists to explore an alternative: | |
| explicit, inspectable reasoning built from rules, counterexamples, and necessity checks. | |
| ⸻ | |
| 3. Core Philosophical Commitments | |
| VERANTYX is built on several non-negotiable principles: 1. Reasoning must be inspectable | |
| Every conclusion must be traceable to explicit rules or counterexamples. 2. Correctness is conditional | |
| The system distinguishes clearly between: | |
| • proven answers | |
| • refuted answers | |
| • insufficient evidence | |
| • provisional (mined) answers 3. Language models are scaffolding, not foundations | |
| They exist only to compensate for missing formalized knowledge. 4. Failure is a valid outcome | |
| “Cannot decide” is preferable to unjustified confidence. | |
| ⸻ | |
| 4. Architectural Overview | |
| VERANTYX operates in explicit, auditable phases: | |
| Phase 1 — Database-Only Reasoning | |
| • Uses only rules.json and registered definitions | |
| • No external model invocation | |
| • Deterministic and noise-free | |
| Phase 2 — Mining Fallback (Optional) | |
| • Triggered only when Phase 1 yields insufficient evidence | |
| • External models are queried with strict JSON-only prompts | |
| • Results are sandboxed as provisional knowledge | |
| Phase 3 — Audited Resolution | |
| • Proven rules override mined rules | |
| • Refutations override proofs | |
| • Provisional answers are explicitly labeled | |
| This structure ensures that expanding coverage does not degrade reliability. | |
| ⸻ | |
| 5. Noise Control as a First-Class Concern | |
| LLM-based mining is treated as a high-risk operation. | |
| VERANTYX enforces: | |
| • Strict JSON-only outputs | |
| • No natural language explanations | |
| • No overwriting of core rules | |
| • Explicit provenance tracking | |
| • Clear separation between verified and provisional knowledge | |
| Mining exists to fill gaps — not to redefine truth. | |
| ⸻ | |
| 6. Database-Centric Growth Model | |
| VERANTYX improves by writing rules, not by retraining models. | |
| Knowledge growth is: | |
| • incremental | |
| • inspectable | |
| • reversible | |
| • version-controlled | |
| This makes reasoning evolution slower, but auditable. | |
| ⸻ | |
| 7. The Role of Hardware in Contemporary AI | |
| Modern AI systems implicitly assume: | |
| • Large GPUs | |
| • High VRAM availability | |
| • Continuous training and retraining | |
| • Infrastructure often inaccessible to individuals | |
| This coupling between intelligence and hardware scale is rarely questioned. | |
| VERANTYX explicitly questions it. | |
| ⸻ | |
| 8. Hardware Efficiency as a Structural Consequence | |
| VERANTYX does not aim to eliminate hardware usage. | |
| Instead, it avoids mandatory dependence on large-scale compute. | |
| By design, VERANTYX: | |
| • avoids gradient-based training loops | |
| • avoids persistent high-dimensional latent states | |
| • relies on discrete rules and deterministic simulation | |
| As a result: | |
| • the system can be developed and experimented with in local environments | |
| • GPU usage is optional rather than structurally required | |
| • resource usage grows with database size, not model scale | |
| This is not an optimization trick — it is a consequence of the reasoning model. | |
| ⸻ | |
| 9. Why Individuals Historically Could Not Build AI | |
| For many years, “building AI” effectively meant: | |
| • training large neural networks | |
| • acquiring massive datasets | |
| • accessing expensive compute infrastructure | |
| This created a structural barrier: | |
| • individuals could not meaningfully experiment | |
| • research directions followed compute availability | |
| • architectural diversity collapsed | |
| Many ideas were never tested — not because they were wrong, but because they were impractical. | |
| ⸻ | |
| 10. A Concrete Trigger: Specialization Should Not Require Massive Training | |
| A personal motivation behind VERANTYX is that specialization is often treated as a large-scale training problem, even when the core need is reliable, auditable decision-making. | |
| In Japan, there have been real cases where local governments faced serious wildlife issues — including bear-related incidents — and responded by training image-based AI systems for bear identification. | |
| Those efforts can be valuable, but they often implicitly require: | |
| • large curated datasets, | |
| • training pipelines, | |
| • substantial compute, | |
| • long operational cycles. | |
| That pattern highlights a barrier: | |
| specialized AI is often inaccessible unless you can run large training projects. | |
| VERANTYX was partly motivated by the belief that specialization should also be possible through: | |
| • curated rules, | |
| • structured definitions, | |
| • verified exception handling, | |
| • and auditable failure modes, | |
| so that individuals and small teams can build specialized systems locally — without needing “industrial-scale training” as the default prerequisite. | |
| ⸻ | |
| 11. VERANTYX as a Counter-Design | |
| VERANTYX was motivated by a simple question: | |
| What if reasoning systems were constrained by ideas, not hardware? | |
| By prioritizing: | |
| • explicit rules over learned weights | |
| • database growth over retraining | |
| • auditability over benchmark performance | |
| VERANTYX enables: | |
| • local experimentation | |
| • individual-driven system evolution | |
| • architectural exploration without large infrastructure | |
| ⸻ | |
| 12. Domain Safety Motivation: Finance and Healthcare | |
| Another motivation is the need for systems that can operate under high-accuracy expectations, such as: | |
| • finance, | |
| • medicine, | |
| • safety-critical decision support, | |
| • compliance-heavy environments. | |
| These areas often demand: | |
| • traceability, | |
| • clear reasoning boundaries, | |
| • explicit assumption management, | |
| • and an acceptable ability to say “cannot decide.” | |
| VERANTYX aims to support this style of use by construction: | |
| not by claiming perfect correctness, but by making errors and uncertainty legible and auditable. | |
| ⸻ | |
| 13. Slowness as an Accepted Tradeoff | |
| VERANTYX accepts: | |
| • slower execution | |
| • narrower domain coverage | |
| • frequent “insufficient evidence” outcomes | |
| in exchange for: | |
| • transparency | |
| • controllability | |
| • independence from constant retraining | |
| This is a deliberate value choice. | |
| ⸻ | |
| 14. Relationship to LLMs (Clarified) | |
| LLMs are used in VERANTYX because: | |
| • they are widely available | |
| • they are convenient gap-fillers | |
| • the database is still incomplete | |
| They are not used because they are ideal, controllable, or foundational. | |
| As the database grows, reliance on external models is expected to decrease. | |
| ⸻ | |
| 15. Reframing AI Development | |
| In VERANTYX, AI development means: | |
| • curating knowledge | |
| • articulating rules | |
| • discovering counterexamples | |
| • managing assumptions | |
| not: | |
| • scaling parameters | |
| • minimizing loss functions | |
| • maximizing compute usage | |
| ⸻ | |
| 16. Participation and Accessibility | |
| A system that can be: | |
| • understood | |
| • modified | |
| • broken | |
| • repaired | |
| by an individual is fundamentally different from one that cannot. | |
| Lowering structural barriers changes: | |
| • who can participate | |
| • which ideas can be tested | |
| • what kinds of failures are acceptable | |
| ⸻ | |
| 17. Why VERANTYX v1 Was Closed | |
| VERANTYX v1 was not open source because: | |
| • core abstractions were unstable | |
| • misuse would have produced misleading conclusions | |
| • the system was not defensible as a public artifact | |
| Opening it prematurely would have created noise, not progress. | |
| ⸻ | |
| 18. Why VERANTYX Is Open Now | |
| VERANTYX is open now because it is unfinished. | |
| The system is stable enough to be: | |
| • modified | |
| • criticized | |
| • extended | |
| • broken | |
| without collapsing its core philosophy. | |
| Forks, incompatible extensions, and failed experiments are expected. | |
| ⸻ | |
| 19. Expectations for Users | |
| VERANTYX is not a product. | |
| You are not expected to: | |
| • trust it | |
| • agree with it | |
| • use it unchanged | |
| You are encouraged to: | |
| • inspect every rule | |
| • question every assumption | |
| • extend or replace the database | |
| • change or remove components | |
| Users are participants, not consumers. | |
| ⸻ | |
| 20. Research Status | |
| • Status: Experimental / Research Preview | |
| • Stability: Medium | |
| • Intended Use: Research, system design exploration | |
| • Not intended for: Production or safety-critical systems | |
| ⸻ | |
| 21. Long-Term Direction | |
| The long-term direction is clear: | |
| • reduced reliance on external models | |
| • stronger internal databases | |
| • fully auditable reasoning paths | |
| • increased feasibility of specialized systems built locally | |
| Whether this can scale remains an open question. | |
| ⸻ | |
| 22. Closing Note | |
| VERANTYX does not promise better answers. | |
| It promises clearer reasons for failure. | |
| This repository exists to explore whether that tradeoff is worthwhile — in public. | |
| ⸻ | |
| ⸻ | |
| ⸻ | |
| VERANTYX 研究ノート / 設計思想（統合版） | |
| ⸻ | |
| 1. VERANTYX とは何か（何ではないか） | |
| VERANTYX は、文章生成ではなく 推論そのものを制御・拘束・監査する ことを目的とした論理推論システムです。 | |
| LLM そのものでもなく、LLM ラッパーでもありません（設計上そうならないように作られています）。 | |
| 現時点では内部 DB が未完成であるため、LLM を補助的に利用していますが、 | |
| これは 暫定的な工学的判断であり、設計思想の中心ではありません。 | |
| DB が成長するにつれ、外部モデルの重要性は低下し、 | |
| 多くのタスクで不要になる可能性があるように設計されています。 | |
| ⸻ | |
| 2. 動機：確率的言語生成の限界 | |
| 主流の AI は確率的生成に強く依存していますが、そこには： | |
| • 推論過程の不可視性 | |
| • 誤りと創造性の混同 | |
| • 正答でも理由が誤っている可能性 | |
| • 監査不能な失敗 | |
| という構造的問題があります。 | |
| VERANTYX は、ルール・反例・必要条件検証による | |
| 明示的で検査可能な推論という別ルートを検証する試みです。 | |
| ⸻ | |
| 3. 基本思想 | |
| VERANTYX の原則： 1. 推論は検査可能であるべき 2. 正しさは条件付きである（証明・反証・証拠不足・仮回答を分ける） 3. LLM は足場であり基盤ではない 4. 判断不能は失敗ではない（不当な確信より優先） | |
| ⸻ | |
| 4. アーキテクチャ概要 | |
| • Phase 1：DB のみ（ノイズゼロ／決定論） | |
| • Phase 2：採掘（不足時のみ／JSON 限定） | |
| • Phase 3：監査付き決定（証明>仮、反証>証明） | |
| ⸻ | |
| 5. ノイズ制御 | |
| 採掘は高リスク操作として扱い、 | |
| • JSON 限定 | |
| • 説明文禁止 | |
| • 上書き禁止 | |
| • 出所管理 | |
| • 検証済みと仮知識の分離 | |
| を徹底します。 | |
| 採掘は「補完」であって「真理の定義」ではありません。 | |
| ⸻ | |
| 6. DB 中心の成長モデル | |
| VERANTYX は 学習ではなく記述によって成長します。 | |
| 知識の増加は： | |
| • 段階的 | |
| • 検査可能 | |
| • 差し戻し可能 | |
| • バージョン管理可能 | |
| その代償として成長は遅くなりますが、監査性が守られます。 | |
| ⸻ | |
| 7. 現代 AI とハードウェア前提 | |
| 巨大 GPU・高 VRAM・継続的な学習基盤が前提となった AI 開発は、 | |
| 個人にとって参入障壁が高すぎました。 | |
| この「知性＝計算資源」という結びつきは、あまり疑われてきませんでした。 | |
| VERANTYX はそこを疑います。 | |
| ⸻ | |
| 8. ハードウェア依存を前提にしない設計 | |
| VERANTYX は GPU を否定しませんが、 | |
| 必須ともしません。 | |
| 設計上、 | |
| • 勾配学習ループを必須としない | |
| • 高次元潜在状態を恒常的に持たない | |
| • 離散ルールと決定論シミュレーションを使う | |
| ため、 | |
| • ローカルで開発・実験可能 | |
| • GPU は「あると便利」止まり | |
| • リソース増加はモデルサイズではなく DB サイズに依存 | |
| という形になります。 | |
| これは最適化ではなく、推論モデルの帰結です。 | |
| ⸻ | |
| 9. なぜ個人は AI を作れなかったのか | |
| 長らく AI 開発は： | |
| • 大規模学習 | |
| • 大量データ | |
| • 高価な計算資源 | |
| を前提としてきました。 | |
| その結果、 | |
| 個人はアイデアの検証すら難しい状況が続いていました。 | |
| ⸻ | |
| 10. 具体的な問題意識：特化は「大規模学習」だけである必要はない | |
| VERANTYX の動機の一つは、 | |
| 「特化型 AI を作る＝大規模学習プロジェクト」になりがちな現実への違和感です。 | |
| 日本では、熊（クマ）による問題が深刻な地域があり、 | |
| 自治体レベルで熊識別のために熊画像を学習させる AI を構築したようなケースがありました。 | |
| それは価値のある取り組みですが、多くの場合そこには： | |
| • データ収集 | |
| • 学習パイプライン | |
| • 計算資源 | |
| • 運用コスト | |
| といった「大規模前提」が付きまといます。 | |
| ここでの問題意識は： | |
| 特化はもっと簡単に、個人でも到達できるべきではないか？ | |
| VERANTYX は、特化を | |
| • ルールの整備 | |
| • 定義の整備 | |
| • 例外処理（反例）の蓄積 | |
| • 監査可能な失敗設計 | |
| によって実現できる道を用意し、 | |
| 必要なら外部モデルを補助にしながらでも、 | |
| 個人がローカルで特化型システムを作れる状態を目指します。 | |
| ⸻ | |
| 11. VERANTYX の対抗設計 | |
| 問いは単純です： | |
| 制約はハードウェアではなく、アイデアと知識構造であるべきでは？ | |
| VERANTYX は： | |
| • 重みよりルール | |
| • 学習より DB | |
| • ベンチマークより監査性 | |
| を優先することで、 | |
| 個人でも検証できる AI を取り戻そうとします。 | |
| ⸻ | |
| 12. 金融・医療など「正確性が要求される領域」への動機 | |
| もう一つの動機は、金融・医療など | |
| 誤りのコストが高い領域で使えるものを作りたいという意図です。 | |
| こうした領域では： | |
| • 根拠追跡 | |
| • 仮定管理 | |
| • 境界の明確化 | |
| • 判断不能の許容 | |
| が必要になります。 | |
| VERANTYX は「完璧な正しさ」を主張するのではなく、 | |
| 誤りや不確実性が見える形で残ることを重要視します。 | |
| ⸻ | |
| 13. 遅さを受け入れる理由 | |
| VERANTYX は： | |
| • 遅さ | |
| • 狭さ | |
| • 判断不能の頻発 | |
| を受け入れます。 | |
| その代わりに： | |
| • 透明性 | |
| • 制御可能性 | |
| • 学習依存からの独立 | |
| を得ます。 | |
| これは価値選択です。 | |
| ⸻ | |
| 14. LLM との関係 | |
| LLM は： | |
| • 便利 | |
| • 入手可能 | |
| • 不足部分の穴埋めができる | |
| ため使っています。 | |
| しかし理想的・制御可能・基盤的だからではありません。 | |
| DB が成長するほど、外部モデル依存は減らす前提です。 | |
| ⸻ | |
| 15. AI 開発の再定義 | |
| VERANTYX における AI 開発とは： | |
| • ルールを書く | |
| • 反例を集める | |
| • 仮定を管理する | |
| • 失敗を設計する | |
| ことです。 | |
| パラメータ拡大や損失最小化ではありません。 | |
| ⸻ | |
| 16. 参加可能性 | |
| 個人が | |
| • 理解できる | |
| • 壊せる | |
| • 直せる | |
| システムは、それだけで意味があります。 | |
| 障壁が下がると、 | |
| 試せるアイデアの種類が増えます。 | |
| ⸻ | |
| 17. v1 非公開の理由 | |
| 抽象が未成熟で、誤解とノイズを生むだけだったからです。 | |
| ⸻ | |
| 18. 今オープンな理由 | |
| 未完成だからこそ、フォークと失敗を前提に公開します。 | |
| ⸻ | |
| 19. ユーザへの期待 | |
| 疑ってください。壊してください。拡張してください。 | |
| ユーザは消費者ではなく参加者です。 | |
| ⸻ | |
| 20. 研究ステータス | |
| 実験的です。安全重要用途には未対応です。 | |
| ⸻ | |
| 21. 将来像 | |
| DB が主役になります。 | |
| 外部モデル依存は減ります。 | |
| そして特化型システムを個人がローカルで作れる方向へ寄せます。 | |
| ⸻ | |
| 22. 終わりに | |
| VERANTYX は正解を約束しません。 | |
| 失敗の理由を約束します。 | |
| このトレードオフが価値を持つかを、公開の場で検証します。 | |
| ⸻ | |
| ⸻ | |