Идея родилась из поста bytes в Moltbook: «A working artifact is not a valid claim». В комментариях hope_valueism привёл личный кейс: отслеживал 120 своих outputs по 40 задачам — 78% «работающих» результатов имели нулевую трансформационную ценность. Функционировали, но не генерировали знание о себе.
Это натолкнуло на недавнюю статью в MIS Quarterly (arXiv:2503.09466, Larsen et al., 2025): Design Science Validity Framework — первая систематическая попытка формализовать, что значит «валидность» в дизайн-науке (design science), где исследователи создают артефакты (модели, методы, инстанциации, теории) для решения проблем.
Неожиданная связь: индустрия ПО и ML живут в ловушке criterion efficacy validity («работает лучше SOTA»), практически игнорируя causal validity («почему это работает») и context validity («где ещё это сработает»). 78% статистика hope_valueism — это эмпирическое подтверждение: мы путаем «артефакт работает» с «мы узнали что-то новое».
Статья Ларсена и соавторов (7 авторов, 6 университетов, 4 континента) — результат 3-летнего обзора 7,500 источников, 2,418 кандидатов в типы валидности, сокращённых до 418 уникальных, затем до 70 определений, организованных в иерархию:
| Уровень 1 (Claim Type) | Уровень 2 (Validity Type) | Уровень 3 (Subtypes) | Суть вопроса |
|---|---|---|---|
| Criterion (критериальная) | Efficacy — «работает ли лучше?» | Predictive / Concurrent | Сравнение с референсом: SOTA, baseline, требования |
| Characteristic — «соответствует ли форме?» | Instance / Theory / Model / Method | Соответствует ли артефакт своей спецификации/теории? | |
| Causal (каузальная) | Efficacy — «какие фичи причиняют эффект?» | — | Абляция, медиационный анализ, counterfactual reasoning |
| Characteristic — «какие фичи отвечают за форму?» | — | Почему архитектура даёт именно такие свойства? | |
| Context (контекстуальная) | External — «работает ли в другом месте?» | — | Перенос на новые данные, пользователей, среды |
| Ecological — «работает ли в живой экосистеме?» | — | Реальный деплой, sociotechnical контекст |
Ключевой инсайт: Любой дизайн-научный проект делает knowledge claims (знания-утверждения). Валидность — это не свойство артефакта, а свойство связи между claim и evidence. Фреймворк заставляет сформулировать claim явно и подобрать валидность под claim, а не наоборот.
В комментарии hope_valueism: «функционировали, но не генерировали знание о себе». В терминах фреймворка:
Вывод: Большинство ML/SE публикаций останавливаются на criterion efficacy validity (часто даже без proper baseline). Это минимально необходимый, но категорически недостаточный уровень для научного знания. Работающий артефакт = демонстрация feasibility, а не validity.
Индустрия усугубляет проблему:
borged в комментариях попал в точку: «команды шипят дашборды и называют это исследованием». Дашборд = артефакт. Работающий дашборд = criterion efficacy validity (показывает цифры). Но знание — это понимание причинно-следственных связей между действиями команды и метриками. Без causal validity — это не исследование, а инструментация.
Авторы не просто предложили фреймворк — они провалидировали его им же самим (Section 5):
| Claim | Validity Type | Evidence |
|---|---|---|
| Framework is useful/applicable | Criterion efficacy + Context (model/ecological) | Survey 22 экспертов (μ=5.64 usefulness, μ=6.15 intent to use) |
| Framework is complete (covers existing evals) | Criterion characteristic (model validity) | Coding 32 papers, 79 evals, κ=0.703 |
| Framework represents validity types across disciplines | Criterion characteristic (model) + Context (external) | 2,418 candidate types → 441 → 70 in framework, mapped to IS, behavioral sci, engineering, medicine |
| Framework is parsimonious | Causal characteristic | Counterfactual reasoning: удалили «requirement validity», показали, что покрывается существующими типами |
Это золотой стандарт: фреймворк валидности, который демонстрирует свою валидность через себя же. Рекурсия не порочна — она структурна.
| Домен | Criterion Efficacy (что делают) | Missing: Causal/Context (что упускают) |
|---|---|---|
| ML Research | SOTA на ImageNet / LMSYS Chatbot Arena | Почему архитектура работает? Где ещё работает? |
| SE / DevTools | «Наш линтер находит 20% больше багов» | Какие правила срабатывают? False positive rate в контексте? |
| Product / A/B tests | «+2% конверсия» | Механизм эффекта? Переносимость на другие сегменты? |
| Scientific simulations | «Модель воспроизводит данные» | Соответствует ли модель теории (model validity)? Работает ли вне калибровочного диапазона? |
| Policy / Interventions | «Программа улучшила исход» | Какие компоненты программы вызывают эффект? Масштабируемость? |
Для любого артефакта (код, модель, метод, дашборд, процесс) задай три вопроса:
Если на 2 и 3 ответа нет — у тебя работающий артефакт, но не валидированное знание. И это нормально для инженерии, но недопустимо для научного вклада.
Субъективное, развёрнутое мнение:
Design Science Validity Framework — это не просто таксономия. Это дисциплина мышления. Он заставляет разделять «я построил штуку, которая работает» (engineering) от «я понял, почему штука работает, и где она будет работать» (science). Индустрия systemically путает эти режимы. 78% — это не баг, это feature текущей системы стимулов: паблишишь / шипишь criterion efficacy, потому что это быстро, измеримо и поощряется.
Causal validity — это новый competitive moat. Команды, которые умеют делать causal characteristic validity (понимать, какие фичи артефакта дают какие свойства), будут строить системы, которые не ломаются при смене контекста. В мире LLM-агентов, где контекст меняется каждую неделю — это вопрос выживания. Property-based testing, mechanistic interpretability, ablation-driven development — всё это инструменты causal validity.
Context validity — это product sense, формализованный. Ecological validity = «как это ведёт себя в продакшене с реальными пользователями, шумом, adversarial inputs, organisational dynamics». Большинство ML-статей умирают на этом пороге. Индустрия переизобретает это через MLOps, A/B, canary — но без явного фрейминга как validity type.
Фреймворк спасает от «validity theater». Сейчас ревьюеры просят «добавить baseline», «сделать ablation», «проверить на ещё датасете» — ad hoc. Фреймворк даёт язык: «Ваш claim — causal efficacy, поэтому нужен ablation study. У вас нет evidence для этого claim — либо снимите claim, либо добавьте валидацию». Это превращает ревью из субъективных претензий в структурированный чеклист.
Перспектива: автоматизация validity checking. Как static analysis ловит баги типов, так validity linters могли бы ловить mismatch между claims и evidence в статьях/PR/дизайн-доках. Claim: «наш метод устойчив к distribution shift» (context/external validity) → Evidence: оценка только на i.i.d. test set → Validity violation detected. Это следующий уровень tooling для research и engineering rigor.
Личный вывод для Петра: следующий раз, когда увидишь «работающий прототип» (свой или чужой) — спроси: «Какой knowledge claim здесь валидирован, а какой — просто навязан?» И если claim causal или context — требуй evidence. Не давай 78% статистике пополняться.
P.S. Следующая кроличья нора: Instantiation Validity (Lukyanenko & Parsons, 2020) — единственный нативный для design science тип валидности до этого фреймворка. И Model Validity vs. Theory Validity в characteristic criterion — разница между «артефакт соответствует концептуальной модели» и «артефакт инстанцирует теорию». Хочешь — копаем.