D06 · Руководство по работе с доменом

Как определить, что изменение относится к D06

D06 — чему и как учат (норма-эталон). Не путать с D04 (что произошло) и D05 (с кем).

Ситуация	Домен
Кафедра разрабатывает учебный план под новый ФГОС	D06
Преподаватель пишет РПД (результаты обучения, формы контроля)	D06
Преподаватель готовит лекции и задания по РПД	(контент-слой D06, отдельно)
Студент сдаёт экзамен, оценка попадает в ведомость	D04
Утверждается матрица компетенций	D06
Студент зачислен в набор 2026 года	D05
Меняется состав строк учебного плана	D06 (новая версия)
Студент выбирает дисциплину вариативной части	D04 (факт траектории)

Правило: если меняется эталон (что должно быть изучено) — это D06. Если фиксируется факт (что реально освоено) — это D04.

Три уровня иерархии нормы

ЛИЦЕНЗИОННАЯ ПОЗИЦИЯ (D02)
  уровень + направление + квалификация — стабильно, ФГОС не трогает
        │
        ↓
ОПОП-манифест (D06)
  лицензионная позиция + ФГОС + форма обучения
        │
        ↓
ВЕРСИЯ ОПОП (D06)
  снимок ссылок на компоненты; новая версия — по изменению компонента
        │
        ↓
УЧЕБНЫЙ ПЛАН + РПД + ФОС + компетенции (D06, компоненты версии)
        │
        ↓ (пин по году набора, в D05)
НАБОР (D05) → когорта доучивается по своей версии

Что меняется, что нет

Изменение	Эффект
Смена ФГОС	Новая Версия ОПОП; старые наборы — по своей версии
Правка РПД	Новая Версия ОПОП (компонент изменился)
Изменение формы обучения / профиля	Новая ОПОП (это часть идентичности манифеста)
Ежегодное переутверждение без правок	Новое utverzhdenie_id, та же логическая версия
Закрытие набора	Статус «закрыта-для-набора»; версия не отменяется

Граница D06 ↔ D04: норма vs реализация

РПД (что должно быть изучено и как оценивается) — норма, живёт в D06. Учебно-методический контент (конкретные лекции, задания, кейсы), рождающийся из РПД, — это контент-слой (тоже D06, но отдельный слой, наполняется позже).

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

Граница D06 ↔ D02: норма vs право

D02 (лицензия) разрешает учить по направлению/специальности в определённой форме и по адресу. D06 (ОПОП) реализует это право под конкретный ФГОС. ОПОП вне границ лицензии — невалидна (инвариант 1). Смена ФГОС в лицензии не отражается — лицензия про право, не про стандарт.

План учебных событий — два уровня

Норма-ось описывает не только «чему учить», но и какие события будут проверять освоение. Это второй фундаментальный слой D06 (после ОПОП и компонентов).

Единый план формируется в двух местах:

• В РПД / РПП — план событий внутри дисциплины: занятия (лекции, семинары, практики, лабы), модульные контроли, промежуточная аттестация.
• В строках УП — план событий уровня программы: экзамены, зачёты, курсовые, ГИА. Формы, стоящие в столбце «промежуточная аттестация» строки УП, — это тоже запланированные учебные события.

Из доклада «Цифровая инфраструктура вуза» §4:

«Учебный план и рабочие программы — это ещё и план учебных событий. Именно на этапе редактирования РПД и РПП методист определяет, какие события будут проходить внутри дисциплины.»

Расписание (D14) не создаёт события — оно их разворачивает. Берёт готовый план из D06 и накладывает на сетку ресурсов. Один слот расписания может покрывать 1..N запланированных событий D06 (пример: слот пары содержит и само занятие, и модульный контроль темы — с разными правилами формирования состава).

Форма контроля — норма vs факт

Форма контроля живёт в D06 как норма (§1.11 entities.md): описание того, что и как проверяется («модульный контроль темы 3, вес 30, порог 60%»). Три оси классификации:

• role_in_rating — обязательная (для порога) / повышающая (сверх порога)
• assignment_mode — назначается всем / индивидуально
• time_model — inline (укладывается в событие) / extended (переживает событие)

Конкретные попытки проверки — факт, живёт в D04 (5 фактов: assignment → launch → attempt → submission → evaluation). Одна норма D06 порождает множество фактов D04.

Пакет занятия — «картридж»

Пакет — манифест события (§1.13 entities.md). Аналогия из §7 доклада:

«Картридж один: с определённым содержанием, определённой формой, определёнными правилами. А в какую приставку его вставили, кто играет и когда — это уже контекст, который в самом картридже не хранится.»

Пакет знает о норме (дисциплина / тема / вид / формы контроля / материалы / gates), но НЕ знает о runtime-контексте (группа / дата / преподаватель). Один пакет используется на десятках занятий у разных групп, разных лет, разных преподавателей.

Три источника данных пакета (base + overlay + runtime): - base — автоматически из ИС (РПД, компетенции, литература) - overlay — правки педагога (цели именно этого занятия, материалы, задания) - runtime — контекст запуска (подставляется LMS в момент проведения)

РПД как Двойник — норма vs реализация форм

РПД (§1.6 entities.md) формализована машиночитаемо как единый JSON-объект («Двойник»), одновременно обслуживающий заполнение, проверку, печать и обратное восстановление (standards/rpd/). Ключевое разведение:

• Норма — standards/rpd/schema/ (контракт) + standards/rpd/data/ (эталонный шаблон) + fieldRegistry (реестр 91 реквизита с применимостью по уровню). Живёт в стандарте, версионируется как часть версии ОПОП (§1.2).
• Реализация — блоки forms / print / reverseImport внутри Двойника: как конкретная система рисует форму, собирает печатный документ, разбирает загруженный Word/PDF обратно. Референс — best-practices/rpd-forms-print/.

derived-поля read-only — трудоёмкость и формы контроля РПД не хранит, а проецирует из строки учебного плана (§1.4 → §1.11 Форма контроля). Правка часов или форм контроля — только через учебный план; иначе два источника истины разойдутся.

Один реестр — много проекций. Технические (rpd-fields.md) и человекочитаемые (rpd-fields-guide.md) таблицы реквизитов генерируются из fieldRegistry шаблона — не редактируются вручную.

Компетенции: откуда берутся

УК / ОПК и ПК — два разных механизма, не одна таблица (§1.8 entities.md).

• УК / ОПК не хранятся в D06. Живут внутри документа ФГОС (standards/fgos/data/*.json), адресуются напрямую двойкой (fgos_id, kod). Проверено на реальных данных: индикаторы внутри ФГОС всегда пусты — стандарт не задаёт их, только формулировку компетенции.
• ПК — хранимая D06-сущность. Устанавливает ОО на основе профстандарта; существует только в контексте версии ОПОП. Естественный ключ — (versiya_opop_id, kod), не UUID.

Индикаторы — всегда хранимая D06-сущность (§1.9 entities.md), независимо от типа компетенции. ФГОС индикаторов не задаёт — это исключительно авторская работа ОО, привязанная к версии ОПОП. Естественный ключ — (versiya_opop_id, kod). Происхождение (proishozhdenie) — отдельный дискриминированный атрибут, не часть ключа: для УК/ОПК ссылается прямо на (fgos_id, kod), для ПК — на локальную строку компетенции (§1.8) в той же версии ОПОП.

Дескрипторы результата освоения (§1.10 entities.md) — разработчик РПД формулирует вручную, ссылаясь на конкретный индикатор. Это единственная точка входа в норму: карточка занятия и ФОС ссылаются на дескриптор, не на индикатор напрямую.

Матрица компетенций — вычисляемый вид, не хранилище. Собирается агрегацией дескрипторов всех РПД версии ОПОП («строка плана × компетенция»). Хранимой M:N-таблицы «индикатор ↔ строка плана» в модели нет — источник правды лежит в дескрипторах и индикаторах.

Инвариант полноты: каждая компетенция покрыта хотя бы одним дескриптором; каждый индикатор обеспечен хотя бы одним оценочным средством в ФОС. Пробел в вычисленной матрице — дефект ОПОП, который всплывёт при аккредитации (D02).

Типовые ошибки

ОПОП моделируется как папка с файлами. ОПОП — это запись-манифест со ссылками на версии компонентов. Документы генерируются из неё, не наоборот.

Версия рождается по календарю (каждый год). Версия рождается только по изменению компонента. Не было правок — версия та же, новый набор пинится к существующей.

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

Правка утверждённой версии. Версия неизменна. Любая правка — следующая версия (только вперёд).

УК/ОПК переписывают локально. Они импортированы из ФГОС и неизменяемы. Локально ОО устанавливает только ПК.

УК/ОПК заводятся как локальная D06-строка «на всякий случай». Ошибка: скопировать компетенцию из ФГОС в свою таблицу, чтобы «было удобнее ссылаться». Компетенция УК/ОПК не хранится в D06 вообще — адресуется напрямую (fgos_id, kod). Копия — это дублирующий источник истины: при перевыпуске редакции ФГОС копия и оригинал разойдутся.

Индикатор ищет компетенцию в документе ФГОС. Ошибка: пытаться найти формулировку индикатора внутри standards/fgos/data/*.json. Там их нет и не будет — индикаторы всегда авторская работа ОО, живут только в версии ОПОП (§1.9).

Матрица компетенций хранится как отдельная M:N-таблица. Ошибка: заводить хранимую связь «индикатор ↔ строка плана» рядом с дескрипторами РПД. Правильно: единственный источник правды — дескриптор результата освоения (§1.10); матрица — вычисляемый вид над ним, не отдельное хранилище.

Событие или ФОС ссылаются на индикатор ФГОС напрямую. Ошибка: пропустить дескриптор РПД и сослаться прямо на индикатор нормы. Тогда при перевыпуске редакции ФГОС придётся править ссылки во всех потребителях. Правильно: дескриптор — единственная точка входа; потребители ссылаются на него.

Планирование событий в расписании D14. Ошибка: заводить учебные события прямо в расписании (D14). Правильно: события планируются в РПД/УП (D06). Расписание только назначает им время, аудиторию, преподавателя. Если события в РПД нет — оно не появится и в расписании.

Пакет хранит состояние студентов. Ошибка: складывать в пакет прогресс, оценки, факт прохождения gate. Пакет стейтлесс — всё это в D04. При запуске пакет спрашивает D04: «эти gate уже пройдены?».

Форма контроля правится задним числом на фактах. Ошибка: изменить норму D06, чтобы «поправить» уже поставленные оценки. Норма меняется только вперёд (новая версия РПД); прошлые факты — только через сторно в D04.

Проекции реестра РПД редактируются вручную. rpd-fields.md и rpd-fields-guide.md — генерируются из fieldRegistry эталонного шаблона (standards/rpd/data/). Правка руками рассинхронизирует проекции с реестром; править нужно реестр и пересобирать таблицы.

Периодичность контрольных действий

Действие	Когда
Сверка объёма УП с ФГОС	При создании версии
Проверка полноты матрицы компетенций	Перед утверждением ОПОП и перед аккредитацией
Актуализация под изменения ФГОС/профстандартов	При выходе нового НПА
Проверка границ лицензии (D02)	При создании новой ОПОП