Research with ai

Research-with-AI — Скилл проведения исследования с сопровождением ИИ

Что такое Research DNA

Research DNA — компактный документ (3–6 страниц), содержащий эпистемические инварианты исследовательского проекта. Фиксируется до начала работы и меняется только через явную мутацию с обоснованием.

По аналогии с Project DNA: Research DNA отвечает на вопрос «какому стандарту истинности подчиняется это исследование», а не «какая у нас гипотеза и какие данные». Гипотеза и данные меняются, инварианты — нет.

Research DNA состоит из тех же четырёх слоёв, что и Project DNA, но наполненных эпистемическим содержанием:

Research DNA = Онтология (что считается объектом, результатом, данными)
             + Деонтика (какие процедурные ходы запрещены)
             + Аксиология (что важнее в этом исследовании)
             + Праксеология (как устроен процесс работы с ИИ)

Философский каркас

Онтология исследования

• Что мы считаем предметом исследования и как отличить его от соседних предметов.
• Что считается результатом, а что — артефактом процедуры.
• Что считается данными, а что — интерпретацией данных.
• Какие категории из training data ИИ недопустимо переносить на предметную область без проверки.

Деонтика исследования

• Какие процедурные ходы запрещены безусловно (подгонка baseline, ретроактивная переформулировка гипотезы, ссылки без проверки существования).
• Какие утверждения требуют внешнего подтверждения, а не ссылки на training data ИИ.
• Какие изменения в процессе требуют явной мутации (смена гипотезы, расширение выборки, добавление переменных).

Аксиология исследования

• Что важнее: скорость или строгость, новизна или воспроизводимость, красота нарратива или честность отрицательного результата.
• Критерии значимости результата — по каким границам он сравнивается.
• Приоритеты при конфликтах (например, между «быстро выпустить» и «дождаться независимой проверки»).

Праксеология исследования

• Как разделены роли между человеком и ИИ.
• Как устроен эпистемический журнал.
• Когда и как проводится адверсариальная проверка.
• Что требует воспроизводимости, что — внешней верификации, что — человеческого суждения.

Иерархия документов

Research DNA — эпистемические инварианты, для человека
  ↓
Research RNA — операционализация в текущем стеке и процессе
  ├── Предрегистрация (гипотеза, процедура, критерии)
  ├── Правила для ИИ-ассистента (роли, запреты, контуры проверки)
  ├── Протоколы воспроизведения (код, seed, окружение)
  ├── Журнал работы (непрерывный лог решений)
  └── Якоря сверки (внешние источники, референсные работы)
  ↓
Идея → Дизайн → Исполнение → Анализ → Адверсариальная проверка → Написание
  ↑
DNA-аудит исследования (обратная связь на любом этапе)

Семь якорей истины

Каждый якорь — механизм, компенсирующий конкретный дефект ИИ как исследовательского ассистента. Якоря встраиваются в Research RNA как обязательные процедуры.

Якорь 1. Предрегистрация гипотезы и процедуры

Компенсирует: склонность ИИ к ретроактивной рационализации результата. Форма: неизменяемый документ (коммит git, запись в журнал с меткой времени), фиксирующий до начала работы: что утверждаем, какие данные, какая процедура, какие критерии успеха и провала, какой результат считается опровержением.

Якорь 2. Разделение генератора и критика

Компенсирует: положительную обратную связь ИИ с собой в одной сессии. Форма: разные сессии/модели для генерации и критики. Промпт критика — адверсариальный: «найди все причины, по которым результат может быть артефактом». Критик не видит ожиданий генератора.

Якорь 3. Внешняя воспроизводимость

Компенсирует: галлюцинации численных значений и незаметные ошибки в коде ИИ. Форма: код, данные, окружение упакованы для независимого перезапуска. Seed фиксирован. Baseline перезапускается в идентичной среде, не принимается «на слово». Обязателен code review человеком критических участков (разбиение train/test, корректность baseline, утечки данных).

Якорь 4. Сверка с внешней реальностью

Компенсирует: склонность ИИ подставлять правдоподобные факты из training data. Форма: каждый фактический элемент (цифра, имя, дата, ссылка, связь) снабжается источником, независимым от training data. Факт, полученный только от ИИ — гипотеза, не факт. Для ссылок — проверка существования публикации. Для цифр — минимум два независимых источника.

Якорь 5. Адверсариальная проверка

Компенсирует: оптимистический дрейф ИИ к «результат корректен». Форма: отдельный этап в пайплайне после получения результата. Промпт: «Дан результат R. Перечисли все причины, по которым R может быть ложным или артефактом. Для каждой — минимальный тест на исключение». Без прохождения этого этапа переход к write-up запрещён.

Якорь 6. Калибровка значимости

Компенсирует: плоскость оценок ИИ — неспособность отличить инкремент от прорыва. Форма: каждый результат сопоставляется с распределением значимых работ в области за фиксированный период. Если результат меньше медианы — позиционируется как инкремент. Если больше — повод к перепроверке через Якорь 5.

Якорь 7. Эпистемический журнал

Компенсирует: ретроактивную подчистку нарратива под итоговый результат. Форма: непрерывный лог с временными метками. Фиксируются: изменения гипотезы с причинами, неожиданные результаты с объяснениями, моменты «слишком хорошо» с последующими действиями, разделение решений человек/ИИ. Финальный текст сверяется с журналом на полноту отражения.

Режим 1: Создание Research DNA для нового проекта

Когда использовать

Запуск нового исследования. Триггеры: «начинаем исследование», «новая тема», «давайте с начала», «хочу изучить Х».

Процесс

1. Собери контекст. Уточни у пользователя:

   • Предметная область и её специфика.
   • Характер ожидаемого результата: эмпирическая закономерность, новая методика, теоретическое обобщение, инструмент.
   • Природа данных: натурные, модельные, литературные, синтетические.
   • Критерии значимости в области (что считается результатом публикабельного уровня).
   • Ключевые failure modes области (что обычно ломает исследования такого типа).

2. Кристаллизуй инварианты. Задавай вопросы, превращающие интуицию в формулировки:

   • «Какой результат Вы бы отказались принять, даже если бы он подтвердил гипотезу?»
   • «Что в этой области является общеизвестной ошибкой, которую Вы точно не хотите повторить?»
   • «Если бы оппонент сказал "это получилось случайно" — что Вы сможете ему ответить?»
   • «На какую работу в области Вы ориентируетесь как на эталон строгости?»

3. Сформулируй Research DNA по шаблону ниже.

4. Проверь деонтику. Для каждого запрета спроси: «Если нарушить — сможет ли это ослабить результат? Если нет — это не деонтика». Вычисти слабые запреты.

5. Проверь аксиологию. Для каждого приоритета представь конфликтную ситуацию: «Что выбираем, если X и Y несовместимы?». Если ответа нет — приоритет не работает.

6. Положи Research_DNA.md в корень проекта.

7. Предложи создать Research RNA и предрегистрацию первого эксперимента.

Шаблон Research DNA

# [Название исследования] — Research DNA

**Версия:** 1.0
**Дата:** [дата]

---

## Назначение этого документа

Эпистемические инварианты исследования. Фиксирует что считается истиной, что запрещено, что важно, как работаем.

### Правила для ИИ-ассистента
1. Прочитай Research DNA перед началом любой фазы работы.
2. Любое действие должно быть совместимо с инвариантами.
3. При конфликте задачи с инвариантами — сообщи, не нарушай молча.
4. Мутация Research DNA — только через согласие исследователя с записью причины.
5. Факты из training data — гипотезы, требующие проверки (Якорь 4).

---

## 1. Предмет и область

[Что исследуется. Границы предметной области. Что НЕ входит в предмет.]

---

## 2. Онтология

### 2.1. Что считается объектом исследования
[Единицы наблюдения, единицы анализа, их различия.]

### 2.2. Что считается результатом
[Какой тип утверждения — целевой результат. Какие типы утверждений — побочные и не публикуются самостоятельно.]

### 2.3. Что считается данными vs артефактом
[Критерии разделения. Примеры артефактов процедуры, которые НЕ могут быть поданы как результат.]

### 2.4. Категориальные разделения, защищённые от подмены ИИ
[X ≠ Y — и почему. Случаи, когда ИИ склонен путать эти категории.]

---

## 3. Деонтика

### 3.1. Запрещённые процедурные ходы
[Конкретные ходы, нарушение которых делает результат недействительным. Каждый с обоснованием.]

### 3.2. Утверждения, требующие внешней верификации
[Какие факты нельзя брать из training data ИИ. Где обязательна сверка с независимым источником.]

### 3.3. Условия обязательной мутации Research DNA
[Какие изменения в процессе требуют явного пересмотра инвариантов, а не тихого продолжения.]

---

## 4. Аксиология

### 4.1. Приоритеты
[Что важнее: скорость или строгость, новизна или воспроизводимость, и т.д. Конкретные правила разрешения конфликтов.]

### 4.2. Критерий значимости результата
[Относительно чего калибруется значимость. Какое улучшение считается инкрементом, какое — прорывом. Референсные работы.]

### 4.3. Критерий публикабельности
[Минимальные требования к результату, без выполнения которых write-up не начинается.]

---

## 5. Праксеология

### 5.1. Разделение ролей человек / ИИ
[Что делает человек, что — ИИ, где граница. Где ИИ предлагает, но не решает.]

### 5.2. Якоря истины в этом проекте
[Какие из семи якорей задействованы, как операционализированы.]

### 5.3. Режим журналирования
[Как ведётся эпистемический журнал. Где хранится. Что обязательно фиксируется.]

### 5.4. Цикл работы
[Идея → дизайн → предрегистрация → исполнение → анализ → адверсариальная проверка → калибровка значимости → write-up. Где разрешены итерации, где нет.]

---

## 6. Специфика предметной области

### 6.1. Типичные failure modes области
[Известные способы получить ложный результат. Защита от каждого.]

### 6.2. Стандарты строгости в области
[Что принято, что отвергается. Примеры работ-эталонов и работ-антиэталонов.]

### 6.3. Внешние источники истины
[Какие базы данных, публикации, архивы — обязательные источники сверки (Якорь 4).]

---

## 7. Типовые сценарии

[Для каких вопросов/задач исследование проектируется. Какие результаты ожидаются.]

---

## Версионирование

| Версия | Дата | Изменения | Причина мутации |
|--------|------|-----------|-----------------|
| 1.0 | [дата] | Первичная формализация | — |

Режим 2: Создание Research RNA

Когда использовать

Research DNA готов, нужно операционализировать инварианты в текущем процессе.

Процесс

1. Прочитай Research DNA.
2. Узнай стек работы: какой ИИ-ассистент, какая среда исполнения экспериментов, какие инструменты доступны.
3. Для каждого инварианта DNA сформулируй операциональное воплощение:
   • Онтология → проверочные вопросы перед каждым утверждением результата.
   • Деонтика → явные запреты в промптах ИИ, автоматические проверки, чек-листы.
   • Аксиология → критерии остановки, критерии эскалации к человеку.
   • Праксеология → процедуры (как запускать предрегистрацию, как вести журнал, как проводить адверсариальную проверку).
4. Создай артефакты Research RNA:
   • predrg_template.md — шаблон предрегистрации.
   • AGENTS.md / CLAUDE.md — правила для ИИ-ассистента.
   • reproduce.md — протокол воспроизведения (среда, seed, данные).
   • journal.md — эпистемический журнал (живой документ).
   • adversarial_checklist.md — чек-лист адверсариальной проверки.
   • significance_calibration.md — референсные работы для калибровки значимости.
5. Предложи зарегистрировать первую гипотезу.

Режим 3: Предрегистрация эксперимента (Якорь 1)

Когда использовать

Перед запуском конкретного эксперимента или серии экспериментов.

Процесс

1. Проверь, что Research DNA и RNA существуют. Если нет — перейди к Режиму 1 или 2.

2. Сформулируй предрегистрацию:

   • Гипотеза. В форме «если выполнить процедуру П на данных Д, ожидаем результат Р в диапазоне [а, б]».
   • Процедура. Пошагово, с указанием всех параметров, которые будут зафиксированы до исполнения (а не подобраны по ходу).
   • Критерий успеха. Какой результат подтверждает гипотезу.
   • Критерий провала. Какой результат её опровергает.
   • Критерий неопределённости. Промежуточные исходы, которые потребуют дополнительного анализа.
   • Условия преждевременной остановки. В каких случаях эксперимент прерывается и это не считается неудачей.
   • Что НЕ будет считаться доказательством. Артефакты процедуры, которые могут имитировать положительный результат.

3. Проверь предрегистрацию на совместимость с Research DNA. Если есть конфликт — сообщи, не регистрируй.

4. Зафиксируй предрегистрацию с меткой времени. Коммит git, запись в журнал, отдельный файл с hash — любая форма, гарантирующая неизменяемость.

5. Только после фиксации — переходи к исполнению.

Режим 4: Адверсариальная проверка (Якорь 5)

Когда использовать

После получения численного результата, до перехода к write-up. Также при ощущении «слишком хорошо получилось».

Процесс

1. Загрузи результат и процедуру в новую сессию ИИ с промптом адверсариального агента:

   «Ты — оппонент, чья задача — обвалить предъявленный результат. Дано: [процедура], [результат]. Перечисли все возможные причины, по которым результат — артефакт, случайность или ошибка. Для каждой причины укажи: минимальный тест на её исключение; текущее состояние этого теста (проведён/не проведён/неприменим); серьёзность угрозы для результата (критическая/серьёзная/мелкая)».

2. Стандартный чек-лист угроз (дополняется предметной спецификой):

   • Baseline не перезапущен в идентичной среде.
   • Утечка данных между train и test.
   • Статистическая значимость не проверена, или проверена при множественных сравнениях без коррекции.
   • Результат возможен только из-за изменения объёма данных или длины обучения, не из-за метода.
   • Размер эффекта меньше шума метрики.
   • Результат невозможен по построению (как e-fold CV > k-fold CV).
   • Корреляция подана как причинность без обоснования.
   • Сравнение проведено на нерепрезентативной подвыборке.
   • Результат чувствителен к seed / инициализации / гиперпараметрам, не зафиксированным в предрегистрации.
   • Работа ИИ-ассистента содержит неисправленные ошибки в коде критических участков.

3. Для каждой критической угрозы — либо провести тест на исключение, либо явно зафиксировать невозможность такого теста (и признать ограничение результата в write-up).

4. Результат адверсариальной проверки фиксируется в эпистемическом журнале.

5. Без прохождения этого режима переход к write-up не разрешается.

Режим 5: Аудит исследования на соответствие Research DNA

Когда использовать

Триггеры: «проверь соответствие DNA», «аудит исследования», после крупного этапа, перед отправкой рецензентам, при смене исполнителя, при подозрении на дрейф.

Процесс

1. Прочитай Research DNA.

2. Изучи артефакты: предрегистрации, код экспериментов, результаты, журнал, черновики текста.

3. Для каждого раздела DNA выдай диагностику:

### [Раздел DNA]

✅ Соответствует:
- [что реализовано корректно, со ссылкой на артефакт]

❌ Нарушения:
- [что противоречит DNA, с указанием места]

⚠️ Не реализовано:
- [что есть в DNA, но не операционализировано]

🔍 Не задокументировано:
- [что есть в исследовании, но не отражено в DNA — возможная область мутации]

4. Специальная проверка на дрейф:

   • Совпадает ли финальная формулировка гипотезы с предрегистрированной? Если нет — зафиксирована ли мутация?
   • Совпадает ли процедура с предрегистрированной?
   • Все ли факты в черновике сверены с внешними источниками (Якорь 4)?
   • Проведена ли адверсариальная проверка (Якорь 5)?
   • Откалибрована ли значимость (Якорь 6)?
   • Полон ли эпистемический журнал (Якорь 7)?

5. Не предлагай исправления в этом проходе. Только диагностика.

6. Отметь что требует ручной проверки (предметная корректность, которую ИИ не может оценить).

Режим 6: Мутация Research DNA

Когда использовать

Обнаружено, что инвариант сформулирован неполно, неверно или перестал соответствовать текущему пониманию. Триггеры: «добавим в DNA», «пересмотрим критерий», «этого запрета недостаточно», результат адверсариальной проверки выявил зазор.

Процесс

1. Покажи текущую версию затронутого раздела.
2. Предложи формулировку изменения.
3. Обоснуй — почему это мутация DNA, а не локальное отступление.
4. Проверь последствия: какие уже выполненные шаги могут оказаться несовместимы с новой DNA?
5. После согласования с человеком — обнови Research_DNA.md с новой версией и записью в таблице версионирования (включая причину).
6. Запусти DNA-аудит (Режим 5) для выявления расхождений между новой DNA и уже сделанным.
7. Зафиксируй решения по выявленным расхождениям в журнале.

Режим 7: Извлечение Research DNA из существующего исследования

Когда использовать

Исследование уже ведётся без явной эпистемической рамки. Триггер: «вот наше исследование, выдели инварианты». Также при рецензировании чужой работы (реконструкция декларируемых и фактических инвариантов).

Процесс

1. Изучи имеющиеся артефакты: план, результаты, черновики, обсуждения.

2. Для каждого решения и утверждения спроси:

   • Это конкретное содержание (гипотеза, цифра, интерпретация) или устойчивый принцип?
   • Если отменить эту частность, останется ли проект тем же?
   • Да → частность, не DNA.
   • Нет → инвариант, элемент DNA.

3. Сгруппируй инварианты по четырём слоям.

4. Для рецензионного применения — проведи двойное извлечение:

   • Декларируемое DNA: что автор заявляет как принципы (введение, методология, positions).
   • Фактическое DNA: что видно из процедур и результатов (как он реально отличает данные от артефакта, какие ходы себе позволил, по какому критерию оценивает значимость).
   • Разрыв между ними — ключевой диагностический сигнал. Совпадение — работа эпистемически честна. Расхождение — признак наукообразия, подмены, дрейфа.

5. Сформулируй без технических деталей реализации.

6. Предложи пользователю на ревью.

Режим 8: Разведывательное исследование предметной области для Project DNA

Когда использовать

Перед запуском нового проекта, требующего формулирования Project DNA. Триггеры: «хочу начать проект по теме X», «нужен Project DNA, но не уверен в предметной области», «не знаю, какие тут реально инварианты», «сначала разведка».

Также применяется ретроспективно, если Project DNA уже сформулирован, но возникло подозрение, что некоторые инварианты унаследованы без обоснования (от учебников, от соавторов, от training data ИИ).

Назначение

Project DNA фиксирует инварианты. Но инварианты нельзя просто вспомнить или сгенерировать — их нужно обнаружить. Разведывательное исследование даёт материал, на который опираются формулировки DNA. Без этого режима DNA рискует быть декларативным документом, который удерживается не на обоснованных предпосылках, а на авторитете источников или на правдоподобии формулировок ИИ.

Типичные failure modes DNA без pre-research:

• Инварианты, перенесённые из training data ИИ без проверки применимости.
• Инварианты, заимствованные у референсных авторов без верификации в конкретной реализации проекта.
• Пропуск реальных ограничений, которые очевидны только после столкновения с прецедентами.
• Размытые границы объекта проекта, смешение с соседними объектами.
• Идеализированная аксиология, не учитывающая реальных конфликтов приоритетов.

Процесс

1. Зафиксируй исходное состояние знания. Явно перечисли, что ты уже считаешь известным о предметной области, и отметь, откуда это знание: личный опыт, учебники, конкретные работы, соавторы, training data ИИ. Это опорная точка для последующей проверки.

2. Предрегистрируй разведку (облегчённый Якорь 1). Сформулируй:

   • Какие вопросы о предметной области должны получить ответ до формулирования DNA.
   • Какие источники будут использованы для ответа.
   • Какой объём разведки считается достаточным (чтобы не уйти в бесконечный обзор).

3. Пять обязательных вопросов разведки:

   3.1. Онтологический вопрос. Какая карта предметной области фактически работает? Какие сущности реально существуют в практике, а какие — только в учебниках или в обобщающих формулировках? Как они связаны в реальных реализациях?

   • Применение Якоря 4: сверка с конкретными прецедентами, не с общими описаниями.
   • Признак успеха: ты можешь нарисовать схему сущностей, опираясь на 3+ независимых прецедента, а не на один учебник.

   3.2. Прецедентный вопрос. Какие проекты этого типа уже делались? Чем закончились? Какие у них были failure modes — не предполагаемые, а фактические?

   • Минимум: 3–5 прецедентов, включая хотя бы один неудачный.
   • Если все известные прецеденты успешны — это подозрительно: либо выборка смещена, либо область молода. Разобрать отдельно.
   • Признак успеха: список known failure modes с привязкой к конкретным кейсам, а не общими рассуждениями.

   3.3. Категориальный вопрос. Какие категории из training data ИИ могут быть перенесены в проект ошибочно? В каких местах агент «знает», как правильно, а на самом деле галлюцинирует или применяет чужой контекст?

   • Тест: попроси ИИ сформулировать типичную архитектуру для данной области. Проверь, соответствует ли она реальной практике известных проектов или обобщённому паттерну.
   • Признак успеха: список мест, где нужно явно запрещать ИИ опираться на training data без верификации.

   3.4. Конфликтный вопрос. Какие реальные конфликты приоритетов возникают в области? Какие аксиологические решения неочевидны? Где в прецедентах видны компромиссы между «скорость vs строгость», «новизна vs воспроизводимость», «охват vs глубина», «свобода vs совместимость»?

   • Источник: ретроспективы известных проектов, дискуссии на профессиональных форумах, разделы «Limitations» в статьях.
   • Признак успеха: набор реальных дилемм с описанием, как их решали другие (или не решали).

   3.5. Граничный вопрос. Где проходит граница объекта проекта относительно соседних объектов? В каких местах граница размыта, и как её провести так, чтобы это не оказалось натяжкой или расширением объёма по ходу?

   • Тест: попроси ИИ привести пример, который формально подпадает под твою постановку, но интуитивно тебе не нужен. Граница проходит там, где твоя интуиция расходится с формальной постановкой.
   • Признак успеха: явные критерии отсечения соседних объектов.

4. Облегчённая адверсариальная проверка (облегчённый Якорь 5). Для каждого ответа на вопросы 3.1–3.5 задай:

   • «Чем этот ответ может быть ошибочен?»
   • «Какой прецедент опроверг бы его?»
   • «Где я опираюсь на training data ИИ, а не на проверенный источник?»

5. Зафиксируй результат разведки в артефакте domain_scouting.md со структурой:

   # Разведка предметной области для [название проекта]
   
   ## Исходное состояние знания
   [Что считалось известным, источники этого знания.]
   
   ## Ответы на пять вопросов
   
   ### Онтологический
   [Карта сущностей с привязкой к прецедентам.]
   
   ### Прецедентный
   [Список проектов, итогов, failure modes.]
   
   ### Категориальный
   [Места, где training data ИИ ненадёжна.]
   
   ### Конфликтный
   [Реальные дилеммы аксиологии.]
   
   ### Граничный
   [Критерии отсечения соседних объектов.]
   
   ## Что изменилось по сравнению с исходным состоянием
   [Какие предположения не подтвердились. Какие инварианты проявились неожиданно.]
   
   ## Предварительные кандидаты на инварианты Project DNA
   [Черновой список по четырём слоям: онтология, деонтика, аксиология, праксеология.]
   

6. Предложи пользователю перейти к созданию Project DNA (скил project-dna, Режим 1), используя domain_scouting.md как опорный материал.

Объём разведки

Разведка — не полный научный цикл. Диапазон глубины:

• Лёгкий проход (1–2 сеанса): знакомая область, ясные прецеденты, автор уже работал рядом. Задача — эксплицировать неявное знание, а не добыть новое.
• Средний проход (несколько сеансов, возможно с паузами): область знакома в общих чертах, но конкретика прецедентов требует чтения. Нужен литобзор минимального объёма.
• Глубокий проход (отдельный подпроект на недели): область новая для автора, прецеденты противоречивы, риск ошибки высок. В этом случае разведка сама становится мини-исследованием и запускается по полному циклу research-with-ai (Режимы 1–5).

Критерий выбора глубины: если после лёгкого прохода ты не можешь ответить на все пять вопросов с опорой на конкретные прецеденты — увеличивай глубину. Пропуск этого шага означает, что Project DNA будет стоять на неустойчивом фундаменте.

Ретроспективное применение

Если Project DNA уже создан, но есть сомнения в обоснованности инвариантов:

1. Проведи разведку по пяти вопросам.
2. Сравни результат с текущим Project DNA.
3. Для каждого инварианта DNA, который не подтверждается разведкой, — либо найди подтверждение (и зафиксируй его), либо инициируй мутацию DNA (Режим 6 project-dna).
4. Зафиксируй в эпистемическом журнале, какие инварианты оказались обоснованными, какие — унаследованными без проверки.

Этот шаг болезненный, но необходимый: унаследованные инварианты без проверки — главный источник последующего дрейфа проекта.

Передача результата в project-dna

Результат Режима 8 — артефакт domain_scouting.md. Он становится входом для Режима 1 скила project-dna:

• Онтологический ответ → раздел «Доменная модель» Project DNA.
• Прецедентный ответ → раздел «Специфика предметной области» Project DNA.
• Категориальный ответ → раздел «Правила для AI-агента» Project DNA (явные запреты на опору на training data).
• Конфликтный ответ → раздел «Критерии качества» и «Приоритеты» Project DNA.
• Граничный ответ → раздел «Сущности» и «Фундаментальные разделения» Project DNA.

В итоге Project DNA становится не формулировкой «из головы», а кристаллизацией разведанного.

Ключевые правила

• Research DNA не содержит гипотез конкретных экспериментов, данных, результатов. Только инварианты.
• Research DNA всегда компактный (3–6 страниц).
• Research DNA мутирует только с согласия исследователя и с записью причины.
• ИИ-ассистент предлагает, не вносит изменения в DNA самостоятельно.
• Предрегистрация (Якорь 1) неизменяема — изменение требует явной мутации DNA или признания отклонения.
• Адверсариальная проверка (Якорь 5) — не опциональна. Без неё нет перехода к write-up.
• Факты из training data ИИ — гипотезы, не факты. Верификация обязательна.
• Моральная ответственность за результат — на человеке, всегда.
• Готовность сказать «не знаю» важнее готовности дать ответ.

Тест качества Research DNA

Тот же тест, что у Project DNA, но перенесённый на научный контекст:

Убери из Research DNA все технические детали реализации и конкретику текущей гипотезы. Остался ли смысл?

Если осталось «мы строго следуем методу Х при соблюдении таких-то условий» — это не DNA, это шаблон реализации.

Если осталось «мы считаем объектом исследования Y, различаем данные и артефакты по критерию Z, запрещаем ход W, приоритизируем строгость над скоростью, работаем через такие-то якоря истины» — это DNA.

Специфика работы с ИИ-ассистентом

Что ИИ делает в этой методологии

• Черновая генерация идей, гипотез, вариантов дизайна.
• Исполнение экспериментов и написание кода.
• Поиск и синтез литературы (с последующей сверкой Якорем 4).
• Визуализация и формализация результатов.
• Черновое написание текста (с последующей сверкой с журналом).
• Адверсариальная роль в Режиме 4 — в отдельной сессии.
• Аудит в Режиме 5 — в отдельной сессии.

Что ИИ НЕ делает

• Не формулирует Research DNA самостоятельно — только кристаллизует.
• Не мутирует DNA без согласия человека.
• Не выдаёт факты из training data за установленные факты.
• Не пропускает адверсариальную проверку.
• Не подменяет «я не знаю» правдоподобным ответом.
• Не несёт ответственности за публикацию.

Контуры обратной связи ИИ → человек

ИИ обязан эскалировать к человеку при:

• Конфликте задачи с инвариантом DNA.
• Обнаружении невозможности выполнить Якорь в текущих условиях.
• Ощущении «слишком хорошо» (странно быстрое схождение, слишком чистый результат).
• Расхождении между фактическим процессом и предрегистрацией.
• Обнаружении в журнале следов ретроактивного дрейфа.

Связанные скиллы

• project-dna — методика формулирования инвариантов проекта. Применяется после Режима 8 этого скила (разведка предметной области). Результат разведки domain_scouting.md становится входом для Режима 1 project-dna.
• peer-review — ревью исследования как критерий качества.
• literature-review — работа с источниками (питание Якоря 4).
• academic-writing — написание финального текста (после адверсариальной проверки).
• systems-analysis — аналитические операции внутри исследования.
• prd-coauthoring — формализация требований (применимо к задачам с продуктовым уклоном).

Антипаттерны (чего избегать)

1. DNA-теория. Написать красивую Research DNA и не операционализировать в RNA. Документ без применения — мертвый.

2. Мутация без следа. Тихое изменение формулировки гипотезы или критерия. Всегда оформляется как явная мутация с записью.

3. Адверсариальная проверка как формальность. Запустить Режим 4, получить список угроз, не провести тесты на исключение, признать результат валидным. Это хуже, чем не проводить проверку — создаёт иллюзию строгости.

4. Якорь 4 через одну ссылку. Сверить факт с одним источником — недостаточно. Якорь требует независимых источников.

5. Эпистемический журнал задним числом. Журнал — живой документ, ведётся в реальном времени. Реконструкция по памяти теряет именно те моменты, ради которых он нужен (дрейф, «слишком хорошо», отвергнутые альтернативы).

6. ИИ как единственный исполнитель адверсариальной роли. ИИ-критик ловит стандартные угрозы (baseline, утечки, значимость), но может пропустить предметно-специфичные. Человек в адверсариальной роли обязателен для работ с высокой ценой ошибки.

7. Отказ от мутации при явной необходимости. Если в процессе обнаружилось, что инвариант сформулирован неверно, но мутация кажется «признанием слабости» — и исследование продолжается с неадекватной DNA — это худший сценарий. Мутация с записью причины — это сила, а не слабость.

Критерий готовности исследования

Research-with-AI проект готов к внешнему рецензированию, если выполнены все условия:

1. ✅ Research DNA зафиксирован и актуален.
2. ✅ Research RNA операционализирует все инварианты DNA.
3. ✅ Каждый эксперимент предрегистрирован до исполнения.
4. ✅ Все численные результаты воспроизводимы в независимой среде.
5. ✅ Все фактические утверждения в тексте сверены с внешними источниками.
6. ✅ Адверсариальная проверка проведена, критические угрозы устранены или явно признаны как ограничения.
7. ✅ Значимость результата откалибрована относительно области.
8. ✅ Эпистемический журнал полон и согласован с финальным текстом.
9. ✅ Проведён DNA-аудит, расхождения разрешены.
10. ✅ Человек-исследователь подтверждает ответственность за публикацию.

Отсутствие любого пункта — не готовность. Не «готовность с оговоркой», не «в целом готово». Не готовность.