Граница системы должна быть строже поведения модели
Финальная система начинается не с весов, а с проверяемого контракта. Он задаёт форму запроса и ответа, типы полей, допустимые диапазоны, версию tokenizer, способ завершения генерации и семантику ошибок. Модель может вернуть неожиданный текст, но внешний API не должен принимать неожиданные типы или молча угадывать намерение клиента. В частности, Python считает bool подтипом int, поэтому проверка целого диапазона обязана отдельно исключать логические значения.
В локальном контракте запрос содержит ровно prompt: str и max_new_tokens: int от 1 до 8. Запрет неизвестных полей помогает обнаружить опечатку вместо того, чтобы проигнорировать её. Ответ отделяет сгенерированные token IDs от citations и причины остановки; эти поля нельзя восстанавливать парсингом произвольной строки. Версия схемы делает несовместимое изменение явным.
Продолжение. Визуальная модель проводит один запрос через границу untrusted input → validation → normalized request → model runtime → typed response. На каждом переходе видны schema version, принятое решение и машинно-читаемый код ошибки. Контракт также фиксирует maximum prompt length, encoding, timeout и поведение при недоступном источнике, чтобы клиент не зависел от случайного текста исключения.
Граница применимости. Валидация формы не доказывает безопасность смысла prompt и не заменяет authorization. Слишком широкий контракт расширяет поверхность атаки, а слишком узкий мешает развитию API. Изменение tokenizer, chat template или stop policy может быть несовместимым даже при прежнем JSON; такие зависимости входят в версионируемый model contract.