Ключевые моменты
Разбираем на примере систем со случайным результатом, почему лабораторный отчёт, версия сборки, настройки и фактические данные нельзя считать одним доказательством.
В технической документации слово «проверено» часто выглядит убедительнее, чем оно того заслуживает. За одной такой формулировкой могут скрываться разные вещи: испытание алгоритма, расчёт математической модели, проверка конкретной сборки или наблюдение за уже работающей системой. Если не разделить эти уровни, сертификату начинают приписывать то, чего он не подтверждает.
Хорошо видна эта проблема на программных продуктах со случайным результатом. У них есть генератор случайных чисел, правила преобразования его выхода, таблица выплат и настраиваемые параметры. Лаборатория может испытать всё это, но итоговый документ всё равно относится к определённой версии и заданной конфигурации. После развёртывания остаётся ещё один вопрос: что именно включено у оператора.
Четыре разных объекта проверки
Первый объект — генератор случайных чисел, или RNG. Проверяют не «везучесть» отдельных пользователей, а свойства последовательности и корректность реализации. В техническом стандарте GLI-19 для интерактивных игровых систем отдельно рассматриваются получение результата через RNG, справедливость игры и проценты выплат. Это соседние, но не взаимозаменяемые блоки.
Второй объект — преобразование исходного числа в результат. Даже хороший генератор бесполезен, если масштабирование выполнено с перекосом. Условно, последовательность может быть статистически корректной, а ошибка в сопоставлении значений с картами, символами или призами изменит вероятность исходов.
Третий объект — математическая модель. Для игры это таблица правил, вероятностей и выплат, из которой рассчитывается теоретический RTP. Британская Gambling Commission в RTS 3 требует до начала игры давать пользователю понятную информацию о правилах и шансах: это может быть RTP, преимущество организатора или вероятность событий. Само число при этом описывает модель на большой дистанции, а не обещает результат отдельной сессии.
Четвёртый объект — конкретная сборка и её настройки. Здесь чаще всего и возникает разрыв между документом и работающим продуктом. Один разработчик может иметь несколько допущенных вариантов для одной игры, а оператор выбирает один из них. Название продукта остаётся прежним, цифры — уже нет.
Почему одного сертификата недостаточно
Сертификат или отчёт об испытаниях отвечает на ограниченный вопрос: соответствовал ли предъявленный объект установленным требованиям в момент проверки. Чтобы прочитать документ правильно, нужны как минимум идентификатор продукта, версия, перечень испытанных модулей, конфигурация и дата.
В GLI-19 версии 3.0 это различие сформулировано практически: стандарт разделяет технические требования, которые оцениваются в лаборатории, и операционные процедуры, проверяемые после установки системы. Такой подход полезен далеко за пределами игровой отрасли. Он применим к промышленному ПО, программно-аппаратным комплексам, расчётным модулям и системам управления: протокол испытаний не доказывает, что на площадке запущена именно испытанная сборка.
Поэтому в досье стоит искать не красивое название документа, а связку идентификаторов. Версия в акте должна совпадать с версией поставленного продукта. Хеш или другой контрольный признак помогает убедиться, что файл не заменили. Для настраиваемой системы отдельно фиксируют значения параметров и права тех, кто может их менять.
RTP — паспорт модели, а не прогноз
Теоретический RTP удобно сравнить с расчётной характеристикой изделия. Он получается из правил и вероятностей модели на очень большом числе событий. В короткой последовательности фактический результат может заметно отклоняться от расчётного — это не опровержение математики и не подтверждение неисправности.
Но и обратное неверно: опубликованный RTP нельзя автоматически переносить на любую площадку с тем же названием игры. Сначала надо установить, какая конфигурация используется. На момент подготовки материала срез по провайдерам и конфигурациям RTP показывал средний разброс между казино 1,19 процентного пункта. Это наблюдаемая характеристика собранной выборки, а не универсальная константа рынка; вместе с цифрой важны дата и охват.
Как должна выглядеть доказательная цепочка
Для сложной программной системы удобно собирать не один «главный сертификат», а последовательность связанных свидетельств:
- Идентификация. Точное наименование, разработчик, номер версии, состав модулей и контрольная сумма сборки.
- Описание логики. Алгоритм, входные данные, правила преобразования и ограничения применения.
- Расчётная модель. Формулы, таблицы параметров и ожидаемые характеристики для каждой допустимой конфигурации.
- Протокол испытаний. Кто проверял, по какому стандарту, что вошло в область испытаний и какие исключения остались.
- Акт развёртывания. Какая сборка установлена, какие настройки включены и кто согласовал изменение.
- Наблюдение после запуска. Датированные записи, журнал изменений и процедура реакции на расхождения.
Если выпадает хотя бы одно звено, вывод приходится сужать. Например, спецификация разработчика подтверждает допустимый диапазон, но не настройку у конкретного оператора. Скриншот рабочей системы показывает состояние в определённый момент, но без идентификатора версии не связывает его с лабораторным отчётом.
Практический пример: как не смешивать источники
Открытые отраслевые базы полезны, только если честно показывают происхождение данных. Методика RTP Index с фиксацией источника, уровня достоверности и даты разделяет сведения оператора, технические спецификации провайдера и наблюдения из конфигурации запуска. Значение из спецификации не выдаётся за подтверждённую настройку казино, а неудачная проверка не превращается в утверждение о нарушении.
Для технического заказчика здесь важен сам принцип. Данные из паспорта изделия, реестра, испытательного протокола и производственного журнала нельзя складывать в одну колонку без пометки. У каждого источника своя область доказательства. Если два значения расходятся, сначала проверяют дату, версию и контекст, а уже потом ищут ошибку.
Что это означает для реестров и закупочной документации
Запись в государственном или отраслевом реестре, лицензия, сертификат и протокол испытаний выполняют разные функции. Реестровая запись подтверждает предусмотренный нормативным актом статус объекта. Испытание описывает результаты проверки в заданной области. Лицензия относится к праву организации вести определённую деятельность. Ни один из этих документов автоматически не заменяет остальные.
При подготовке документации на программное обеспечение или программно-аппаратный комплекс полезно заранее определить единицу учёта. Что именно заявляется: семейство продуктов, конкретная версия, модуль или комплект с оборудованием? Какие изменения считаются существенными? После какого обновления требуется повторная проверка? Ответы лучше зафиксировать до подачи заявки или закупки, иначе одна и та же торговая марка будет скрывать несколько технически разных объектов.
Короткий чек-лист для заказчика
- совпадают ли наименование и версия во всех документах;
- указана ли область испытаний, а не только итог «соответствует»;
- перечислены ли допустимые конфигурации и параметры;
- есть ли контрольная сумма или другой способ идентифицировать сборку;
- зафиксирована ли фактическая настройка после развёртывания;
- ведётся ли журнал изменений с датой и ответственным;
- можно ли восстановить источник каждой опубликованной метрики.
Главный вывод простой: проверяют не название продукта и не репутацию поставщика, а конкретный объект в конкретном состоянии. Чем сложнее и гибче программная система, тем важнее связать лабораторный документ с версией, конфигурацией и последующим наблюдением. Именно эта связка превращает набор файлов в доказательство.
