Cognitive Engineering · Non-Neural Execution Engines · AI Agent Infrastructure · AI-Native Compilation

日本語: AIの出力だけでなく、計算・判断・実行・権限・記憶・監査を成立させる構造そのものを研究・設計しています。主力は D4 Pocket、BLUE-TANUKI、MINIDORA（ミニドラ）。さらに MINIDORA-BETA、AI-compiler、こんにゃく翻訳、MARS再現研究へ展開しています。対象・責任・証拠・保証範囲を分け、仕様と実装を照合する工学を重視します。

A language model is not automatically an agent. A fluent answer is not proof of correct judgment. And granting tools to an LLM does not, by itself, create a trustworthy authority system.

My work tackles all three gaps: the model, the decision-making and action-control layer, and the runtime infrastructure around it.

I lead the architecture, specifications, development direction and acceptance criteria, using AI coding agents as implementation collaborators. The central engineering question is always the same: What structure actually produces the result, and how can we rebuild and verify it without inheriting unnecessary assumptions?

These are three different engineering responsibilities, not three names for the same chatbot.

Repository →

D4 Pocket (formerly GUI Shell) is built around a simple proposition: as AI agents gain capabilities, runtime governance should become infrastructure—not an ad hoc collection of UI buttons, prompts and wrappers.

• Contract-driven integration: Runtime, Adapter, Agent Task and permission boundaries are defined through machine-readable schemas and conformance paths.
• Authority-sensitive Rust Broker: authenticated execution, approval eligibility, audit and recovery are kept separate from the Flutter presentation layer.
• Multi-agent operational surfaces: comparison, handoff, task handling, runtime catalogs and a product-facing Agent Center.

The October 11, 2026 B4-L2 development record reports 569 Rust tests passed, 167 schemas and 245 conformance checks, alongside bounded live Codex CLI integration tests. Those figures belong to that source revision and test environment, not to the current HEAD.

The November 10 integrated progress record now distinguishes W01 scoped Windows acceptance from W02 open end-to-end Codex → MCP Tool → dependent task execution. Ubuntu package install/update/rollback/uninstall has bounded acceptance evidence, but Linux product acceptance and broader release gates remain open. The record reports 16 unresolved release blockers of 18 and release_ready=false.

The ambition: an extensible “four-dimensional pocket” of agent capabilities, with the authority and responsibility to operate them coherently.

Repository →

BLUE-TANUKI is not designed as another chat frontend that happens to call tools. Its core idea is to separate capability from authority.

• HDS-BRAIN provides a standalone upstream decision and control boundary; its authority decisions do not call an LLM.
• LLMs, tools and communication channels remain downstream capabilities, not independent sources of permission.
• Approval, audit, memory and recovery are explicit parts of the execution model. Historical content and external metadata do not automatically escalate authority.

A public technical RC provides a bounded implementation and portable installers. The November QE_BUILD ledger records local wiring for browser observation, task-scoped recovery, source-bound memory and subsequent decisions. Many entries report build or fixture evidence while explicitly marking full tests, live provider paths, five-OS acceptance and product release NOT_RUN or OPEN. The five-OS vision is a target, not a claim of five completed releases.

The ambition: move from “AI that can call things” to AI whose decisions and actions can be governed and inspected.

Repository → · Live demo video → · Measured capability experiment →

What if the next route to capable AI is not a larger neural model, but a different engineering structure? MINIDORA tackles that question by building a non-neural language-model core, separating decision governance through HDS, and attaching computation, knowledge retrieval and replaceable capabilities without turning them into one monolithic model.

Its strongest bounded demonstration is not just that the model can run. On the September 9, 2026 GPQA Diamond experiment, enabling scientific-capability modules raised the same-run LIVE result from 29/198 to 80/198—51 additional correct answers, zero regressions—without retraining or enlarging the retained model core for that addition.

The historical MINIDORA80 40.40% result also sits in the same roughly 40% numerical range as the 39% GPT-4 baseline published in the original GPQA paper. The tested subsets and evaluation conditions differ; it is not a same-condition win or a claim of overall GPT-4 equivalence.

The October 1 integrated implementation and subsequent chat additions have not yet been measured across all 198 GPQA questions, so the older benchmark results stay attached to their original versions.

The ambition: to reopen how LLM capabilities are engineered—not only how many parameters they contain.

These are distinct projects with their own contracts and acceptance gates. Their presence in the portfolio does not mean they are integrated or released.

Cognitive Engineering → shared inquiry and audit discipline

MINIDORA (research) → MINIDORA-BETA (isolated execution engine)
                        └── Konjac Translation (planned product consumer)
BLUE-TANUKI          → governed agent execution
D4 Pocket            → generic runtimes, tools and operator control

AI-compiler          → independent AI-to-machine translation research
MARS                 → independent historical engineering reconstruction

These lines distinguish roles and proposed relationships; they do not certify cross-project integration or production readiness.

The architecture is informed by the same method across domains:

Observe the actual system
→ separate the target from its present implementation
→ identify relations, state changes and causal boundaries
→ specify who or what owns each decision
→ implement a testable alternative
→ measure results, failures and remaining gaps
→ revise the architecture where the evidence requires it

The point is not to invent terminology for its own sake. It is to stop mistaking the vocabulary of an existing implementation for the structure of the problem.

Cognitive Engineering Foundations archives the Japanese canonical work behind my cognitive-engineering program, including language-base theory, the Trinity Principle, Closure Phase Ψ and 神の領域原理（仮） (the provisional God's Domain Principle). Its current 14 canonical documents have separately classified English full translations and summary projections. The Japanese original remains authoritative; the project investigates how objects, relations and judgments are formed before they are promoted into engineering models.

LLM-Constitutive-Specification separates the constitutive conditions of a language model from a particular model family, and distinguishes reproducing a local operation from reproducing a decision-making system. It is a specification with explicit applicability boundaries—not a statement that every model must use HDS.

HDS-BlackBox-Translator records an earlier bounded public explanation experiment. It is a legacy public projection, not a current HDS specification or a disclosure of private internals.

The current theoretical publication boundary exposes HDS by name only. Historical public demos and product-level references must not be read as a current disclosure of HDS internals. Each repository sets its own public evidence and publication boundary.

Project ORCHID is low-level execution and memory-architecture work that grew from my initial locality and multi-memory-role proof-of-concept research.

• Concept originator: credited under my personal name in the ORCHID repository (GitHub: @gatchimuchio)
• Core architecture and maintainer: Kevin West (@westkevin12)

The ORCHID repository preserves the division of responsibility and the original baseline. The engineering connection with my AI work is the deliberate separation of what a system must do from how its current hardware or software implementation happens to do it.

I treat AI coding agents as an engineering workforce—not as the source of project goals, permission or final judgment.

My role is to determine the problem, design the system, formalize constraints and instructions, inspect the actual implementation, and decide whether the observed evidence warrants acceptance. A change in code is not automatically a change in capability; a passing unit test is not automatically a working product.

The working rules are straightforward:

• Goals and responsibility boundaries before tool choice
• End-to-end integration before mistaking isolated components for a finished system
• Evidence tied to exact source revisions, environments and conditions
• Explicit authorization, auditability and recovery for consequential actions
• Failure analysis that can reopen an upstream assumption, not just patch a downstream symptom

I am interested in systems whose operating principles can be explained, tested, challenged and improved—even when the implementation breaks with convention.

Flagship projects: D4 Pocket · BLUE-TANUKI · MINIDORA

New work: MINIDORA-BETA · AI-compiler · Konjac Translation · MARS

Research and collaboration: Cognitive Engineering · LLM Constitutive Specification · Legacy HDS demo · Project ORCHID

GitHub: @gatchimuchio

Portfolio status reviewed against public repository records on November 10, 2026 (JST). Each milestone describes its recorded revision and scope, not blanket certification or commercial release readiness.