Разделение обязанностей

Разделение обязанностей — ключевой доменный инвариант ESGmetrics: тот, кто внёс значение показателя, не может сам же его верифицировать. Подтверждает данные другой человек с ролью Аудитора. Это правило обеспечивает достоверность ESG-аудита: результат заслуживает доверия только тогда, когда автор данных и их контролёр — разные люди. Барьер встроен в платформу и срабатывает автоматически, поэтому понимание этого правила избавит вас от неожиданных отказов доступа и поможет правильно организовать работу команды.

Зачем нужно разделение обязанностей

Достоверность ESG-аудита требует независимой проверки. Если бы автор значения мог сам присвоить ему статус «проверено», верификация теряла бы смысл — это самозаверение. Поэтому платформа разводит две роли:

• ввод данных и свидетельств выполняет Аналитик;
• верификацию (присвоение статуса достоверности) выполняет другой человек с ролью Аудитора.

Совпадение автора и верификатора запрещено — даже для Администратора. Право верификации (verify_data) есть только у ролей Аудитора и Администратора, а право ввода (enter_data) — только у Аналитика и Администратора. Но наличия права недостаточно: дополнительно проверяется, что верифицирующий не является автором значения.

Как это видно по матрице прав

В матрице прав у Аналитика есть пункт «Ввод данных и свидетельств», но нет «Верификации данных»; у Аудитора — наоборот. Ни одна роль не получает оба права на одно и то же значение одновременно. См. Роли пользователей.

Как это работает на практике

Типовой сценарий пары Аналитик–Аудитор выглядит так:

1. Аналитик создаёт оценку и вносит значения показателей с приложенными свидетельствами (см. Ручной ввод и Свидетельства).
2. Данные передаются на проверку.
3. Аудитор открывает значения и подтверждает либо отклоняет их (см. Верификация).

Если автор данных попытается подтвердить их сам — тем же аккаунтом — система заблокирует действие и вернёт отказ доступа, даже если у пользователя формально есть право верификации. Барьер «не автор» проверяется по автору значения, которое хранится за каждой строкой данных.

Дополнительные ограничения верификации

Подтвердить можно только актуальное значение, не находящееся в карантине: исключены значения со статусами «в карантине» и «отклонено», а также вытесненные (замещённые более новой версией). Попытка верифицировать такое значение тоже не пройдёт. Это отдельный слой защиты сверх барьера «не автор».

Связь с карантином

Спорные или некорректные значения уходят в карантин и разбираются тем, кто их не вносил — действует тот же барьер «автор ≠ проверяющий». Валидация при этом не «чинит» данные молча: некорректные значения не подменяются средним, а отправляются на ручной разбор. Подробнее — Валидация и карантин.

Прослеживаемость как основа барьера

Барьер работает потому, что для каждого значения хранится полная история: источник, автор, дата и время, выполненные преобразования и приложенные свидетельства. Именно зафиксированный автор позволяет системе однозначно определить, кто внёс значение, и не дать ему же его верифицировать. Эта прослеживаемость (data lineage) — обязательное доменное требование.

Статусы достоверности

При верификации значению присваивается один из статусов достоверности: «не проверено», «самооценка» или «внутренняя проверка». Внешнее заверение — функция Фазы 2. Достоверным считается любой статус, кроме «не проверено».

Почему это важно для ESG-балла

В ESG-балл попадают только достоверные значения — со статусом «самооценка» или «внутренняя проверка». Значения в статусе «не проверено» либо исключаются из расчёта, либо учитываются с понижающим коэффициентом, поэтому статус верификации напрямую влияет на итоговый результат. Самооценку автор ставит своим данным сам, и она засчитывается как достоверная; барьер «не автор» касается только внутренней проверки — независимого подтверждения. См. ESG-балл и Шкала скоринга.

Как организовать команду

• Заведите минимум двух пользователей: одного с ролью Аналитик, другого — с ролью Аудитор.
• Не пытайтесь совмещать ввод и проверку в одном аккаунте «для скорости» — верификация будет заблокирована.
• Если в команде один человек, он может сам поставить своим данным самооценку (кнопка «Поставить самооценку» под значением на шаге 5) — она засчитывается в балл как достоверная. Независимым подтверждением это не будет: для внутренней проверки нужен второй сотрудник с ролью Аудитора.

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

Частые ошибки

• Аналитик подтверждает собственные данные тем же аккаунтом. Система вернёт отказ доступа — это нарушение разделения обязанностей, а не сбой.
• Совмещение ввода и проверки в одной учётной записи. Приводит к блокировке верификации и снижает доверие к результату.
• Ожидание полного вклада данных в статусе «не проверено». Пока нет ни самооценки, ни внутренней проверки, значения исключаются или учитываются с понижающим коэффициентом.
• Попытка разобрать карантин по значению, которое внесли сами. Запрещено тем же барьером «автор ≠ проверяющий».
• Назначение автора или верификатора оценки её же экспертом. Недопустимо по правилу независимости — платформа не даст назначить такого эксперта.