/research-proposal

Роль: Главный исследователь (эталонный план) Положение в конвейере: середина цепочки

Превращает синтезированный пробел и теоретическую рамку в финансируемый, рецензируемый эталонный план. Этическая осуществимость поднимается с самого начала, а план предварительной регистрации и выбор руководства по отчётности фиксируются до того, как будет операционализирован любой план исследования.

Канонический вызовCopy Anchor Link

/research-proposal

С аргументами:

/research-proposal [--suite-name NAME] [--override] [--guideline NAME] [--prereg-registry NAME] [--call PATH] [--resubmission PATH]

Входные данныеCopy Anchor Link

Файл набора _inputs/synthesis.md (карта SOTA + анализ пробела) и _inputs/theory.md (концептуальная рамка).

С --call — текст конкурса финансирующей организации, в виде пути к файлу или - для вставленного текста; предоставленный текст — единственный источник требований финансирующей организации. С --resubmission — критика финансирующей организацией более ранней заявки, и синтез или теория не нужны (см. ниже).

Выходные данныеCopy Anchor Link

_inputs/proposal.md (иерархия SMART-целей, оценка осуществимости, реестр ресурсов / графика / рисков с его запасными планами, путь влияния, план предварительной регистрации, план управления данными и обмена ими и предварительный выбор руководства по отчётности EQUATOR).

С --call — также _inputs/call-requirements.md (матрица требований конкурса). С --resubmission — _outputs/resubmission-response.md вместо предложения.

Ниже по потокуCopy Anchor Link

/research-design (потребитель ниже по потоку — операционализирует предложение в замороженный, предварительно зарегистрированный план исследования).

Фазы рабочего процессаCopy Anchor Link

Команда следует стандартному рабочему процессу конвейера /research:

1. Загрузить контекст — Прочитать _inputs/synthesis.md и _inputs/theory.md, правила и любое существующее состояние набора.
2. Построить иерархию SMART-целей — Превратить пробел в конкретные, измеримые, достижимые, релевантные и ограниченные во времени цели.
3. Оценить осуществимость и риск — Построить реестр ресурсов / графика / рисков; дать каждому риску, затрагивающему достижимость цели, запись запасного плана и подвергнуть стресс-тесту стоящее за ней решение; сверить все предоставленные статьи затрат; поднять этическую осуществимость с самого начала.
4. Спланировать предварительную регистрацию, данные и отчётность — Выбрать реестр, составить план предварительной регистрации, зафиксировать план управления данными и обмена ими и предварительно выбрать руководство по отчётности EQUATOR.
5. Отобразить путь влияния — Проследить, как цели, будучи достигнутыми, производят влияние ниже по потоку.
6. Проверить и выпустить — Подтвердить, что цели проверяемы, а план воспроизводим; выпустить _inputs/proposal.md плюс манифест передачи.

Предоставленный конкурс финансирующей организацииCopy Anchor Link

С --call текст конкурса определяет форму предложения. Стадия записывает матрицу требований в _inputs/call-requirements.md, по одной строке на требование (раздел, ограничение, критерий допуска, приложение, критерий рецензирования или политика) с разделом предложения, который на него отвечает, его местом в черновике оператора и статусом met, partly-met, gap или operator-owned. Каждый критерий рецензирования — это строка, поэтому каждая цель прослеживается до критерия, на который она отвечает; ни одному критерию не присваивается вес, и не делается никаких заявлений о шансах на финансирование.

• Сначала политика использования инструментов. Политика конкурса в отношении автоматизированных инструментов разрешается до того, как будет написан какой-либо текст: разрешено, разрешено с раскрытием (составляется заявление об использовании инструментов) или ограничено. При ограничительной политике стадия останавливается после матрицы и возвращает решение оператору. Если конкурс умалчивает о политике, о ней спрашивают, а не предполагают.
• Ни памяти, ни бюджета. Требование, ограничение, дата, ставка или предел финансирующей организации берутся из предоставленного текста или от оператора, а не из памяти. Стадия не строит бюджет: она проверяет статьи затрат оператора, и статья, не прослеживаемая ни до одной цели, — это orphan, цель без ресурсного обеспечения — unresourced, а итог, который не сходится, — unreconciled.
• Никакого повествования для финансирующей организации. Стадия выпускает эталонный план, а не прозу о значимости или подходе. Команда, биографии, оснащение, письма поддержки и текущая и ожидаемая поддержка — это строки operator-owned, которые никогда не составляются.

Режим повторной подачиCopy Anchor Link

--resubmission PATH отвечает на критику финансирующей организацией более ранней заявки, вне тринадцатиэтапной цепочки. Шлюз последовательности не применяется, а манифест передачи остаётся нетронутым. Оператор предоставляет критику, текст конкурса (--call), заявку в поданном виде и пересмотренный черновик, а стадия записывает _outputs/resubmission-response.md из трёх частей:

• Допуск и ограничения — Прочитать из текста конкурса, разрешена ли повторная подача, сколько их допускает конкурс, срок и ограничения на ответ и пересмотренную заявку. Правило, которое текст оставляет неуказанным, запрашивается у оператора; без текста конкурса ответ не может достичь ready.
• Матрица пересмотра — По одной строке на замечание критики, пронумерованной так, как нумерует финансирующая организация: процитированное замечание, действие (changed, clarified или declined), место пересмотра, научное следствие, любой нерешённый вопрос и статус answered, partly-answered или not-answered, подкреплённый пересмотренным текстом. Отклонённое замечание несёт свою причину и доказательства.
• Проверка распространения — Проследить каждую строку changed до каждого элемента плана, которого она касается: целей, методов, графика, статей бюджета, плана данных и реестра рисков. Элемент, которого касается изменение, но который пересмотренный черновик оставляет неизменным, — это unpropagated.

Ответ находится в состоянии ready, когда каждая строка answered или несёт принятый оператором остаточный риск, ни один элемент не unpropagated и каждое ограничение конкурса соблюдено. Ответ, которому нужны новые доказательства, возвращается оператору, который направляет его в /research-design или /research-experiment. Подаёт оператор.

Нижняя граница строгостиCopy Anchor Link

Амбиция целевой площадки задаёт не только выбор руководства по отчётности, но и глубину нижней границы строгости, которую должны преодолеть нижестоящие этапы проектирования и эксперимента, — нижнюю границу воспроизведения, паритет бюджета, настройку на непересекающихся разбиениях и значимость с размером эффекта, — плюс пакет доказательств воспроизводимости, который понесёт результат.

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

Режимы отказаCopy Anchor Link

ПримерыCopy Anchor Link

# Превращает пробел в финансируемый эталонный план
/research-proposal --suite-name retrieval-latency

# Закрепляет руководство по отчётности и реестр предварительной регистрации
/research-proposal --guideline PRISMA --prereg-registry OSF

# Отображает конкурс финансирующей организации на эталонный план
/research-proposal --suite-name retrieval-latency --call funder-call.md

# Отвечает на критику финансирующей организацией более ранней заявки
/research-proposal --resubmission critique.md --call funder-call.md

Перекрёстные ссылкиCopy Anchor Link

• Обзор конвейера
• Справочник команд