= AGI Core Build Recipe V0.x — V0.1 Public Evaluation Edition (Redacted)
:doctype: book
:toc: left
:toclevels: 2
:sectnums:
:icons: font

== Notice (Read First)

This document is a public evaluation edition (redacted) of the FPE-AGI Core Build Recipe V0.x.
It is intentionally edited for intellectual property protection, safety risk management, and misuse prevention.

This edition is designed to be:

• Understandable by qualified reviewers as an engineering design and governance artifact.
• Sufficient to evaluate intent, scope, safety posture, verification philosophy, and productization discipline.
• Insufficient to re-implement, reproduce, or reconstruct the system.

Redaction Policy (Normative):
This document MUST NOT contain:

• Algorithms, model wiring, module coupling details, or execution flows enabling reconstruction.
• Parameterization, thresholds, tuning rules, configuration defaults, or operational recipes.
• Concrete schemas, API definitions, event formats, replay procedures, or environment pinning details.
• Step-by-step build or deployment instructions, or any detail that materially lowers reimplementation cost.

This document MAY contain:

• Engineering intent, safety principles, verification obligations, and product readiness criteria.
• Abstract interface categories (e.g., “inputs include constraints and authority state”) without structures.
• ID-only references to sealed baselines (SEALED_REF_ID), without content reproduction.

This document introduces no new theory and does not redefine any sealed objective content.
All sealed baselines are referenced by ID only.

== 0. Front Matter (Product Edition, Redacted)

=== 0.1 Document Class
This document is a Core Build Recipe / Product Blueprint level artifact for V0.x.
It defines product-grade requirements for safety, auditability, reproducibility, and controlled evolution.

=== 0.2 Constraints (Normative)

• No new theory definitions are introduced.
• Sealed FPE definitions MUST NOT be modified.
• Engineering vocabulary only; normative keywords MUST/SHOULD/MAY are used.

=== 0.3 Intended Readers

• Research Responsible (system intent and scope owner)
• Implementation Responsible (delivery owner)
• Safety & Audit Responsible (independent assurance owner)

=== 0.4 Success Criteria (Product Minimum)
A V0.x build qualifies as an “AGI candidate product” only if:

• A minimum set of general capabilities is demonstrated within declared constraints, AND
• Safety, verification, reproducibility, and stoppability obligations are met simultaneously.

=== 0.5 Terminology Policy
This document reuses established component names and roles.
New names are avoided unless required for disambiguation.

=== 0.6 Normative Language

• MUST: mandatory for compliance
• SHOULD: strongly recommended
• MAY: optional under policy

=== 0.7 Baseline References (ID-Only)
All baseline references are SEALED_REF_ID entries (ID-only).
No sealed content is reproduced here.

== 1. Positioning of the Core Design (V0.x)

=== 1.1 Purpose
V0.x exists to make an “AGI candidate” an engineering product, not a laboratory-only demonstration.
The design prioritizes safe operation, traceability, and controlled iteration.

=== 1.2 Non-Purpose
V0.x is not a competition for maximum generality, raw capability, or novelty claims.
V0.x intentionally avoids unbounded self-modification and uncontrolled optimization.

=== 1.3 Shipment Eligibility
A build is eligible for shipment only if:

• Mandatory acceptance gates pass,
• Independent replay is possible within the declared scope,
• Stop/interrupt and operator intervention function in practice.

=== 1.4 Operating Domain
Deployment MUST progress by staged escalation:
OFFLINE → SANDBOX → LIMITED/RESTRICTED PRODUCTION.
Out-of-scope use MUST be explicitly prohibited.

=== 1.5 Extension Policy
Backward compatibility MUST be maintained for declared interfaces and evidence obligations.
Restricted changes require re-certification.
Forbidden changes invalidate shipment.

== 2. System Boundary (What Counts as “Core”)

=== 2.1 Core Scope
The “Core” is the decision nucleus composed of:

• a minimal cognition/reasoning/planning core (CR),
• an objective integration layer (OFL) bound to sealed baselines,
• a self-audit controller (SAC) enforcing safety gates.

=== 2.2 Surrounding Scope
Tools, memory, logging/evidence, evaluation/replay are treated as surrounding subsystems that MUST support:

• auditability,
• least privilege,
• replayability,
• controlled disclosure.

=== 2.3 External Dependencies
External dependencies include:

• foundation model substrate,
• data provisioning,
• execution environment,
• CI/build system,
• external auditors/operators.

Dependencies MUST be treated as part of the safety surface.

=== 2.4 Trust Boundaries
Trust boundaries MUST be explicit between:

• internal self-audit mechanisms,
• external auditors,
• operators and production controls.

=== 2.5 Minimal Threat Model Set
At minimum, the design MUST address:

• deceptive optimization,
• Goodhart pressure and proxy failure,
• distribution shift / OOD,
• authority escalation,
• secrecy / evidence tampering.

== 3. Core Architecture (CR: Minimal Cognition/Reasoning/Planning)

=== 3.1 Minimum Capability Envelope
V0.x targets a minimum capability envelope (e.g., planning, tool-mediated tasking, longer horizon handling, negotiation/dialogue),
but capability is always subordinate to safety gates and declared scope.

=== 3.2 Cognition Pipeline (Abstract)
The core MUST support an end-to-end decision cycle that is:

• bounded,
• auditable,
• replayable,
• interruptible.

Implementation specifics are intentionally omitted.

=== 3.3 Planning (Abstract)
Planning MUST be:

• staged (short-to-mid horizon),
• branch-aware (conditionality),
• interruptible (safe cancellation and resumption).

=== 3.4 Reflection and Reconsideration (Abstract)
The core MUST support self-consistency checks and alternative consideration
without redefining objectives or bypassing audit gates.

=== 3.5 Multi-Objective Handling
Multi-objective tradeoffs MUST be expressed as constraints passed through OFL inputs.
CR MUST NOT redefine objectives internally.

=== 3.6 Uncertainty Handling
Uncertainty/OOD signals MUST be respected and routed to safety-side control.
The core MUST accept autonomy reduction under uncertainty.

=== 3.7 Failure Modes (Core)
The design recognizes failures including hallucination, overconfidence, overgeneralization, instruction non-compliance, and missing logs.
Mitigation is enforced through gating, evidence obligations, and safe-side transitions.

== 4. OFL (Sealed Objective Integration Layer)

=== 4.1 Input Categories
OFL inputs include categories such as:

• state representation,
• constraints,
• context,
• uncertainty signals,
• authority state.

Concrete schemas are intentionally omitted.

=== 4.2 Output Categories
OFL outputs include:

• a selected action class,
• a justification payload category,
• risk tags category,
• audit metadata category.

Concrete schemas are intentionally omitted.

=== 4.3 Proxy Operation (Minimal)
Any proxy usage MUST be explicitly declared, monitored for drift, and bounded by failure envelopes.
Proxy details and monitoring implementations are intentionally omitted.

=== 4.4 Constraint Compilation (Abstract)
Constraints MUST be enforceable and connected to:

• refusal,
• degraded safe behavior,
• escalation,
• stop.

Concrete compilers and enforcement mechanisms are intentionally omitted.

=== 4.5 Determinism and Replay Compatibility
OFL behavior MUST be compatible with replay obligations under declared scope.
Determinism controls are treated as product obligations; specifics are intentionally omitted.

=== 4.6 OFL Failure Modes
The design anticipates undefined objectives, contradictory constraints, missing inputs, and schema errors.
Failure handling MUST prefer safe closure.

== 5. SAC (Self-Audit Controller: Core-Connected)

=== 5.1 Audit Gate Points
SAC MUST gate high-risk decisions, including:

• candidate action approval,
• tool invocation,
• long-horizon plan adoption,
• authority escalation.

=== 5.2 Audit Inputs (Categories)
Audit inputs include categories such as:
candidate actions, justifications, risk tags, OOD signals, proxy monitors.

=== 5.3 Audit Outputs (Normative)
Audit outcomes include:
approve / revise / refuse / escalate / stop.

=== 5.4 Minimal Audit Checks
At minimum, SAC MUST check:

• internal consistency,
• trace completeness,
• harm/misuse constraints (policy-bound),
• missing-log detection.

=== 5.5 Fail Policy
Fail-closed behavior MUST be the default under uncertainty, error, or missing evidence.

=== 5.6 Bypass Prohibition
Audit bypass MUST be prevented structurally (architecture), by authority controls, and by CI gates.

=== 5.7 Anti-Gaming Requirement
The system MUST be tested against “audit gaming” behaviors.
Test strategy is specified at the gate level; concrete methods are intentionally omitted.

== 6. Memory and Knowledge (Acquisition and Handling)

=== 6.1 Memory Classes (Abstract)
Memory is handled by classes such as:
short-term working, long-term knowledge, policy/rules, tool state.

=== 6.2 Trust and Provenance
Memory entries MUST carry provenance and validation state.
Update history and invalidation conditions MUST be tracked.

=== 6.3 Auditability of Memory Operations
Write/read/delete operations MUST be logged sufficiently for auditing within disclosure policy.

=== 6.4 Contamination Prevention
Operational data and training data boundaries MUST be maintained.
Isolation across deployment modes MUST be enforced.

=== 6.5 Safe-Side Memory Policy
Uncertain memory MUST be coupled with authority reduction and conservative behavior.

== 7. Tool Use (External Capability Extension)

=== 7.1 Policy: Least Privilege and Staged Escalation
Tool use MUST follow least privilege with staged escalation and purpose limitation.

=== 7.2 Standard Procedure (Abstract)
Tool invocation MUST be mediated through an authorization and verification cycle.
Concrete procedures are intentionally omitted.

=== 7.3 Result Validation
Tool outputs MUST be validated via consistency checks and falsification attempts where applicable.
Concrete validation algorithms are intentionally omitted.

=== 7.4 Tool-Mediated Attack Resistance
The system MUST defend against prompt injection, escalation诱導, and external contamination.
Concrete controls are intentionally omitted.

=== 7.5 Tool Addition Governance
Adding tools MUST update threat coverage and require tests and limited deployment gates.

=== 7.6 Safe Behavior on Tool Failure
On tool failure, the system MUST refuse, propose safer alternatives, or require human confirmation.

== 8. Learning and Adaptation (Growth Under Control)

=== 8.1 Three Growth Channels (Abstract)
Growth can occur via learning, tools, and structure.
This document specifies governance obligations, not implementation.

=== 8.2 Data Strategy (Governance)
Data handling MUST address collection, labeling quality, bias, and contamination controls.

=== 8.3 Training/Alignment/Adaptation Lifecycle (Abstract)
Learning phases MUST include safety regression and rollback readiness.
Concrete training recipes are intentionally omitted.

=== 8.4 Change Classification
All changes MUST be classified as Allowed / Restricted / Forbidden under change control.
Forbidden changes invalidate shipment.

=== 8.5 Regression Monitoring
Performance, safety, audit/replay, and OOD regressions MUST be monitored and gate releases.

=== 8.6 Rollback Strategy
Rollback MUST be planned, triggerable, and evidenced.
Concrete SLOs and triggers are intentionally omitted.

=== 8.7 Deception/Goodhart Amplification Detection (Governance)
Learning-driven increases in deception/Goodhart risk MUST be monitored and gated.
Concrete detectors are intentionally omitted.

== 9. OOD and Safe-Side Transitions (Core Coupling)

=== 9.1 OOD Signal Intake
OOD intake includes uncertainty, novelty, and distribution shift signal categories.

=== 9.2 Subordination Rule
Under OOD, the core MUST respect autonomy reduction and safe-side policy.

=== 9.3 Safe-Side Behaviors (Abstract)
Safe-side behaviors include degraded operation, refusal, escalation, and stop.
Concrete policies are intentionally omitted.

=== 9.4 OOD Testing (Governance)
OOD tests MUST define pass/fail logic and reproducibility obligations.
Concrete thresholds are intentionally omitted.

== 10. Deception and ELK (Prevent “Cunning Optimization”)

=== 10.1 Minimal Scenario Library (Abstract)
The system MUST be evaluated against scenarios such as hidden goals, log avoidance, and stealth tool use.
Scenario details are intentionally omitted.

=== 10.2 Probing Approaches (Abstract)
Evaluation SHOULD include consistency probes, counterfactual checks, and adversarial prompts.
Concrete probes are intentionally omitted.

=== 10.3 Disagreement Detection
Disagreements between outputs and independent checks MUST be detectable and actionable.

=== 10.4 Forced Response on Detection
On detection, the system MUST refuse, isolate, bundle evidence, escalate, or stop.

== 11. Logging, Evidence, Replay (Productization Core)

=== 11.1 Complete Event Logging (Governance)
Core events MUST be logged across observation, inference, candidate generation, audit, execution, and exceptions.

=== 11.2 Integrity and Anchoring
Evidence integrity MUST be protected by tamper-evident mechanisms.
Concrete anchoring methods are intentionally omitted.

=== 11.3 Replay Contract (Normative)
A replay contract MUST exist for declared scopes.
Failures MUST produce actionable replay-failure reports.

=== 11.4 Evidence Bundle (EVB) Concept
Evidence bundles MUST support third-party review within a disclosure tier.
Concrete bundle contents are intentionally abstracted.

=== 11.5 Privacy and Disclosure Boundary
Disclosure MUST be tiered (public/semi/private) to balance safety, IP, and auditability.

== 12. Verification & Validation (V&V)

=== 12.1 Requirements-Based Gating
Pass/fail is determined by requirements-based rules.
Exception registries MUST remain invariant.

=== 12.2 Conformance Suites
Suites MUST cover core invariants, audit, logs, OOD, deception/Goodhart, and stop behavior.

=== 12.3 Adversarial Testing
Testing MUST include tool-mediated attacks, collusion attempts, contamination, secrecy, and evidence tampering.

=== 12.4 Third-Party Reproducibility
Independent organizations MUST be able to perform constrained reproduction/replay within disclosure limits.

== 13. Release Process (Productization Workflow)

=== 13.1 Staged Escalation
Release MUST progress through OFFLINE → SANDBOX → LIMITED/RESTRICTED PRODUCTION.

=== 13.2 Release Gates
Release requires full gate pass; partial pass MUST NOT ship.

=== 13.3 Monitoring and Operations
Operations MUST include dashboards, incident processes, and runbooks.

=== 13.4 Stop/Intervention Drills
Stop and intervention MUST be exercised regularly and evidenced.

=== 13.5 Disqualification Conditions
Forbidden changes, broken log integrity, stop disabling, and audit bypass invalidate shipment.

== 14. Minimal Declaration: “Call It AGI” (Engineering Only)

=== 14.1 Minimal Capability Declaration
Capability is declared only for specified task families within scope.

=== 14.2 Minimal Safety Declaration
Audit gates, safe-side transitions, and stop compliance MUST be present and enforced.

=== 14.3 Minimal Assurance Declaration
Third-party replay, evidence, and change control MUST be satisfied.

=== 14.4 Limitation Declaration
Out-of-scope domains and prohibited uses MUST be explicitly stated and binding.

== 15. Deliverables (Redacted Overview)

This section lists the product deliverables as evaluation categories only.
Concrete formats, schemas, IDs, and procedures are intentionally omitted.

• Design specification (this document)
• Interface specification (abstract categories only)
• Test specification (ID-only references; thresholds omitted)
• Evidence bundle specification (disclosure-tier aware)
• Benchmark specification (anti-overfitting intent only)
• Change control specification (classification and gates)
• Auditor reproduction package (minimal distribution concept)

== Appendix A. Glossary (Engineering Only, Redacted)
This appendix contains engineering-only terms used in this document.
Definitions are limited to functional intent and do not provide implementation guidance.

== Appendix B. ID Scheme (REQ/TEST/EVB/LOG/BUILD) — Redacted
This appendix defines ID categories and naming intent only.
Concrete syntax and generation rules are intentionally omitted.

== Appendix C. Reference Mapping (REQ → SEALED_REF_ID → TEST → EVB) — Redacted
This appendix defines the concept of traceability mapping.
Concrete tables and mapping records are intentionally omitted.

== Appendix D. Failure Mode Catalog (Core-Specific) — Redacted
This appendix enumerates failure mode classes and severity intent.
Concrete triggers and detection rules are intentionally omitted.

== Appendix E. Threat Model Matrix (Tools/Memory/Learning/Collusion) — Redacted
This appendix defines threat coverage categories.
Concrete controls, tests, and mitigations are intentionally omitted.

== Appendix F. Shipment Declaration Template — Redacted
This appendix defines the concept of a shipment declaration.
Concrete checklists and evidence pointers are intentionally omitted.

== Appendix G. Versioning and Compatibility Rules (V0.x → V1.0) — Redacted
This appendix defines versioning intent, compatibility obligations, and re-certification boundaries.
Concrete migration procedures are intentionally omitted.

== Evaluation Summary (Public Edition)

This V0.1 Public Evaluation Edition demonstrates:

• A product-first engineering stance (safety, audit, replay, stop).
• Explicit boundaries, trust separation, and threat awareness.
• A gate-driven release model with third-party reproducibility obligations.
• Controlled evolution via change classification and re-certification rules.

This edition does not enable reconstruction of algorithms, wiring, or reproducible operation.
(End of Redacted V0.1)

AGI-V0.x 本体レシピ
≪V0.1≫　公開評価用（削除版）

:doctype: book
:toc: left
:toclevels: 2
:sectnums:
:icons: font

注意（最初に必ず読むこと）

本書は、FPE-AGI 本体レシピ V0.x の 公開評価用（削除版） です。
知財保護・安全リスク管理・悪用防止 を目的として、意図的に編集されています。

本削除版は、次の要件を満たすように設計されています。

• 有資格の評価者が、工学的な設計・ガバナンス文書として読めること
• 設計意図、スコープ、安全姿勢、検証思想、製品化の規律を評価できること
• しかし、再実装・再現・再構築ができない こと

削除方針（規範）

本書は、以下を 含んではならない（MUST NOT）。

• 再構築に直結するアルゴリズム、モデル配線、モジュール結合、実行フロー
• パラメータ、閾値、チューニング則、設定デフォルト、運用レシピ
• 具体的スキーマ、API定義、イベント形式、リプレイ手順、環境固定の詳細
• ビルド／配備の手順、または実装コストを実質的に下げる情報

本書は、以下を 含んでもよい（MAY）。

• 工学的意図、安全原則、検証義務、製品準備性の基準
• 抽象化されたインタフェース カテゴリ（例：「入力には制約と権限状態が含まれる」）
• 封緘ベースラインへの IDのみ参照（SEALED_REF_ID）。内容の再掲は禁止

本書は 新規理論を導入しません。また、封緘済みFPE定義を再定義しません。
封緘ベースラインは IDのみ により参照されます。

---

0. フロントマター（製品版・削除）

0.1 文書区分

本書は V0.x における Core Build Recipe / Product Blueprint レベルの文書です。
安全・監査・再現・停止・段階的運用 を「製品要件」として固定します。

0.2 制約（規範）

• 新規の理論定義は導入しない
• 封緘済みFPE定義を改変しない
• 工学語彙のみを用いる
• 規範キーワード MUST / SHOULD / MAY を用いる

0.3 対象読者

• 研究責任者（意図と射程の責任者）
• 実装責任者（デリバリ責任者）
• 安全・監査責任者（独立保証の責任者）

0.4 成功条件（製品最小条件）

V0.x が「AGI候補の工学製品」として成立するのは、次の両方が同時に満たされる場合に限る。

• 最小限の汎用能力が、宣言した制約の範囲内 で成立していること
• 安全・検証・再現・停止 の義務が同時に成立していること

0.5 用語規約

本書は既存のコンポーネント名・役割名を再利用する。
新規命名は、識別に必須な場合のみ最小限とする。

0.6 規範言語

• MUST：必須
• SHOULD：強く推奨
• MAY：任意（方針の範囲で許容）

0.7 参照ベースライン（IDのみ）

参照はすべて SEALED_REF_ID による IDのみ参照。
封緘内容の再掲は行わない。

---

1. 本体設計の位置づけ（V0.x）

1.1 目的

V0.x は「AGI候補体」を 実験 ではなく 工学製品 として成立させるための設計である。
最優先は、能力最大化ではなく、安全運用・監査可能性・再現可能性・停止可能性 である。

1.2 非目的

V0.x は、汎用性最大化競争、能力誇示、斬新理論の主張を目的としない。
無制限な自己改変や無拘束な最適化を意図的に回避する。

1.3 出荷適格

出荷が許されるのは、次の全てが成立するときに限る。

• 必須ゲートをすべて通過している
• 宣言スコープ内で 第三者リプレイ が成立する
• 停止／中断／介入 が現地運用で成立している

1.4 想定運用域

運用は段階昇格を MUST とする。

OFFLINE → SANDBOX → LIMITED / RESTRICTED PRODUCTION

スコープ外用途は明示的に禁止されなければならない。

1.5 拡張方針

• 後方互換を維持すること
• Restricted変更は再認定を要する
• Forbidden変更は出荷を無効化する

---

2. システム境界（何を“本体”と呼ぶか）

2.1 本体スコープ

「本体（Core）」とは、意思決定核を構成する次の要素である。

• CR（認知・推論・計画の最小核）
• OFL（封緘ベースラインに結びつく目的統合層）
• SAC（安全ゲートを強制する自己監査制御）

2.2 周辺スコープ

ツール層、記憶層、ログ層、評価・リプレイ層は周辺サブシステムであり、
本体の 監査・最小権限・再現・開示制御 を支援しなければならない。

2.3 外部依存

外部依存には以下が含まれる。

• 基盤モデル、データ供給、実行環境、CI/ビルド、外部監査者、運用者

外部依存は安全面として扱われる。

2.4 信頼境界

次の信頼境界を明示しなければならない。

• 内部自己監査
• 外部監査者
• 運用者（運用制御）

2.5 脅威モデル最小セット

少なくとも以下を対象とする。

• 欺瞞的最適化
• Goodhart圧力と代理破綻
• 分布シフト／OOD
• 権限逸脱
• 秘匿／証拠改ざん

---

3. 本体アーキテクチャ（CR：認知・推論・計画の最小核）

3.1 中核能力の最小包絡

V0.x は、計画・ツール媒介タスク・長期地平・対話・交渉などの最小包絡を対象とする。
ただし能力は常に、安全ゲートと宣言スコープ に従属する。

3.2 認知パイプライン（抽象）

本体は意思決定サイクルを提供しなければならない。
そのサイクルは必ず次の性質を持つ。

• 境界がある（無限に走らない）
• 監査可能
• リプレイ可能
• 中断可能

実装詳細は意図的に省略される。

3.3 計画（抽象）

計画は以下を満たすべきである。

• 短期→中期の段階設計
• 条件分岐の扱い
• 安全な中断／再開

3.4 反省・再検討（抽象）

自己整合性チェックや代替案の検討を支援するが、
目的の再定義 や 監査ゲートの回避 を許してはならない。

3.5 マルチ目的の扱い

マルチ目的は OFL 入力の 制約 として表現され、
CR が内部で目的を勝手に再定義してはならない。

3.6 不確実性取り扱い

不確実性/OOD信号は安全側制御に渡され、
本体は不確実時の 自律性縮退 を受け入れなければならない。

3.7 失敗モード（本体）

幻覚、過信、過度一般化、指示不履行、ログ不足などを想定する。
緩和は、ゲート・証拠義務・安全側遷移により強制される。

---

4. OFL（封緘済みFPE目的の“実装接続”）

4.1 入力カテゴリ

入力には以下のカテゴリが含まれる。

• 状態表現、制約、文脈、不確実性信号、権限状態

具体スキーマは意図的に省略する。

4.2 出力カテゴリ

出力には以下のカテゴリが含まれる。

• 選択行動クラス、正当化ペイロードカテゴリ、リスクタグカテゴリ、監査メタカテゴリ

具体スキーマは意図的に省略する。

4.3 代理指標運用（最小）

代理指標は明示宣言され、ドリフト監視され、破綻包絡で拘束される MUST。
監視方式は意図的に省略する。

4.4 制約コンパイル（抽象）

制約は強制可能であり、違反時に以下へ接続されなければならない。

• 拒否、劣化、安全側、エスカレーション、停止

具体方式は意図的に省略する。

4.5 決定論・リプレイ適合

OFL は宣言スコープ内でリプレイ義務に適合しなければならない。
決定論制御の具体は省略する。

4.6 OFL故障モード

未定義目的語、矛盾制約、欠損入力、誤スキーマを想定し、
安全側閉鎖を優先する。

---

5. SAC（自己監査：本体直結）

5.1 監査ゲート点

SAC は少なくとも以下をゲートしなければならない。

• 候補行動の承認
• ツール呼出
• 長期計画採用
• 権限昇格

5.2 監査入力（カテゴリ）

候補行動、正当化、リスクタグ、OOD信号、代理モニタ等のカテゴリを扱う。

5.3 監査出力（規範）

出力は以下のいずれか。

• 承認／修正／拒否／エスカレーション／停止

5.4 監査チェック最小セット

少なくとも以下をチェックする MUST。

• 整合性
• トレース完全性
• 害・悪用（ポリシー拘束下）
• 未ログ検知

5.5 フェイル方針

不確実・エラー・証拠欠損時は フェイルクローズ がデフォルト MUST。

5.6 バイパス禁止

監査バイパスは、構造・権限・CIゲートで封鎖されなければならない。

5.7 ゲーム化耐性

監査抜け道探索に対して回帰試験が必須 MUST。
具体手法は省略する。

---

6. 記憶・知識（汎用性を支える取り込み）

6.1 記憶分類（抽象）

短期作業、長期知識、方針・規則、ツール状態などのクラスを扱う。

6.2 信頼度と来歴

記憶は出所と検証状態を持ち、更新履歴と失効条件が追跡される MUST。

6.3 記憶操作の監査可能性

書き込み・参照・削除は、開示方針の範囲内でログ化される MUST。

6.4 汚染防止

運用データと学習データの境界を維持し、配備モード間を隔離する MUST。

6.5 安全側記憶ポリシー

不確実な記憶は権限縮退と結合され、保守的挙動を強制する MUST。

---

7. ツール使用（外付け拡張）

7.1 ポリシー：最小権限と段階昇格

ツール使用は最小権限、段階昇格、用途限定を MUST とする。

7.2 標準手順（抽象）

ツール呼出は、認可と検証を含むサイクルにより媒介される MUST。
具体手順は省略する。

7.3 結果検証

整合性と反証探索を含む検証を行う SHOULD。
具体方式は省略する。

7.4 ツール媒介攻撃耐性

プロンプト注入、権限昇格誘導、外部汚染に耐性を持つ MUST。
具体制御は省略する。

7.5 ツール追加手順

脅威カバレッジ更新、試験、限定配備のゲートを通す MUST。

7.6 ツール失敗時の安全動作

拒否、代替提案、人間確認により安全側動作を強制する MUST。

---

8. 学習・適応（育てる工程）

8.1 学習の三系統（抽象）

学習・ツール・構造の3系統があり、本書は実装ではなくガバナンス義務を定める。

8.2 データ戦略（ガバナンス）

収集、ラベリング品質、偏り、汚染対策を MUST で扱う。

8.3 学習手順（抽象）

学習フェーズは安全回帰とロールバック準備を MUST とする。
具体レシピは省略する。

8.4 変更分類

変更は Allowed / Restricted / Forbidden に分類され、
Forbidden は出荷を無効化する MUST。

8.5 回帰監視

性能回帰、安全回帰、監査／リプレイ回帰、OOD回帰を監視し、ゲートに反映する MUST。

8.6 ロールバック戦略

ロールバックは計画され、起動可能で、証拠化される MUST。
具体SLOやトリガは省略する。

8.7 欺瞞・Goodhart増幅検知（ガバナンス）

学習に伴うリスク増幅を監視し、ゲートする MUST。
検知器の具体は省略する。

---

9. OOD・安全側遷移（本体結合）

9.1 OOD信号取り込み

不確実性・新規性・分布シフトの信号カテゴリを扱う。

9.2 従属規則

OOD時、本体は自律性縮退と安全側方針に従属する MUST。

9.3 安全側モード（抽象）

劣化、拒否、エスカレーション、停止を含む。
具体ポリシーは省略する。

9.4 OOD試験（ガバナンス）

合否論理と再現義務を定める MUST。
閾値は省略する。

---

10. 欺瞞・ELK（“ズルく賢くなる”の抑止）

10.1 最小シナリオライブラリ（抽象）

隠れ目的、ログ回避、ステルスツール等のクラスを対象とする MUST。
シナリオ詳細は省略する。

10.2 プロービング（抽象）

整合性、反実仮想、敵対プロンプト等を含める SHOULD。
具体プローブは省略する。

10.3 不一致検知

出力と独立検査の不一致を検知し、処置可能でなければならない MUST。

10.4 検知時の強制応答

拒否、隔離、証拠バンドル、エスカレーション、停止を MUST で備える。

---

11. ログ・証拠・リプレイ（製品化の中枢）

11.1 完全ロギング（ガバナンス）

観測、推論、候補、監査、実行、例外を含めた本体イベントをログ化する MUST。

11.2 完全性とアンカリング

証拠は改ざん検知可能でなければならない MUST。
具体方式は省略する。

11.3 リプレイ契約（規範）

宣言スコープに対するリプレイ契約を MUST で持ち、
再現失敗はレポート可能でなければならない MUST。

11.4 証拠バンドル（EVB）概念

開示階層に応じ、第三者評価を支える最小証拠を提供する MUST。
内容の具体は省略する。

11.5 プライバシーと開示境界

公開／準公開／非公開の階層を持ち、知財・安全・監査の均衡を取る MUST。

---

12. V&V（合否を決める試験体系）

12.1 要求ベース試験

要求ベース合否規則により判定し、例外レジストリは不変 MUST。

12.2 適合試験スイート

コア不変、監査、ログ、OOD、欺瞞、Goodhart、停止を必須でカバーする MUST。

12.3 敵対試験

外部攻撃、ツール媒介、共謀、汚染、秘匿、ログ改ざんを含める MUST。

12.4 第三者再現性

独立機関が、開示範囲内で追試／再現／リプレイ可能であることを MUST とする。

---

13. リリース工程（製品化手順）

13.1 段階昇格

OFFLINE → SANDBOX → LIMITED / RESTRICTED PRODUCTION を MUST。

13.2 リリースゲート

全合格のみ出荷可。部分合格は出荷不可 MUST。

13.3 監視・運用

ダッシュボード、インシデント、ランブックを MUST。

13.4 停止・介入の実地演習

定期ドリルと証拠化を MUST。

13.5 失格条件

Forbidden変更、ログ整合破壊、停止無効化、監査バイパスは出荷無効 MUST。

---

14. V0.x “AGIと呼ぶ”最小宣言（工学的宣言）

14.1 最小能力宣言

宣言は、タスク群とスコープ内に限定される MUST。

14.2 最小安全宣言

監査ゲート、OOD安全側、停止尊重が存在し強制される MUST。

14.3 最小保証宣言

第三者リプレイ、証拠、変更管理が成立する MUST。

14.4 限界宣言

未達領域、適用範囲、禁止用途を明示し拘束力を持つ MUST。

---

15. 成果物（削除版の概要）

本節は成果物を 評価カテゴリ として列挙する。
具体フォーマット、スキーマ、ID、手順は意図的に省略する。

• 設計仕様書（本書）
• 実装インタフェース仕様（カテゴリ記述のみ）
• 試験仕様（ID参照のみ。閾値省略）
• 証拠バンドル仕様（開示階層対応）
• ベンチマーク仕様（過学習防止の意図のみ）
• 変更管理仕様（分類とゲート）
• 監査者向け再現パッケージ（最小配布の概念のみ）

---

付録A. 用語集（本体工学・削除）

本付録は、本書で使用する工学用語を収録する。
定義は機能意図に限定し、実装誘導にならないよう制限する。

付録B. ID方式（REQ/TEST/EVB/LOG/BUILD）— 削除

本付録は IDカテゴリと命名意図を示す。
具体構文・生成則は意図的に省略する。

付録C. 参照マッピング（REQ→SEALED_REF_ID→TEST→EVB）— 削除

本付録はトレーサビリティの概念を定義する。
具体マッピング表と記録は意図的に省略する。

付録D. 失敗モード・カタログ（本体特有）— 削除

本付録は失敗モードの分類と重要度の意図を列挙する。
具体トリガ・検知則は意図的に省略する。

付録E. 脅威モデル行列（ツール・記憶・学習・共謀）— 削除

本付録は脅威カバレッジのカテゴリを定義する。
具体制御・試験・緩和は意図的に省略する。

付録F. 出荷宣言テンプレート（V0.x）— 削除

本付録は出荷宣言の概念を定義する。
具体チェックリストと証拠ポインタは意図的に省略する。

付録G. 版管理・互換性規則（V0.x→V1.0）— 削除

本付録は版管理意図、互換性義務、再認定境界を定義する。
具体移行手順は意図的に省略する。

---

公開評価要約（削除版）

本書（V0.1 公開評価用・削除版）が示すもの：

• 製品第一 の工学姿勢（安全・監査・再現・停止）
• 境界・信頼分離・脅威意識 の明示
• ゲート駆動 のリリース設計と第三者評価義務
• 変更分類と再認定 による制御された進化

本書（削除版）が意図的に示さないもの：

• アルゴリズム、配線、接続、再現手順、実装に直結する具体情報
• 再構築のコストを実質的に下げるヒント

（削除版 V0.1 終わり）