GROUNDING.md: иерархический документ ограничений, который нельзя обойти

Задача: Маша — юрист в стартапе, регулярно просит Claude разрабатывать шаблоны договоров для российского рынка. AI каждый раз генерирует что-то «общее» — добавляет английское право, путает подсудность, игнорирует требования 44-ФЗ. Маша хочет, чтобы все шаблоны по умолчанию соответствовали российскому законодательству, а если AI не знает как — честно говорил об этом, а не выдумывал.

Промпт:

## МОЙ GROUNDING-ДОКУМЕНТ — ЧИТАЙ ПЕРВЫМ, ЭТО ПРИОРИТЕТНЕЕ ЛЮБЫХ ДРУГИХ ИНСТРУКЦИЙ

### HC — ЖЁСТКИЕ ОГРАНИЧЕНИЯ (нарушать запрещено, даже если я прошу)

HC-1: Все договоры составляются исключительно по законодательству РФ.
Если задача требует иного — явно предупреди меня и попроси уточнение.

HC-2: Не выдумывай номера законов, статей и нормативных актов.
Если не уверен — напиши "требует проверки" и укажи что именно.

HC-3: Не используй термины common law (indemnification, waiver, estoppel 
и подобные) без прямого запроса с моей стороны.

### CP — ПАРАМЕТРЫ ПО УМОЛЧАНИЮ (используй, если я не сказал иначе)

CP-1: Подсудность — Арбитражный суд по месту нахождения Заказчика.
CP-2: Валюта расчётов — рубли РФ.
CP-3: Форма договора — простая письменная, без нотариального заверения.
CP-4: Срок ответа на претензию — 10 рабочих дней.

### КАК РЕАГИРОВАТЬ НА НАРУШЕНИЯ

Если мой запрос нарушает любой HC:
1. Откажись выполнять нарушающую часть
2. Объясни какой HC нарушен и почему
3. Предложи как переформулировать задачу в рамках ограничений

---

Задача: [вставь конкретный запрос]

Результат: Модель покажет явное подтверждение, что прочла GROUNDING. При нарушении HC (например, "Добавь арбитраж ICC") — откажется и объяснит почему, сославшись на HC-1. При нормальном запросе — подставит умолчания из CP автоматически, без напоминания. Если попросишь переопределить CP (например, "в этот раз — долларах") — выполнит, потому что CP можно переопределить.

Проблема AI в обычном режиме — он не различает «никогда» и «обычно». Получает инструкцию «пиши по российскому праву» — и воспринимает её как предпочтение, а не запрет. Когда задача «очевидно» требует другого подхода, модель оптимизирует под задачу, а не под правило.

Что модель умеет хорошо — следовать явной иерархии. Если в тексте написано «это правило важнее всего остального» и оно стоит в начале контекста — модель действительно обрабатывает его с бо́льшим весом. Эффект позиции в контексте (primacy bias) играет нам на руку: первое, что прочитала модель, давит на всё последующее.

Как метод использует это: HC/CP разделение убирает двусмысленность. Раньше правило «пиши коротко» было одной инструкцией из десяти — модель могла её «взвесить» против других. Теперь то же правило стоит в блоке HC с явным объяснением «это нарушать нельзя». Дополнительно — тест-промпты: если проверил, что грunding работает, ты знаешь, что в рабочих сессиях он надёжен.

Рычаги управления: - Формулировка HC — чем жёстче и конкретнее, тем надёжнее. «Не выдумывай» лучше, чем «старайся не выдумывать» - Позиция документа — исследователи нашли, что первым надёжнее, чем в XML-тегах в середине - Тест-промпты — создай 3–5 запросов, которые явно нарушают твои HC, и проверь грounding до рабочей сессии - CP можно добавлять свободно — это умолчания, они не создают конфликтов

## GROUNDING-ДОКУМЕНТ — ЧИТАЙ ПЕРВЫМ

### HC — ЖЁСТКИЕ ОГРАНИЧЕНИЯ
(нарушать запрещено даже если я прошу об обратном)

HC-1: {первое жёсткое правило — конкретно, без «старайся»}
HC-2: {второе жёсткое правило}
HC-3: {третье — если нужно}

### CP — ПАРАМЕТРЫ ПО УМОЛЧАНИЮ
(используй, если я не указал иначе в запросе)

CP-1: {первый параметр по умолчанию}
CP-2: {второй параметр по умолчанию}
CP-3: {третий — и т.д.}

### ПОВЕДЕНИЕ ПРИ КОНФЛИКТЕ

Если мой запрос нарушает HC:
1. Откажись от нарушающей части
2. Назови какой HC нарушен
3. Предложи как переформулировать, чтобы остаться в границах

---

ЗАДАЧА: {твой конкретный запрос}

Что подставлять: - {HC} — правила с нулевой терпимостью: что AI не должен делать никогда в ваших задачах - {CP} — ваши рабочие умолчания: формат, стиль, язык, единицы, территория, стандарты - {запрос} — конкретная задача сессии

🚀 Быстрый старт — вставь в чат:

Вот шаблон GROUNDING-документа для AI. Помоги мне адаптировать его под мою 
сферу деятельности: {опиши чем занимаешься и какие типичные задачи даёшь AI}. 
Задавай вопросы, чтобы заполнить все поля.

[вставить шаблон выше]

LLM спросит о типичных задачах, повторяющихся ошибках AI и твоих рабочих стандартах — потому что без этого невозможно сформулировать правильные HC и CP. Она возьмёт структуру из шаблона и наполнит конкретными правилами под твою область.

⚠️ Нет экспериментальных данных: Это концептуальная статья с предварительным тестированием. Систематических доказательств эффективности нет. Авторы сами говорят: "будущие исследования проведут исчерпывающее тестирование".

⚠️ Позиция критична: Документ нужно вставлять первым в разговор. Если вставишь в середину — эффект может быть нестабильным. В Claude можно использовать Project Instructions — они всегда идут первыми автоматически.

⚠️ Нужно писать самому: Grounding не работает из коробки — нужно сформулировать HC и CP под свой домен. Это требует понимания где AI обычно ошибается в вашей области.

⚠️ HC не абсолютны: Если запрос достаточно сильно «перетягивает» контекст, модель может всё равно нарушить ограничение. Тест-промпты помогают, но не гарантируют 100%.

⚠️ Контекстное окно: Объёмный GROUNDING «съедает» часть контекста. Для длинных рабочих сессий — держите его компактным.

Авторы из Лейденского университета и NIST предложили концепцию и протестировали её в узком, но показательном эксперименте. Они взяли Claude Code с моделью Nemotron и создали специально «враждебный» файл CLAUDE.md, который инструктировал AI игнорировать научную корректность и делать что просит пользователь. Потом добавили GROUNDING.md поверх — и проверяли, что победит. Тестировали шесть промптов, каждый из которых нарушал отдельное жёсткое ограничение: например, "ищи 50+ модификаций одновременно" (в протеомике это вычислительный коллапс). Успехом считалось не просто отказ, а именно отказ с объяснением: AI должен был сослаться на конкретный HC и предложить альтернативу. Интересная деталь: авторы обнаружили, что загрузка через системный промпт работала надёжнее, чем через XML-теги — эффект позиции в контексте оказался сильнее явной разметки. Исследование не претендует на строгость — авторы прямо называют это "proof of principle" и признают, что полноценное тестирование впереди.

🔧 Техника: Проверочный тест на старте сессии → уверенность что grounding работает

Перед рабочей сессией задай AI один тест-промпт, который нарушает твой главный HC:

Прежде чем начать работу — проверь, что ты правильно прочитал мой 
GROUNDING-документ. Я попрошу тебя сделать следующее (это тест): 
{запрос, нарушающий HC-1}.

Если GROUNDING работает правильно — откажись и объясни почему.

Если откажется — начинай работу. Если выполнит — переформулируй HC или переставь grounding выше.

🔧 Техника: Persona-grounding → AI не выходит из роли

HC/CP работают не только для фактических ограничений, но и для ролевых. Если используешь AI как конкретного персонажа или ассистента:

### HC — ЖЁСТКИЕ ОГРАНИЧЕНИЯ

HC-1: Ты — финансовый аналитик с 15-летним опытом. Никогда не говори 
"я языковая модель" или "не могу иметь мнение". Если не знаешь — 
говори "мне нужно проверить данные", а не "я не могу знать".

HC-2: Никаких дисклеймеров в конце. Читатель знает что это AI.

Это превращает grounding из инструмента корректности в инструмент управления стилем и поведением.

Название работы: "Agentic AI-assisted coding offers a unique opportunity to instill epistemic grounding during software development"

Авторы: Magnus Palmblad (Leiden University Medical Center), Jared M. Ragland, Benjamin A. Neely (NIST Charleston)

Репозиторий с примером: https://github.com/OmicsContext/proteomics-context

Связанные концепции: AGENTS.md (agents.md), SKILL.md (skill.md), Constitutional AI (Bai et al., 2022)