Формальное представление знаний как входной и внутренний языки компилятора знаний в системах клинического назначения

Авторский коллектив

1. Прозоров А.А., Директор по технологиям РТЛАБ, архитектор Сбертех, ap@rtlab.ru;
2. Бахвалов И.М., Генеральный директор РТЛАБ Онкология, ibakhvalov@rtlab.ru;

Аннотация

Цель. Сформулировать формальную модель представления знаний для компилятора знаний, применимого к программному обеспечению, значимому для безопасности, включая надзорные экосистемы операционной и отделения реанимации и интенсивной терапии (OR/ICU). Особое внимание уделено разделению авторизованного языка ввода, авторизованного входа конкретной компиляции, контракта понижения представления, внутреннего языка компилятора, скомпилированной материализации и производных проекций.

Материал и методы. Работа имеет методологический и архитектурный характер. Выполнен концептуальный анализ языкового стека компилятора знаний с учетом требований к управляемой семантике, машинно-проверяемым отображениям, внутренним промежуточным представлениям, производным артефактам среды времени выполнения и рецензирования, а также доказательным поверхностям. Внешнюю методологическую основу составили спецификации OWL, RDF, SHACL, PROV-O, JSON Canonicalization Scheme, JSON Schema, Meta Object Facility и работы по предметно-специфическим языкам [1–9]. В качестве исходной авторской основы использованы положения о графо-ориентированном авторизованном языке, авторизованном снимке, формальных плоскостях, скомпилированном пакете, производных представлениях Plane-JSON и Plane-BIN, а также о разграничении владения между оболочкой, семантическим ядром и средой времени выполнения.

Результаты. Предложена многослойная модель компилятора знаний. В данной модели авторизованная семантика представлена онтологически-ориентированным языком ввода; авторизованный снимок является единственным допустимым экземпляром входа для конкретной компиляции; машинно-проверяемый артефакт отображения управляет понижением представления по принципу «при сомнении — стоп»; формальные плоскости образуют внутренний язык компиляции; скомпилированный пакет материализует этот внутренний язык; Plane-JSON, Plane-BIN, совместимые поверхности во время выполнения, манифесты и квитанции рассматриваются как производные, но не авторизованные, проекции. Отдельно сформулирована дисциплина владения, согласно которой входной слой, семантическое ядро и среда времени выполнения не должны подменять друг друга в определении смысла.

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

Ключевые слова: формальное представление знаний; компилятор знаний; авторизованная семантика; авторизованный снимок; промежуточное представление; языковые уровни компилятора; трассируемость; программное обеспечение, значимое для безопасности; медицинская информатика

Сокращения и терминологические соглашения

ОРИТ — отделение реанимации и интенсивной терапии; OR/ICU — операционная и отделение реанимации и интенсивной терапии; IR — промежуточное представление; DSL — предметно-специфический язык; JSON — JavaScript Object Notation; BIN — бинарное представление; CI — контур непрерывной интеграции; RDF — Resource Description Framework; OWL — Web Ontology Language; SHACL — Shapes Constraint Language; среда времени выполнения — среда исполнения скомпилированных структур.

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

Англоязычные названия артефактов сохранены в исходной форме, когда они являются частью внутреннего канона архитектуры: Authorized snapshot, Plane-JSON, Plane-BIN, Go shell, Rust semantic core, C++ runtime/build. Канонические термины, русифицированные в настоящей статье: скомпилированный пакет, проекция связывания, манифест трассировки, панель управления дескрипторами.

1. Введение

Клиническое программное обеспечение, применяемое в средах с высокой ответственностью, не может основываться только на декларации о том, что его поведение «происходит из онтологии» или «происходит из графа знаний». Подобная формулировка часто скрывает ключевую инженерную границу. Граф знаний, даже если он описан средствами OWL, RDF или SHACL, сам по себе не является исполняемым контуром; релизный пакет сам по себе не становится источником авторизованного смысла; JSON-представление, пригодное для совместимости во время выполнения, не гарантирует корректной семантической проекции [1–3, 5, 6]. Между управляемым значением и артефактами развертывания всегда находится компилятор. Эта граница должна быть формализована, поскольку именно в ней может возникать скрытое принятие решений реализации.

В системах, ориентированных на операционную и ОРИТ, такая проблема приобретает особую значимость. Надзорная система может обрабатывать физиологические осциллограммы, числовые тренды, данные медицинских устройств, кодифицированные термины и локальные клинические политики. Если путь от авторизованной клинической семантики к исполняемым структурам не описан явно, то фактическим владельцем смысла может стать не утвержденная модель, а локальный код, конфигурация среды времени выполнения, проекция совместимости или файл рецензирования. Такая система может сохранять операционную работоспособность, однако ее проверяемость и воспроизводимость остаются ограниченными.

Наиболее уязвимым является слой, в котором предикаты графа понижаются до полей среды времени выполнения, внутренние структуры появляются только в коде, а проекции совместимости начинают использоваться как поверхности авторского редактирования. В этом случае компилятор перестает быть механизмом сохранения семантической истины и становится непрозрачным соавтором семантики. Для клинических систем, значимых для безопасности, подобная неопределенность затрудняет аудит, анализ первопричин, воспроизведение релиза и контролируемое уточнение.

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

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

2. Методологическая основа и границы работы

Работа относится к концептуально-архитектурному типу исследований. В ней не анализируются клинические исходы, не проводится сравнение групп пациентов, не оценивается чувствительность или специфичность алгоритма, не заявляется регистрационно-значимая валидация и не описывается завершенная реализация времени выполнения. Вклад статьи состоит в уточнении формализма компилятора знаний и в описании дисциплины владения между представительными слоями.

В качестве методологической основы рассматриваются следующие классы объектов:

1. авторизованная семантическая основа, представленная графо-ориентированным языком;
2. авторизованный снимок, допускаемый к конкретной компиляции;
3. нормативный артефакт отображения, определяющий допустимое понижение представления;
4. формальные плоскости как внутренний язык компиляции;
5. скомпилированный пакет как ограниченная материализация внутреннего языка;
6. производные выходные артефакты для рецензирования, совместимости во время выполнения, упаковки и доказательств;
7. граница владения между входной оболочкой, семантическим ядром и средой времени выполнения или сборки.

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

3. Почему необходим подход через языки компилятора

Подход через языки компилятора необходим потому, что несколько различных обязанностей часто объединяются в одно расплывчатое понятие «представления». Такое объединение может быть допустимым в небольших демонстрационных системах, но оно становится недостаточным для программного обеспечения, применимого в клинических средах с высоким уровнем ответственности.

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

Если эти обязанности не разведены, реализация вынуждена импровизировать. Файл программы среды времени выполнения начинает нести скрытую семантику. Внутренний формат пакета начинает вести себя как авторизованный язык. Оболочка приобретает черты владения семантикой только потому, что внутренний язык не был описан в явном виде. Правило отображения остается воплощенным только в коде конкретного сервиса, поскольку нормативная поверхность понижения представления отсутствует.

Формальная языковая рамка не означает абстрагирование от реализации. Напротив, она позволяет явно указать, какой слой чем владеет. В этом смысле компилятор знаний следует рассматривать не как набор файловых преобразований, а как архитектурную границу между авторизованным смыслом и его допустимыми материализациями.

Практическая ценность такого подхода состоит в разделении обязанностей. Авторизованная семантика остается в управляемом слое и его авторизованных снимках. Понижение представления принадлежит артефакту отображения. Внутреннее рассуждение принадлежит формальным плоскостям и скомпилированным структурам. Совместимость во время выполнения принадлежит производным проекциям. Границы между оболочкой, семантическим ядром и средой времени выполнения остаются контролируемыми, поскольку соответствующие языковые слои описаны явно.

4. Авторизованный язык ввода

Язык ввода компилятора в рассматриваемой программе не должен сводиться к вручную авторизуемому JSON-файлу среды времени выполнения. Он представляет собой онтологически-ориентированный абстрактный синтаксис, выраженный в управляемой графовой модели. Программа поддерживает слой авторизованной семантики и допускает компиляцию только из авторизованного снимка. Это различие принципиально: авторизованный слой является местом, где семантическая основа допускается к машинно-значимому преобразованию, тогда как нижестоящие файлы являются лишь производными материализациями.

В авторизованном языке дескрипторы, методы, строки, предикаты, эффекты, привязки, политики, терминологические связи и связанные структуры существуют как управляемые семантические объекты. Они еще не являются полями среды времени выполнения и не должны редактироваться через производные поверхности. Такой язык является абстрактным синтаксисом в компиляторном смысле: он фиксирует структурные и семантические единицы, над которыми системе разрешено рассуждать, но не привязывает программу к одной проекции развертывания или рецензирования.

Из этого определения следуют четыре свойства авторизованного языка ввода.

Во-первых, слой должен учитывать именованные графы. Семантическое разделение и область полномочий должны быть частью входного языка, а не постфактум деталями хранения. Во-вторых, объекты авторизованного слоя должны иметь устойчивую идентичность. Дескрипторы, строки, предикаты, привязки и политики должны существовать как управляемые объекты до появления любой проекции. В-третьих, генерируемый JSON не должен быть поверхностью мутации. Файлы рецензирования или развертывания могут отражать смысл, но не должны становиться местом, где редактируется устойчивый смысл. В-четвертых, авторизованный слой не обязан повторять файловую вложенность или удобство нижестоящих потребителей. Он должен быть компактным по набору понятий и богатым по семантической идентичности.

Именно здесь статья расходится с работами, ориентированными на среду времени выполнения. Такие работы могут начинаться со скомпилированных артефактов. Работа о языках компилятора должна начинаться раньше — с описания того, что является авторизованным входом. Если такой слой не определен, создается впечатление, что компилятор компилирует «откуда-то», а это и является типичным механизмом скрытого семантического владения.

5. Нормативный мост отображения как контракт понижения представления

Между авторизованной семантикой и внутренней скомпилированной структурой должен существовать нормативный мост понижения представления. В рассматриваемой архитектуре такой мост не является комментарием к коду и не является устной практикой реализации. Он представляет собой машинно-проверяемый артефакт отображения, который определяет, как онтологические классы, предикаты и профили могут материализоваться в формальные плоскости и поля производных проекций.

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

Необходимость данного моста является методологической, а не косметической. Без него компилятор может незаметно изобретать владение плоскостями, размещение полей или семантику совместимости внутри локального кода реализации. В таком случае наиболее важная часть компиляции перестает принадлежать формальному языковому стеку и переходит в приватную деталь реализации. Система может продолжать порождать выходные данные, но уже не доказывает, что эти данные являются управляемым потомком авторизованной семантики.

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

Данный мост также предотвращает смешение авторизованных и производных языковых слоев. Онтологически-ориентированная авторизованная семантика остается авторизованным языком ввода. Строки отображения определяют допустимый путь понижения представления. Формальные плоскости определяют внутренний язык компиляции. Производные проекции определяют выходные языки. Ни один из этих слоев не должен молча выдавать себя за другой.

6. Внутренний язык: формальные плоскости и скомпилированный пакет

Даже после ограничения пути понижения представления компилятору необходим внутренний семантический язык, в котором он может валидировать, упорядочивать, связывать и выводить исполняемые структуры. В рассматриваемой программе таким внутренним языком является формальный многоплоскостной IR: плоскости управления, данных, дескрипторов и исполнения правил, а также сквозные ограниченные проекции, включая проекцию связывания и манифест трассировки.

Именно эти плоскости являются внутренним языком компилятора. Скомпилированный пакет представляет собой ограниченную материализацию данного внутреннего языка для детерминированной последующей обработки. Он еще не является полным семейством производных артефактов, ориентированных на потребителя.

Называть формальные плоскости внутренним языком следует не как риторическое усиление, а как архитектурное утверждение. Во-первых, компилятор рассуждает о них как о структурированных объектах с инвариантами, а не как о сырых экспортируемых полях. Во-вторых, плоскости разделяют семантические обязанности: структура планирования и зависимостей не должна находиться в том же представительном пространстве, что и семантика клинических данных, а межплоскостные привязки должны оставаться декларативными и не вводить скрытый поток управления. В-третьих, плоскости расположены ближе к пути доказательств компилятора, чем любая проекция совместимости.

Следовательно, скомпилированный пакет не следует рассматривать только как удобство упаковки. Он несет формальные плоскости, поверхности привязки и трассы, необходимые для детерминированного рассуждения и последующего объяснения. Он также содержит структуру, связанную дайджестами и необходимую для происхождения и доказательств. В этом смысле скомпилированный пакет является материализацией внутреннего языка, но не авторизованным каноном.

Это различие особенно важно потому, что нижестоящие артефакты часто выглядят привычнее, чем внутренний язык. JSON, совместимый во время выполнения, легче читать, чем формальные плоскости. Представление Plane-JSON для рецензирования удобнее для просмотра, чем скомпилированный пакет. Однако удобство просмотра не является авторством. Внутренний язык — это слой, которым семантически владеет компилятор; проекции — это слои, которые компилятор порождает для нижестоящего потребления.

Пример трассы по слоям

Стадия	Пример представления
Авторизованный семантический объект	В онтологически-ориентированном слое авторизованной семантики существует предикат зависимости дескриптора.
Авторизованный вход компиляции	Авторизованный снимок допускает этот предикат и владеющий им дескриптор в одну конкретную компиляцию.
Строка отображения	Строка проекции предиката связывает этот предикат с панелью управления дескрипторами и допустимыми полями представлений рецензирования или совместимости.
Внутренний язык	Зависимость материализуется как объект плоскости управления, переносимый скомпилированный пакет, вместе с записями проекции связывания и манифеста трассировки.
Производные проекции	Компилятор может вывести путь рецензирования Plane-JSON и, при необходимости, поле, совместимое во время выполнения, производное от того же отображенного объекта.

Рисунок 1. Языковой стек компилятора знаний

7. Слои языков компилятора и их обязанности

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

Таблица 1. Слои языков компилятора и границы их обязанностей

Слой	Роль	Канонический артефакт	Недопустимый выход за границу
Авторизованный язык ввода	Определяет управляемый смысл до исполнения.	Онтологически-ориентированный абстрактный синтаксис и семантика именованных графов.	Превращение в файл, совместимый во время выполнения, или вручную редактируемую поверхность развертывания.
Авторизованный вход компиляции	Допускает один управляемый экземпляр авторизованной семантической основы к конкретной компиляции.	Authorized snapshot, авторизованный снимок.	Рассматриваться как необязательный, выводимый по умолчанию или заменяемый локальными файлами.
Контракт понижения представления	Ограничивает то, как авторизованная семантика может материализоваться ниже по цепочке.	Реестр отображения, схема отображения и нормативные строки проекции.	Скрытые правила понижения представления, живущие только в коде, или неявно выводимые непокрытые поля.
Внутренний язык	Дает компилятору структурированные семантические плоскости для валидации и рассуждения.	Формальный многоплоскостной IR.	Вести себя как авторизованная поверхность мутации или обходить контракт понижения представления.
Скомпилированная материализация	Несет внутренний язык как ограниченный набор выходов, принадлежащий компилятору.	Скомпилированный пакет с проекцией связывания и манифестом трассировки.	Смешиваться с производными пакетами, ориентированными на потребителей, или с представлениями рецензирования.
Производные проекции	Материализуют выходы для развертывания, рецензирования и доказательств.	Plane-JSON, Plane-BIN, совместимые проекции во время выполнения, манифесты, квитанции.	Становиться равноправным авторизованным каноном или самостоятельным источником семантики.

Такое разделение не вводит дополнительные форматы ради форматов. Оно делает уже существующие представительные слои проверяемыми и предотвращает ситуацию, при которой компилятор молча создает дополнительный, неописанный слой внутри себя.

8. Производные проекции и доказательные поверхности

Проекционный слой начинается после скомпилированного пакета. Часть производных артефактов ориентирована на развертывание, например Plane-BIN и совместимые представления во время выполнения. Другая часть ориентирована на рецензирование, например более подробные представления Plane-JSON. Третья часть ориентирована на доказательства, например манифесты и квитанции, связанные дайджестами. Их объединяет не функция, а статус: все они являются производными выходами из одной авторизованной основы и одной принадлежащей компилятору внутренней материализации.

Из этого статуса следуют два практических последствия. Во-первых, производные проекции могут быть заново сгенерированы из той же авторизованной семантической основы и того же контракта понижения представления без изменения смысла системы. Во-вторых, доказательные поверхности могут оцениваться на собственных основаниях. Каноникализация, манифесты, дайджесты и связи происхождения нужны для доказательства того, что именно было спроецировано и из какой основы. Они не должны становиться вторым семантическим языком.

Поэтому Plane-BIN не следует отождествлять с самим скомпилированным пакетом. Скомпилированный пакет — это ограниченная материализация внутреннего языка. Plane-BIN — это производное машинно-ориентированное представление упаковки этой материализации. Аналогично Plane-JSON является человеко-ориентированным представлением для рецензирования. Совместимые проекции во время выполнения могут сохранять операционную непрерывность там, где это требуется, а манифесты и квитанции могут связывать эти выходы с одной семантической основой и одним контрактом понижения представления. Однако ни один из этих выходов не должен быть местом, с которого начинается семантическое исправление.

Данная статья концептуально соприкасается с тематикой происхождения и трассируемости, но это пересечение ограничено. Здесь важно показать, что производные выходы являются частью языкового стека, но их доказательные поверхности остаются производными. Полная программа сквозной трассируемости терминов, доказательств среды времени выполнения и управляемого уточнения относится к сопутствующим работам.

9. Граница оболочки, семантического ядра и среды времени выполнения

В текущей программе разделение Go shell -> Rust semantic core -> C++ runtime/build имеет значение не как «война языков», а как пример более общей дисциплины владения. Входной и оркестрационный слой владеет разбором команд, разрешением путей, операторским рабочим процессом и поведением на границе системы. Семантическое ядро владеет понижением представления, доказательством проекций, валидацией по принципу «при сомнении — стоп» и материализацией внутреннего языка. Среда времени выполнения или сборки исполняет либо упаковывает принятые скомпилированные структуры, но не владеет ни авторизованной семантикой, ни смыслом времени компиляции.

Эта граница важна потому, что не позволяет поверхностям реализации размывать языковой стек. Оболочка не должна становиться вторым движком понижения представления. Среда времени выполнения не должна становиться автором семантики. Проекция совместимости не должна становиться источником истины только потому, что это удобно локальному сервису. Поэтому разделение оболочки, семантического ядра и среды времени выполнения служит той же цели, что и разделение представительных слоев: на каждое семантическое обязательство должен быть назначен один владелец.

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

Рисунок 2. Граница владения между оболочкой, семантическим ядром и средой времени выполнения

10. Обсуждение

Полученные результаты позволяют рассматривать компилятор знаний как стек формальных языков, а не как технический экспортер из графа. Такое представление особенно важно для медицинского программного обеспечения, где различие между авторизованным клиническим смыслом и его производными артефактами должно сохраняться на протяжении всего пути от авторского описания до исполнения у постели пациента.

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

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

Третье преимущество связано с дисциплиной владения. В клинических системах, где могут использоваться разные технологические слои, важно не то, написаны ли они на Go, Rust или C++, а то, не возникает ли скрытого семантического владения у слоя, который должен выполнять только оркестрационную, упаковочную или исполнительную роль. Предложенная модель позволяет отделить выбор языка реализации от архитектурного вопроса о принадлежности смысла.

Следует подчеркнуть, что использование онтологий, RDF, OWL, SHACL или родственных стандартов само по себе еще не гарантирует наличие такого языкового стека. Эти технологии могут поддерживать явность, ограничения и происхождение, а спецификации каноникализации и описания схем могут повышать воспроизводимость машинных артефактов [1–6]. Однако они не заставляют проект автоматически различать авторизованный синтаксис, контракт понижения представления, внутренний язык и производные проекции. Такое различение должно быть специально спроектировано, реализовано и проверено.

11. Инварианты предложенной модели

Инварианты данной статьи являются преимущественно представительными и архитектурными.

1. Существует одна авторизованная семантическая основа, а каждая компиляция потребляет один авторизованный снимок этой основы.
2. Никакое скрытое понижение представления не допускается вне нормативного артефакта отображения.
3. Компиляция выполняется по принципу «при сомнении — стоп» в отношении непокрытой отображением машинно-значимой семантики.
4. Формальные плоскости определяют внутренний язык, а скомпилированный пакет является его ограниченной материализацией, но не вторым авторизованным слоем.
5. Производные выходы, включая Plane-BIN, Plane-JSON, совместимые представления во время выполнения, манифесты и квитанции, остаются производными и неавторитетными.
6. За каждое семантическое обязательство должен быть определен один владелец на уровне входного слоя, семантического ядра или потребителя среды времени выполнения/сборки.

Этих инвариантов достаточно, чтобы отделить настоящую статью от сопутствующих работ. Замкнутый цикл управления формализуемым знанием объясняет, как управляемое знание проходит через авторизацию, выпуск, доказательства и уточнение, сохраняя авторство. Работа по сквозной трассируемости кодифицированных терминов должна объяснить, как скомпилированные термины и доказательства среды времени выполнения остаются трассируемыми. Работа по реализации исполняемого знания как детерминированного вычислительного ядра и детерминированного ядра безопасности должна описать операционное размещение скомпилированного знания. Настоящая статья расположена раньше в этой цепочке: она определяет, какие уровни представления должны существовать у компилятора, чтобы последующие статьи не опирались на скрытое появление семантики.

12. Граница с сопутствующими статьями

Таблица 2. Граница настоящей статьи с сопутствующими работами серии

Статья	Отвечает за	Не отвечает за
Замкнутый цикл управления формализуемым знанием	Метод управления в пространстве авторизации через авторизацию, выпуск, доказательства и уточнение.	Формальный языковой стек компилятора или архитектуру размещения среды времени выполнения.
Формальное представление знаний как входной и внутренний языки компилятора знаний	Авторизованный язык ввода, контракт понижения представления, внутренний язык и границы производных проекций.	Полный жизненный цикл происхождения, размещение среды времени выполнения, автоматизацию выпуска или выполнение цепочки доверия.
Сквозная трассируемость кодифицированных терминов для отладки и аудита компилятора и исполняемых модулей	Происхождение терминов, трассируемость и пригодность к выполнению аудита через артефакты компилятора и среды времени выполнения.	Определение авторизованного языка ввода или архитектуры оболочки и среды времени выполнения как таковых.
Реализация исполняемого знания как детерминированного вычислительного ядра и детерминированного ядра безопасности	Размещение детерминированного вычислительного ядра, архитектуру среды времени выполнения и границу детерминированного ядра безопасности.	Формальный языковой стек компилятора или метод управления.

13. Ограничения работы

Настоящая работа имеет несколько ограничений. Во-первых, статья носит методологический и архитектурный характер и не содержит клинической валидации. Следовательно, ее выводы не должны интерпретироваться как доказательство клинической эффективности какой-либо системы поддержки принятия решений, надзорного контура OR/ICU или алгоритма управления медицинскими устройствами.

Во-вторых, статья не описывает полную реализацию времени выполнения. Разделение Go shell -> Rust semantic core -> C++ runtime/build используется как пример дисциплины владения, а не как универсальное требование к технологическому стеку.

В-третьих, работа не заявляет полной сквозной трассируемости, аудируемости и завершенности цепочки доверия. Она формулирует представительные слои, без которых такая трассируемость затруднена, но не заменяет отдельные работы о доказательствах среды времени выполнения, происхождении и управляемом уточнении.

В-четвертых, работа не утверждает, что любая система, основанная на онтологии, уже удовлетворяет предложенным инвариантам. Наличие RDF-, OWL-, SHACL- или аналогичных технологий является лишь потенциальной основой, но не гарантирует корректного разделения авторизованного языка, контракта понижения, внутреннего языка и производных проекций.

14. Заключение

Компилятор знаний в программном обеспечении, значимом для безопасности, целесообразно описывать не как экспортер графа, упаковщик среды времени выполнения или одну протокольную границу, а как многослойный языковой стек. Центральное различие этого стека состоит в следующем: авторизованная семантика и ее авторизованный снимок не являются контрактом отображения; контракт отображения не является внутренним языком; внутренний язык и скомпилированный пакет не являются тем же самым, что производные представления Plane-JSON, Plane-BIN или совместимые поверхности во время выполнения.

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

Предложенная модель может рассматриваться как основа для дальнейшего проектирования клинических информационных систем, в которых авторизованная семантика должна сохранять управляемость при переходе к машинно-значимым представлениям, совместимости во время выполнения, доказательным поверхностям и последующему аудиту.

Авторская основа

Статья опирается на внутреннюю документацию проекта HealthOS: спецификации, схемы и реестры, задающие авторизованную семантику и её скомпилированную форму, на среду выполнения и инструменты, дающие доказательства выполнения, и на смежные статьи серии, объединённые общим каноном терминологии. Это рабочие источники, которые обосновывают инженерные решения и удерживают единство терминологии в серии. Они остаются внутренней авторской основой, а не публичными ссылками, и не приводятся как ссылки на репозиторий в тексте.

Конфликт интересов

Рукопись описывает реализацию определенного аспекта платформы HealthOS, а именно: формальное представление знаний как входной и внутренний языки компилятора знаний.

Финансирование

Финансирование работ со стороны РТЛАБ.

Литература

1. W3C OWL Working Group. OWL 2 Web Ontology Language Document Overview. Second Edition. W3C Recommendation. 2012. https://www.w3.org/TR/owl2-overview/
2. Cyganiak R., Wood D., Lanthaler M., editors. RDF 1.1 Concepts and Abstract Syntax. W3C Recommendation. 2014. https://www.w3.org/TR/rdf11-concepts/
3. Knublauch H., Kontokostas D., editors. Shapes Constraint Language (SHACL). W3C Recommendation. 2017. https://www.w3.org/TR/shacl/
4. Lebo T., Sahoo S., McGuinness D., editors. PROV-O: The PROV Ontology. W3C Recommendation. 2013. https://www.w3.org/TR/prov-o/
5. Rundgren A., Jordan B., Erdtman S. JSON Canonicalization Scheme (JCS). IETF RFC 8785. 2020. https://www.rfc-editor.org/rfc/rfc8785
6. JSON Schema authors. JSON Schema Draft 2020-12. 2022. https://json-schema.org/draft/2020-12
7. Object Management Group. Meta Object Facility (MOF) Core Specification, Version 2.5.1. 2019. https://www.omg.org/spec/MOF/2.5.1
8. Fowler M., Parsons R. Domain-Specific Languages. Addison-Wesley. 2010. https://martinfowler.com/books/dsl.html
9. Voelter M., Benz S., Dietrich C. et al. DSL Engineering. 2013. https://dslbook.org/