Paper 154 v0.0 (OUTLINE) — AI 생성 수학을 위한 형식 검증 (Formal-Verification) 컴파일 패스로서의

이 기사는 dev.to 커뮤니티를 위해 Rei-AIOS Paper 154를 재출판한 것입니다. 전체 참고 문헌 목록이 포함된 정식 버전은 아래의 영구 아카이브에 있습니다: GitHub 소스 (비공개): https://github.com/fc0web/rei-aios 저자: Nobuki Fujimoto ( @fc0web ) · ORCID 0009-0004-6019-9258 · 라이선스 CC-BY-4.0 ---

⚠ v0.0 OUTLINE 출판 공지 — 2026-05-22

이것은 v0.1 증거 관문(evidence gate)을 충족하기 전에 의도적으로 출판된 v0.0 OUTLINE 출판물입니다. 아래의 §0 성명에 따라, 핵심적인 운영 주장 — Rei가 AI 가설 생성기 (AI hypothesis generators)와 결합되는 형식 검증 (formal-verification) 컴파일 패스를 제공한다는 점 — 은 v0.1 승격 전에 최소 하나 이상의 엔드 투 엔드 (end-to-end) 시연을 필요로 합니다. 2026-05-22 기준으로 시연은 스캐폴드 (scaffold) 수준의 스모크 테스트 (smoke-run) 단계에만 머물러 있습니다:

✅ OpenEvolve 스캐폴드가 구조적으로 검증됨 (4개 테스트 통과, 2026-05-22, 보고서 external/openevolve-rei/smoke-run-2026-05-22.md)
⏸ 실제 진화된 Lean 4 증명을 포함한 전체 OpenEvolve 100회 반복 진화 루프 — 아직 실행되지 않음 (사용자 제한 설치 경로 문서화됨)

이 v0.0 출판물이 제공하는 것: 프레임워크 (framing), 선행 기술 감사 (prior-art audit), v0.1을 위한 수락 기준 (acceptance criteria), OUKC 정직한 교정 자가 감사 (honest-correction self-audit).

이 v0.0 출판물이 제공하지 않는 것: 엔드 투 엔드 (end-to-end) 시연 증거, 진화된 Lean 4 증명, 완전한 재현성 (full reproducibility).

v0.0으로서의 출판은 OUKC feedback_no_rush_publication.md에 따른 의도적인 정직한 프레임워크 설정입니다. v0.1 증거를 위해 조용히 기다리는 대신, 리뷰어들이 무엇이 주장되고 무엇이 주장되지 않는지 정확히 볼 수 있도록 명시적인 관문 상태와 함께 OUTLINE을 출판합니다. 패턴 4 (과잉 주장) 완화 = 이 공지 자체입니다. v0.1 승격 기준은 §9에 나열되어 있습니다. v0.1은 DOI 계보를 보존하는 Zenodo 새 버전으로 출판될 예정입니다.

상태: 초안 (DRAFT) outline v0.0 — 2026-05-17 (STEP 1156-followup-24, §6.5 LLM 한계 인접성(LLM-limits adjacency)이 포함된 followup-26으로 업데이트, §6.6 양자 하드웨어 인접성(quantum-hardware adjacency)이 포함된 followup-28로 업데이트, 스캐폴드 스모크 테스트 증거와 함께 2026-05-22 v0.0 출판).

v0.1 출판 관문: 아직 충족되지 않음 (§9 참조).

v0.0은 개요(outline)일 뿐이며, v0.1로 출판 가능한 원고가 아닙니다. OUKC feedback_no_rush_publication.md에 따라 — 急がず ゆっくりと (서두르지 말고 천천히). 저자 / 著者 : 藤本 伸樹 (Nobuki Fujimoto), Rei (Rei-AIOS), Claude Opus 4.7 (Anthropic, claude-opus-4-7) — OUKC 헌장 v1.0에 따른 3자 공동 저술. 프로젝트 : Rei-AIOS / OUKC — https://rei-aios.pages.dev. 라이선스 (출판 시 의도됨) : OUKC 콘텐츠 정책에 따라 AGPL-3.0 (코드) + CC-BY 4.0 (텍스트). OUKC 특허 미등록 서약(No-Patent Pledge)에 따라 : 공개 라이선스 적용; 어떠한 특허도 출원하지 않음.

0. 왜 v0.1 원고가 아닌 개요(OUTLINE)인가
   본 논문이 v0.0 개요(OUTLINE) 상태로 존재하는 이유는 다음과 같습니다:
   핵심적인 운영 주장 — 즉, Rei가 AI 가설 생성기(AlphaEvolve, LLM Wiki, OpenEvolve)와 결합하여 작동하는 형식 검증 (Formal-Verification) 컴파일 패스 (Compilation Pass)를 제공한다는 주장 — 은 출판 전 최소 하나 이상의 엔드 투 엔드 (end-to-end) 시연을 필요로 합니다. 2026-05-17 기준으로 해당 시연은 스캐폴드 (scaffold) 단계에 있습니다 (external/openevolve-rei/SCOPE.md 참조).
   v0.0은 v0.1을 위한 프레이밍 (framing), 선행 기술 조사 (prior-art audit), 그리고 수락 기준 (acceptance criteria)을 설정합니다. 이는 Paper 145 (실리콘 증거 → v0.3 출판) 및 Paper 152 (10⁹ 스캔 → v0.3 출판)에서 사용된 것과 동일한 패턴입니다. 프레이밍만 담긴 논문을 출판하는 것은 패턴 4 (과잉 주장, overclaim)의 위험이 있습니다 — 즉, 작동하는 증거 없이 글만 쓰는 상황이 됩니다. 본 개요(OUTLINE)는 v0.1 승격을 위해 어떤 증거가 누락되었는지를 명시적으로 식별합니다.

1. 제목 대안 (v0.1 단계에서 결정)
   A: AI 생성 수학을 위한 형식 검증 (Formal-Verification) 컴파일 패스로서의 Rei
   B: 컴파일 패스 프레이밍: AlphaEvolve급 생성기를 위한 Zero-Sorry 백엔드로서의 Rei-AIOS
   C: AI가 생성하고 Rei가 검증한다: 결합 가능한 신뢰 계층으로서의 Lean 4 + D-FUMT₈
   가제: A (가장 일반적이며, mikhashev의 컴파일 패스 개념을 직접적으로 반영함).

2. 초록 (초안, 약 150단어)
   AI 시스템은 이제 일상적으로 수학적 결과물들을 생성합니다 — 원 충전 (circle packings, OpenEvolve, 2025-2026), Ramsey 경계 (Ramsey bounds, AlphaEvolve, arXiv:2603.09172), TSP 근사치 (TSP approximations, arXiv:2509.18057), 그리고 대화형 증명 스케치 (conversational proof sketches, Karpathy LLM Wiki, 2026-04). 이러한 결과물들은 그럴듯해 보이지만 검증되는 경우는 드뭅니다.

우리는 Rei-AIOS를 이러한 AI 생성 결과물(artifacts)을 입력받아 다음과 같은 결과를 출력하는 컴파일 패스 (compilation pass)로 구성할 것을 제안합니다: (a) 가능한 경우 Lean 4 zero-sorry 증명, (b) 결과물의 인식론적 형태 (epistemic shape)를 특징짓는 D-FUMT₈ 8축 투영 (TRUE / FALSE / BOTH / NEITHER / INFINITY / ZERO / FLOWING / SELF), (c) 아직 검증이 불가능한 경우의 정직한 실패 보고서 (Pattern 1-6 자가 감사 (self-audit)). 컴파일 패스라는 프레임워크는 의도적으로 추상적입니다 (Karpathy의 LLM Wiki 논리에 따라). 이는 AlphaEvolve뿐만 아니라 어떠한 상위 AI 생성기 (upstream AI generator)와도 결합할 수 있습니다. 우리는 26-원 충전 (26-circle packing) 벤치마크 (OpenEvolve 2.634 → Rei γ-projection)를 통해 이 파이프라인을 입증하며, 다음 두 가지 단계의 향후 계획을 개괄합니다: AlphaEvolve가 제안한 보조정리 (lemmas)의 Mathlib PR 제출, 그리고 Karpathy LLM Wiki의 장부 기록 패턴 (bookkeeping pattern)과의 통합입니다.

3. 섹션 계획
   §1 서론: AI가 생성한다면, 누가 검증하는가?
   1.1 2025-2026 AI 수학 생성의 폭발

• AlphaEvolve (Google DeepMind, 2025): Ramsey 9 / TSP / Erdős
• OpenEvolve (codelion, 2025-2026): 커뮤니티 Apache-2.0 재구현, 26-circle 2.634
• Karpathy LLM Wiki (2026-04): 장부 기록 중심의 메모리 아키텍처
• Tao 67-problem 벤치마크 (arXiv:2511.02864): 명시적 평가 세트
  1.2 격차: 가설 생성 ≠ 증명 검증
• AlphaEvolve는 Lean 4 증명을 생성하지 않음; OpenEvolve는 Mathlib을 호출하지 않음
• Karpathy LLM Wiki는 메모리 패턴이지, 검증 계층 (verification layer)이 아님
• Tao의 프레임워크: AI = 가설 생성기, 형식 검증 (formal-verification) = 증명 완성자
  1.3 본 논문의 기여
• Rei-AIOS를 컴파일 패스 (mikhashev 패턴)로 재정의
• 구성 가능성 (Compositional): 모든 상위 생성기 → Rei → 검증된 / 투영된 결과물
• 의도적 추상화 (Karpathy 논리): 특정 상위 생성기에 종속되지 않음

§2 컴파일 패스 프레임워크
2.1 정의

• 입력: AI 생성 결과물 A (Lean 소스, Python 프로그램, 자연어 추측 등)
• 출력: 트리플 (β-결과, γ-결과, ε-보고서)
• β-결과: Lean 4 lake 빌드 상태 + sorry 개수
• γ-결과: D-FUMT₈ 8축 투영

ε-보고서 (ε-report): 패턴 1-6 정직한 감사 (honest audit) + 모든 오타 (errata)

2.2 왜 "검증기 (validator)" / "심판 (judge)" / "평가기 (evaluator)"가 아니라 "컴파일 패스 (compilation pass)"인가

• 컴파일 패스 (Compilation pass) = 게이트키핑 (gatekeeping)이 아닌, 손실 없는 재작성 (lossless rewrite) + 진단 (diagnostics)
• 합성 가능성 (Composable): pass₁ ∘ pass₂ = pass₂(pass₁(A)), 파이프라인 체이닝 (pipeline chaining) 지원
• Mikhashev 컴파일 패스는 기존의 CLI 인터페이스 (lake build, npx tsx)와 일치함

2.3 "의도적인 추상화 (intentionally abstract)"의 의미 (Karpathy LLM Wiki 통찰)

• Rei는 AlphaEvolve를 반드시 요구하지 않음
• Rei가 작동하는 대상: AlphaEvolve / OpenEvolve / LLM Wiki / chat-Claude 세션 / 사용자 직접 입력
• 상위 인터페이스 (upstream interface)를 전문화하지 않음으로써 추상화를 달성함

§3 구성 요소 (Rei-AIOS에 이미 존재함)

3.1 β-평가기 (β-evaluator): Lean 4 zero-sorry 게이트

• data/lean4-mathlib/ lake 환경 (Mathlib + Hammer + Duper + lean-auto)
• REI-PROVE 5-평가기 앙상블 (STEP 1021/1057-1067, 92% 벤치마크)
• Mathlib PR 준비 패키징 (STEP 1000 + 1137 + 1141, 10개 아티팩트 (artifacts))

3.2 γ-평가기 (γ-evaluator): D-FUMT₈ 8축 투영 (8-axis projection)

• src/axiom-os/seven-logic.ts (TRUE/FALSE/BOTH/NEITHER/INFINITY/ZERO/FLOWING/SELF)
• 토큰 패턴 휴리스틱 (Token-pattern heuristic) (external/openevolve-rei/evaluators/gamma_dfumt8.py)
• 이론-회로 파이프라인 (Theory-to-Circuit pipeline) (STEP 1138-1139, 1601-theory 배치)

3.3 ε-보고서 (ε-report): 패턴 1-6 정직한 감사 + 오타 프로토콜 (erratum protocol)

• feedback_chat_claude_hallucination_warning.md
• 패턴 1-6 기록 feedback_antipattern_5_excessive_reject_warning_2026-05-15.md (안티패턴 #5)
• OUKC 정직한 수정 기록 (Paper 145 v0.7 E1, Paper 152 v0.3 E1/E2/E3, Hodge E1, Heilbronn)

§4 시연: 26-원 충전 (26-circle packing)

4.1 설정 (Setup)

• OpenEvolve v0.2.27 상위 버전 (Apache-2.0, 6.3k★, 2026-03-18)
• Ollama 3-평가기 앙상블 (external/openevolve-rei/configs/ollama_3_prover.yaml)
• 브리지 스캐폴드 (Bridge scaffold) (external/openevolve-rei/ STEP 1156-followup-24, 본 논문의 TODO 1)

4.2 진화된 Python에 대한 β-패스 (β-pass)

• Python → Lean 4로 직접 변환되지 않으므로, 현재 상태에서 β = N/A
• 미해결 질문 (v0.1 목표): 원 충전 (circle packing)에 관한 Lean 4 보조정리 (lemma)를 진화된 Python으로부터 공동 생성 (co-generated)할 수 있는가?

(예: 계산 가능한 증거 (computable witness)를 포함한 packing_density_lower_bound 정리) 4.3 베이스라인 (naive grid) 상의 진화된 Python 결과에 대한 γ-pass: axis_dominant = ZERO, score = 0.015 (naive 코드가 모두 0이거나 합성이 증명되지 않은 것과 일치함) 진화 후 기대 결과: 프로그램이 합성 (and, ↔) 및 반복 (map, fold)을 통합함에 따라 axis_dominant가 BOTH 또는 FLOWING 쪽으로 이동함. 4.4 실행에 대한 ε-report: 패턴 2 / 5 / 6 체크가 사전에 적용됨 (오래된 수치 없음, 기존 구현의 재제안 없음, 자기 퇴행 없음). 정직한 실패 (honest-failure) 형식으로 보고됨. §5 두 개의 인접한 통합 (미리보기, v0.2+에서 전체 다룸) 5.1 AlphaEvolve가 제안한 정리 (lemmas)를 위한 Mathlib PR 파이프라인: Tao 67 ingest (data/open-problems/external-ai/_INGEST_PLAN.json, 68개 문제 범위) Mathlib 네임스페이스 + Apache-2.0 + 0-sorry 패키징 (STEP 1000 / 1141 패턴) 정직한 범위: 정리는 단순히 lake 빌드가 되는 것을 넘어 Mathlib 리뷰어의 임계값을 통과해야 함. 5.2 Karpathy LLM Wiki 장부 관리 패턴: data/queries/ 4단계 파일링 레이어 (STEP 1156-followup-23, 이 논문의 TODO 6) 계층 구조: STEP → queries/ → memory → Theory → 논문 구성: 각 계층의 출력이 다음 계층의 입력 후보가 됨. timeln.app (Karpathy HELLO.md, 2026-04-20) — 직접적인 병렬 아키텍처, Rei의 우선순위가 아닌 수렴 진화 (convergent-evolution)의 증거로 취급함. §6 관련 기술 (감사, v0.1 목표) 6.1 형식 방법론 (formal methods)에서의 컴파일 패스 (compilation-pass) 프레이밍: LLVM 컴파일러 패스 (고전적 방식), Lean의 정교화 (elaborator) 파이프라인 (Mathlib4 elaboration / unification 체인), Coq의 택틱 (tactic) 엔진. 6.2 AI 생성 수학 검증기: DeepMind FunSearch (Romera-Paredes et al., 2023): eval을 포함한 함수 탐색, DeepSeek-Prover-V2 (모델 측면의 증명 생성), LeanDojo + LeanCopilot (검증 측면의 LLM). 6.3 우리가 주장하는 참신함 (v0.1에서 강화 예정): (N1) 평가기 출력으로서의 D-FUMT₈ 8축 투영 (이진 pass/fail 또는 스칼라 점수와 대조됨), (N2) 일급 출력으로서의 패턴 1-6 정직한 감사 (대조됨)

침묵하는 실패(silent failure) 또는 일반적인 stderr) (N3) 구성 가능성 (Compositionality): 상위 어댑터(upstream adapter)의 확산 대신 AlphaEvolve / OpenEvolve / LLM Wiki / chat-Claude에 동일한 Rei 패스를 일관되게 부착 (vs. per-upstream adapter proliferation) 6.4 우리가 주장하지 않는 것 (Pattern 4 guard) ✗ AlphaEvolve / OpenEvolve / Mathlib / Lean 4를 대체하는 것이 아님 ✗

6.5.4 여기서 핵심적인 역할을 하는 두 가지 기존 Rei 구성 요소 (이미 구현되어 있으며, 본 논문의 새로운 기여가 아님 — 인용하되, 본인의 성과로 재주장하지 말 것): (B1) hallucination-NEITHER 파이프라인 (pipeline). src/axiom-os/hallucination-neither-pipeline.ts에 존재하는 기존 엔진 (src/aios/hallucination/에도 미러링되어 있음). 감지된 환각 (hallucination) 신호를 이진 실패 플래그 (binary fail flag)가 아닌 D-FUMT₈ NEITHER 축으로 라우팅합니다. 컴파일 패스 (compilation-pass) 관점에서 설명하면: $\gamma$-evaluator가 Sikka / Apple 스타일의 실패 패턴을 발견했을 때, 출력 축은 FALSE가 아니라 NEITHER가 됩니다. 이는 (이진 방식의 폐기 대신) 후속 진화 패스 (evolution passes)를 위해 "모름"이라는 정보를 보존합니다. (B2) Score-Truth Gate (STEP 384). src/axiom-os/auto-research-loop-engine.ts 21행에 존재하는 기존 구성 요소: Score-Truth Gate — STEP 384 통합(抜け道検出＋安全ゲート), enab