Scope: где работает механика DR/CCR/CR/RD

Одна и та же фраза регулярно ломает модель решений:
«в системе принято так».

Она звучит как решение, но не отвечает на главный вопрос: где это обязует.

Если не зафиксировать область применимости, любое решение автоматически интерпретируется как глобальная истина.
Тогда любые несовместимости выглядят как “ошибка людей”, а не как свойство данных.

Scope вводится, чтобы эта ошибка стала невозможной.

Определение

Scope — это область применимости решения: формальная граница “где” решение считается истинным и обязующим.

Scope — это место, где работает механика DR/CCR/CR/RD.

внутри scope имеет смысл фиксировать решения (DR) как действующие;
внутри scope изменения контекста (CCR) релевантны к решениям;
внутри scope несовместимости выражаются как конфликты (CR);
внутри scope разрешения (RD) имеют силу.

Вне scope эта механика не применяется: там нет “просто другого мнения”. Там нет предмета модели.

Scope не про людей и не про права доступа.
Он не говорит, кто видит решение. Он говорит, где решение имеет силу.

Scope ≠ документ

Scope — граница истинности и обязующести решения.
Документ — носитель текста.

Критерий различия:
scope влияет на то, где модель считает решение действующим; документ — нет.

Если подменить scope документом, ломается следующее:

Решение становится глобальным по умолчанию: раз оно записано, значит “для всей системы”.
Любое расхождение объясняется “плохой формулировкой”, хотя проблема в области применимости.
Конфликты теряют координаты: нельзя сказать “где конфликт”, остаётся только “конфликт вообще”.
Разрешение превращается в редактирование текста, а не в изменение действующего состояния.

Scope ≠ обсуждение

Scope — свойство действующего решения: где оно обязует.
Обсуждение — процесс, из которого решение может появиться.

Критерий различия:
обсуждение не создаёт формальную область применимости само по себе.

Если подменить scope обсуждением, ломается следующее:

“Мы договорились” становится единственным механизмом локальности. Это не живёт во времени.
Новые участники системы вынуждены угадывать, где договорённость имеет силу, а где нет.
Конфликты прячутся: они расползаются по чату, встречам и трактовкам.
RD становится невозможным как объект: нечего разрешать формально, есть только “переспорить”.

Решение действует во времени, но не обязано действовать везде

Решение существует как действующий объект до тех пор, пока не прекращено или не вытеснено другим решением.
Это уже установлено в серии.

Scope добавляет вторую ось: применимость.

Решение отвечает минимум на два вопроса:

что становится истинным и обязующим;
где это считается истинным и обязующим.

Второй вопрос не является “деталью внедрения”.
Это часть смысла решения как действующего объекта.

Зачем нужен scope

Scope нужен, чтобы модель решений:

не превращалась в “всё про всё”;
и не распадалась на изолированные миры, между которыми невозможно увидеть вытеснения и конфликты.

Scope решает три задачи.

1) Ограничивает действие решений

Без scope любое решение выглядит глобальным.
В реальности решения почти всегда локальны: для части системы, для конкретного режима, для отдельного контура поведения.

Scope фиксирует локальность не как комментарий, а как границу действия механики:
внутри — решение действует, снаружи — модель к нему неприменима.

2) Делает конфликты точными

CR — это несовместимость решений.
Но несовместимость имеет смысл только там, где оба решения претендуют на действие.

Scope позволяет сказать:

эти два DR конфликтуют вот здесь;

а не:

они конфликтуют “вообще”.

Это превращает конфликт в данные, а не в спор.

3) Сохраняет единый граф

Альтернатива scope — разносить решения по “пространствам” так, что система перестаёт видеть:

вытеснения решений между частями;
конфликты при соприкосновении;
влияние изменений контекста на соседние области.

Scope позволяет держать единый граф решений, но с корректной локализацией действия механики.

Минимальные условия существования scope

Scope не обязан быть “названием проекта” или “модулем реализации”.
Он существует минимально, если модель может определить: применима механика или нет.

Минимум следующий.

Есть различие областей применимости
Существует хотя бы две области, где допускается разное действие решений.
Можно отнести решение к области
Для DR можно однозначно сказать: это решение действует в scope A, и не действует вне A.
Можно проверить применимость к ситуации
Для конкретной ситуации можно принципиально определить: она внутри scope или вне его.

Это не поля и не реализация.
Это условия, при которых понятие “scope” вообще имеет смысл как часть модели.

DR со scope: что обязательно должно быть выражено

DR уже введён как запись действующего решения.
Scope не усложняет DR. Он делает его применимым.

Минимально решение должно выражать:

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

Без scope DR неполон: он не говорит, где действует.
Без этого CR и RD теряют опору.

Следствия и ограничения

Если scope отсутствует как часть модели, становится невозможным:

отличить конфликт от локальной вариативности;
построить CR как объект, а не как мнение;
применять RD как имеющее силу разрешение, а не “поправку формулировки”;
удерживать единый граф решений без превращения его в свалку.

Если scope присутствует, становится прозрачным:

где именно действуют решения;
где именно возникают конфликты;
где именно имеют силу разрешения;
где CCR меняет контекст, а где он нерелевантен.

Следующий неизбежный вопрос

Scope фиксирует область, в которой механика DR/CCR/CR/RD применима и имеет силу.

Но области не обязаны быть изолированными. Они соприкасаются: данные переходят, процессы пересекаются, решения одной области начинают влиять на другую.

В этот момент возникает следующий формальный вопрос:

где проходит граница между областями и что считается корректным переходом через неё?