Экспертная система редко ломается из-за отсутствия требований. Чаще проблема возникает тогда, когда требования разных заинтересованных сторон одновременно обоснованны, но противоречат друг другу, требуют несопоставимых ресурсов или относятся к разным уровням системы.
Для Индустриального ИИ Альянса эта задача стала практической после исследовательской миграции отраслевых материалов в общую библиотеку для человека и ИИ. Алина Цуцу подготовила подробный отзыв объемом 45 страниц: в нем были одновременно признаны уже работающие защитные механизмы и поставлены жесткие вопросы об авторстве, границах метода, публикации, машинной обработке, рекомендациях экспертов и выпуске новых версий.
Разбирать такой документ построчно недостаточно. Нужна процедура, которая позволяет сохранить смысл требований, определить их место в архитектуре, принять проверяемые решения и зафиксировать новую базовую линию системы. В этой статье мы называем ее архитектурной балансировкой требований заинтересованных сторон и фиксацией переходной базовой линии системы.
Это не юридическое заключение и не попытка заменить договорную работу архитектурной схемой. Это инженерный способ удержать развитие общей системы там, где технология, профессиональная практика, авторские границы, экономика и институты меняются быстрее, чем успевает сложиться окончательная модель регулирования.
Откуда появилось 45-страничное требование
Первая миграция отраслевой библиотеки создавалась как исследовательский прототип. Ее задачей было не объявить архитектуру завершенной, а проверить, можно ли собрать в одном рабочем контуре открытые материалы Альянса, резидентские знания, связи между областями знаний, профессиональными ролями, кейсами и траекториями, а затем дать человеку и ИИИ возможность находить нужный объект с сохранением источника, доступа и версии.
Пилотный релиз сделал систему наблюдаемой. Пока материалы существовали на разных страницах, в документах и в памяти участников, многие противоречия оставались теоретическими. После сборки стало возможно задать конкретные вопросы: где автор, где соавтор, где участник кейса, где источник, а где валидатор; какая часть текста относится к открытому стандарту, а какая может быть авторской методикой; что ИИИ вправе найти и объяснить, но не вправе выдавать за личное заключение эксперта; какие объекты должны входить в открытый дистрибутив полностью, а какие — только индексом.
45-страничный отзыв Алины возник именно как ответ на работающий объект, а не на презентацию будущей системы. В нем были отмечены полезные изменения: разделение открытого и закрытого слоев, режим работы только с библиотекой, явное подтверждение внешних действий, маршруты консультации с экспертом, выборочное подключение документов, сохранение источников и более безопасная установка. Одновременно отзыв показал, что текстовых правил недостаточно, если читатель не видит границу авторского вклада, а релизная процедура не отличает подтверждение содержания от соавторства.
Такой отзыв нельзя трактовать ни как окончательное решение всей системы, ни как частное замечание, которое можно принять или отклонить одним ответом. Это качественная экспертная критика и структурированный вход требований заинтересованной стороны. В научном языке дальнейшая работа включает выявление и анализ требований, согласование конфликтов, архитектурную балансировку и верификацию выбранных решений. Сила отзыва — в глубине и конкретности. Его граница — в том, что одна заинтересованная сторона управляет собственным вкладом, но не может единолично закрыть всю область знаний, коллективный материал, вклад других авторов или архитектуру, собранную из нескольких независимых источников.
Ответом на отзыв становится не спор о правоте, а архитектурное заключение по результатам анализа требований заинтересованной стороны. В заключении каждое существенное требование получает основание, затронутый компонент, проверяемый критерий и один из пяти статусов: принято, принято с изменением, уже реализовано, отложено или не принято.
Почему исследовательская миграция не была ошибкой
Инженерный прототип оценивают не по тому, совпал ли он с окончательной системой, а по тому, позволил ли он обнаружить значимые требования до масштабирования. В этом смысле миграция выполнила свою функцию: показала не только техническую возможность сборки, но и пределы прежней модели авторства, названий, доступа и проверки.
По результатам разбора признаны три корректируемых разрыва.
Первый: перед более широким пилотным распространением требовался ограниченный экспертный показ. Он позволил бы раньше увидеть, как авторы воспринимают глубину отражения их вклада, какие формулировки считают открытым профессиональным знанием, а какие требуют более узкой границы.
Второй: в метаданных и редакционных решениях местами смешались разные отношения к материалу — авторство, соавторство, участие, источник и валидация. Эксперт, проверивший структуру главы или участвовавший в обсуждении, не становится автоматически соавтором основного текста. И наоборот: содержательный вклад нельзя растворить в безличной общей редакции.
Третий: при переходе от исходных материалов к унифицированным главам местами потерялись узнаваемые авторские названия. Системное имя удобно для навигации, но не должно стирать историю текста и способ, которым автор обозначил предмет. Поэтому понадобился трехчастный контракт названия: исходное название, каноническое системное название и человекочитаемый заголовок текущего представления.
Эти разрывы требуют исправления, но не доказывают ошибочность самой миграции. Напротив, без прототипа они оставались бы скрытыми. Корректный вывод звучит так: исследовательская версия создала наблюдаемый объект, экспертное ревью выявило требования следующего уровня, а архитектурная балансировка переводит их в новую проверяемую базовую линию.
Научная основа: от мнений к модели системы
Методологической основой служит модельно-ориентированный системный инжиниринг, изложенный Александром Кондратьевым в DocKA0.1 «Модельно-ориентированный системный инжиниринг 2.0». Его принципиальная для этой задачи мысль состоит в том, что систему нельзя описать только перечнем компонентов. Нужно удерживать состав, связи, параметры, ограничения, критерии, ситуацию применения и изменение системы во времени.
В прикладном виде это означает, что требование эксперта нельзя сразу переводить в кнопку, программное право или запрет релиза. Сначала нужно установить, какую функцию системы оно защищает, к какому объекту относится, с какими требованиями конфликтует, какой риск снижает, какие ресурсы потребляет и по какому наблюдаемому признаку можно проверить результат.
Архитектурная балансировка проходит через восемь шагов:
- Зафиксировать заинтересованную сторону и границу ее подтвержденного отношения к объекту.
- Разделить требование, наблюдаемый риск, предлагаемое решение и желаемый результат.
- Связать требование с базовой функцией системы и конкретным компонентом.
- Определить класс требования: ключевое, второстепенное или индивидуальное.
- Проверить существующие механизмы до проектирования новой сущности или нового кода.
- Сопоставить требование с ресурсными, правовыми, организационными и релизными ограничениями.
- Принять disposition-решение и назначить критерий проверки.
- Зафиксировать решение в версии, хеше и переходной базовой линии, которую можно независимо проверить.
Этот порядок защищает систему от двух симметричных ошибок. Первая — игнорировать экспертное требование только потому, что оно неудобно текущей архитектуре. Вторая — немедленно программировать каждое требование, не проверив, можно ли закрыть риск уже существующими средствами и не создает ли локальное решение новый системный разрыв.
Что является системой и что она должна сохранять
Индустриальный ИИ Альянса — не автономный агент, который заменяет экспертов и принимает решения от их имени. Это координационная человеко-машинная система, соединяющая источники, людей, профессиональные роли, области знаний, документы, реальные траектории, пересечения траекторий, эталонные маршруты и проверяемые версии.
Ее базовая функция — помочь человеку найти релевантное знание и профессиональную проверку, сохранив происхождение материала, уровень доступа, границу авторского вклада и возможность вернуться к исходному объекту. ИИИ может систематизировать, параметризовать, искать, классифицировать и объяснять материалы внутри разрешенного контура. Он не должен приписывать эксперту машинный вывод, раскрывать закрытую методику, обещать клиентский результат или превращать упоминание человека в сертификат компетенции.
В систему входят как минимум следующие связанные компоненты:
| Компонент | Системная функция | Что требуется сохранять |
|---|---|---|
| Платформа Альянса | канонические публикации, профили, доступы, обсуждение и решения | URL, доступ, авторов, участников, историю изменений |
| Свод и области знаний KA | открытая архитектура профессионального знания | структуру, границы областей, связи и версии |
| DocKA | объяснения, шаблоны и рабочие документы | автора, KA, статус, версию, источник и режим доступа |
| RL, TR, TRxTR и RLTR | роли, реальные следы, пересечения и эталонные траектории | различие факта, гипотезы, стадии и проверенного результата |
| Рабочее место эксперта | поиск собственного вклада, проверка отношений и постановка требований | доказательство связи, доступ, зеркало, версию и требуемое исправление |
| Дистрибутив библиотеки | локальная работа человека и ИИИ с разрешенным корпусом | состав релиза, манифест, хеш, границы открытого и закрытого слоя |
| Совет | человеческий арбитраж по спорным и базисным решениям | предмет спора, позиции сторон, решение и версию базовой линии |
Главное свойство такой архитектуры — прослеживаемость. Человек должен понимать не только, что система что-то «знает», но и откуда это знание взялось, в каком отношении к нему находится названный эксперт, что разрешено делать с материалом и какая версия проверялась.
Ключевые, второстепенные и индивидуальные требования
Не все требования имеют одинаковый вес. Ключевое требование связано с базовой функцией системы, доступом, происхождением, безопасностью, авторством или возможностью проверить результат. Если оно нарушено, система перестает выполнять обещанную функцию или создает неприемлемый риск.
Второстепенное требование улучшает удобство, полноту, скорость или интерфейс, но его временное отсутствие не разрушает базовую функцию. Индивидуальное требование относится к конкретному автору, объекту, фрагменту или способу использования. Оно может быть критически важным для этого объекта, но не должно автоматически переписывать правила всей системы.
Такое различение не обесценивает частные требования. Оно определяет правильный уровень решения. Просьба исправить неверную атрибуцию конкретного текста требует точечного исправления и следующей синхронизации. Требование закрыть подтвержденную авторскую методику требует установить точный фрагмент, источник, историю публикации, границу конфиденциальности и минимально достаточное действие. Но ни одно из этих требований само по себе не дает основания закрыть целую KA или удалить вклад других авторов.
Ключевыми для текущей базовой линии признаны:
- точная связь объекта с автором, соавтором, участником, источником, валидатором или упоминанием;
- сохранение исходного и человекочитаемого названия рядом с системным;
- соблюдение public, resident и private-доступа;
- невозможность выдавать машинный результат за личное заключение эксперта;
- возможность исправить атрибуцию, текст своего вклада или запросить удаление конкретного объекта;
- версия, манифест и хеш проверяемого релиза;
- человеческое разрешение конфликта, если архитектурная и редакционная процедуры не привели к согласию.
Второстепенными на текущей стадии остаются часть интерфейсных удобств, отдельные представления вкладов, расширенная аналитика и автоматизированные отчеты. Они полезны, но не должны вытеснять исправление происхождения, доступа и границ авторства.
Матрица disposition: как решение становится проверяемым
Disposition — это не оценка автора требования. Это статус архитектурного решения по отношению к конкретному требованию и текущей базовой линии.
| Статус | Значение | Пример применения |
|---|---|---|
| Принято | требование входит в текущую базовую линию в исходном смысле | различать автора, валидатора и участника; сохранять исходное название; проводить ограниченный экспертный показ |
| Принято с изменением | риск признан, но решение меняется ради системной совместимости | вместо безусловной остановки всей библиотеки — закрытый экспертный RC и точечные блокеры; вместо права одного эксперта закрыть целую KA — управление подтвержденным собственным вкладом |
| Уже реализовано | требование закрывается действующим механизмом, который нужно показать и проверить | доступы, локальный режим библиотеки, подтверждение внешних действий, комментарии, манифест, версия, хеш, Совет |
| Отложено | требование содержательно обосновано, но для текущей стадии нет доказанной необходимости или ресурса | фрагментные программные permissions, новая rights-сущность, сложные runtime-gates, отдельная коммерческая архитектура экспертских агентов |
| Не принято | предлагаемое решение конфликтует с базовой функцией, правами других участников или доказательной моделью | автоматическое признание валидатора соавтором; закрытие коллективного знания одним участником; рейтинг как сертификат компетенции |
Для требований из 45-страничного отзыва получилась не бинарная картина «принять или отклонить», а распределение по всем пяти статусам.
Принято различение открытого стандарта, резидентского кейса и закрытой авторской методики; необходимость точной атрибуции; проверка глубины публичного описания; отделение профессиональной рекомендации от общего рейтинга; ограниченный экспертный релиз перед следующим расширением.
Принято с изменением предложение о более жесткой защите фрагментов. На текущем уровне оно реализуется не новой программной моделью прав, а проверяемой процедурой: эксперт называет точный объект или фрагмент, подтверждает свое отношение, указывает источник и версию, описывает границу, а архитектурный контур назначает минимально достаточное действие. Маркер эксперта является требованием на ревью следующей версии, а не автоматическим изменением общей базовой линии.
Уже реализованными признаны механизмы разграничения доступа, локальной работы с библиотекой, явного подтверждения внешних действий, сохранения происхождения, удаления или очистки собственных публикаций через платформенный маршрут, комментариев, Совета и версионированных сборок. Их наличие не отменяет проверки качества применения: функция может существовать технически, но оставаться непонятной пользователю или не быть связанной с релизным gate.
Отложены фрагментные права на уровне программного исполнения, новая универсальная сущность прав, индивидуальные runtime-блокировки для каждого материала и сложная коммерческая модель распределения дохода. Отложить — не значит отрицать. Это означает зафиксировать условие возврата: повторяемая ошибка, которую нельзя закрыть действующей процедурой; доказанный коммерческий масштаб; понятный владелец разработки; ресурс поддержки; проверяемый результат.
Не приняты решения, которые разрушали бы коллективную природу системы: возможность одного участника закрыть целую область знаний, автоматическое распространение требования на чужой вклад, признание любого упоминания авторством или использование общего рейтинга как допуска к профессиональной рекомендации.
Как требование проходит процедуру: три разных случая
Чтобы процедура не осталась декларацией, рассмотрим три типовых требования, которые внешне могут звучать одинаково жестко, но требуют разных архитектурных решений.
Первый случай — неверная атрибуция. Эксперт сообщает, что на странице указан соавтором человек, который проверял структуру, но не писал основной текст, а содержательный вклад другого участника не отражен. Здесь предметом требования является не вся глава и не право на общий метод, а тип связи конкретных людей с конкретным объектом. Архитектор сначала устанавливает канонический URL и проверяемую версию, затем поднимает исходный материал, историю миграции и доказательство вклада. Если факты подтверждаются, требование получает статус «принято», метаданные и source note исправляются, основной корпус защищается от смысловой переписи, а новая версия проходит source/title и author/validator gate. Критерий проверки прост: платформа, локальный каталог и манифест одинаково различают автора, содержательного соавтора и валидатора.
Второй случай — заявление о закрытой авторской методике. Эксперт видит в опубликованной главе вопросы, последовательность действий или интерпретационные правила, которые считает собственным know-how. Система не может ни проигнорировать это заявление, ни автоматически закрыть весь материал. Сначала устанавливается точный фрагмент, авторская связь, источник, дата и история доступа. Затем отделяются общеизвестный профессиональный принцип, опубликованный ранее авторский материал, коллективная редакция и действительно непубличная последовательность. Если граница подтверждена, возможны разные решения: оставить открытым общий принцип с атрибуцией; перенести полный авторский фрагмент в resident-контур, сохранив публичную индексную карточку; закрыть конкретную методическую последовательность; исправить формулировку, которая ошибочно выдает машинную реконструкцию за вывод эксперта. Статус может быть «принято с изменением», потому что признается риск, но минимальное действие отличается от первоначального требования закрыть всю главу. Критерий проверки: открытая версия сохраняет общий стандарт и происхождение, а закрытая часть не попадает в новый открытый релиз и не применяется ИИИ как готовое личное заключение автора.
Третий случай — требование запретить машинное использование. Оно требует самого точного разложения, потому что слово «использование» объединяет разные операции. Внутренняя навигация по разрешенному корпусу, поиск источника, классификация и краткое объяснение с атрибуцией не равны передаче материала внешнему оператору, отдельному обучению модели или созданию самостоятельного коммерческого агента. Для первой группы операций уже действуют доступ, локальный режим, источник и запрет говорить от лица эксперта. Для второй требуется отдельное основание и отдельное согласование. Поэтому общее требование «никакой ИИ не должен читать материал» не принимается как универсальное правило, но риск неконтролируемого внешнего переноса принимается и связывается с конкретной границей. В текущей базовой линии решение может быть «уже реализовано» для внутреннего доступа и «отложено» для будущей программной детализации способов использования.
Во всех трех случаях важен один и тот же принцип: disposition относится не к человеку и не к качеству его аргументации, а к требованию в заданной версии системы. Один и тот же эксперт может получить «принято» по атрибуции, «принято с изменением» по границе метода, «уже реализовано» по доступу и «отложено» по новому runtime-механизму. Это не непоследовательность, а точное разделение предметов.
Для каждого случая минимальная карточка анализа содержит семь элементов:
- Канонический объект и проверяемую версию.
- Подтвержденное отношение заинтересованной стороны к объекту.
- Требование и отдельно наблюдаемый риск.
- Затронутую функцию и компонент системы.
- Существующие средства, которые уже покрывают часть риска.
- Решение, минимальное изменение и критерий проверки.
- Последствие для текущей и следующей базовой линии.
Такая карточка соединяет человеческий комментарий с инженерной моделью. Она достаточно короткая для реальной работы и достаточно строгая, чтобы независимый аудитор мог восстановить путь от исходного требования до релизного решения.
Авторство, валидация и граница вклада
Самый заметный практический результат балансировки — переход от плоского списка имен к типизированным отношениям.
Автор создает основной текст или доказанный содержательный слой. Соавтор вносит самостоятельный существенный вклад в содержание. Участник присутствует в кейсе или переговорах, но это не делает его автором описания. Источник дает материал, на котором построен отдельный тезис или фрагмент. Валидатор проверяет структуру, применимость или отдельный уровень модели. Упоминание фиксирует связь, но не подтверждает ни авторство, ни квалификацию.
Эти отношения нельзя восстанавливать только по частоте имени. Для каждого изменения требуется доказательство: исходный материал, история публикации, протокол, согласование, профильная ссылка или иной проверяемый след.
Эксперт управляет своим подтвержденным вкладом. Он может потребовать исправить связь, обозначить границу авторской методики, сузить доступ, запросить удаление собственного объекта или запретить выдавать машинную реконструкцию за его личный вывод. При этом эксперт не распоряжается вкладом соавторов, коллективным материалом, системной связью, собранной из нескольких источников, или архитектурой всей KA.
Если конкретная публикация удалена или очищена на платформе, следующая синхронизация не должна переносить ее полный текст в актуальный релиз. Удаление публикации, очистка содержания и удаление аккаунта остаются разными действиями и требуют отдельных осознанных решений.
Для текущего контура достаточно пяти рабочих запросов эксперта: оставить как открытый стандарт; сохранить полным только в резидентском контуре и индексом в открытом; обозначить подтвержденную закрытую авторскую методику; исправить атрибуцию; удалить конкретный объект. Эти запросы не становятся новыми автоматическими правами. Они запускают проверку отношения, доступа, версии и минимально достаточного действия.
Что показал аудит 242 объектов
Балансировка требований получила практическое продолжение в миграционном аудите авторства, валидаторов и названий. Единый реестр охватил 242 объекта: каталог статей и связанный контур страниц Сопровождения, Форкурса и экспертных материалов.
Аудит не использовал правило «массово переписать метаданные по именам». Он разделил объекты, для которых найден подтвержденный источник, и объекты, пока доступные только как базовая линия текущей платформы. Это существенно: отсутствие локального доказательства не означает, что материал ничей, но и не дает оснований автоматически назначать авторство.
Проверка выявила три класса системных исправлений.
Первый — контракт названия. Предлагаемый для следующих подтвержденных миграций контракт хранит исходное название, каноническое системное имя и человекочитаемый заголовок представления. Он должен одновременно удержать узнаваемость авторского текста, навигацию Свода и понятный первый экран.
Второй — тип вклада. Валидатор не должен попадать в соавторы только потому, что проверял структуру. Содержательный соавтор, напротив, не должен исчезать за формулой «собрано системой». В проверенных объектах обнаружены разные ситуации: один подтвержденный вклад требует синхронизации после авторского и источникового gate, в другом случае экспертная проверка должна быть отдельно зафиксирована как валидация, а не авторство основного текста.
Третий — режим ретроспективной миграции. Исторические страницы не переписываются одной формулой. Для каждой волны сначала собирается evidence package, затем проходит source/title gate, после чего могут быть изменены только подтвержденные поля и первый экран. Основной корпус защищается от незапрошенного редактирования.
Результат аудита важен не числом проверенных строк, а тем, что сформирован воспроизводимый проект процедуры: источник, тип отношения, название, доступ, версия, решение и независимый gate. Его применение к конкретным страницам требует отдельных source/contribution gates и согласования изменений.
Существующие возможности и ресурсная граница
Системный инжиниринг требует проектировать не идеальную систему вообще, а систему, реализуемую в заданных ресурсах и жизненном цикле. Текущая архитектура уже содержит значительную часть необходимых функций:
- канонические страницы и профили на платформе;
- авторов и соавторов в метаданных;
- public, resident и private-доступ;
- комментарии как человекочитаемый след требований и решений;
- роли, кейсы и траектории;
- локальную библиотеку с выборочным составом;
- режим работы без обязательного подключения всего рабочего контура;
- явное подтверждение внешних действий;
- манифесты, версии и хеши сборок;
- возможность исправления и удаления платформенных объектов;
- Совет как действующий человеческий арбитраж.
Основной дефицит сейчас находится не в отсутствии еще одной сущности, а в связности этих механизмов. Авторство должно быть связано с источником, доступ — с зеркалом, релиз — с манифестом, требование — с критерием проверки, а рекомендация — с подтвержденным кейсом и квалификацией.
Ресурсы разработки и сопровождения ограничены. Поэтому на текущем этапе не программируются фрагментные permissions для каждого абзаца, новая универсальная rights-сущность, автоматические runtime-gates на все варианты использования и отдельный коммерческий движок распределения прав. Создание таких компонентов без повторяемого доказанного конфликта повысило бы сложность быстрее, чем надежность.
Техническое усложнение оправдано, когда существующая процедура перестает закрывать наблюдаемый риск. До этого момента предпочтительнее использовать действующие доступы, профили, комментарии, версии, закрытый RC, ручной evidence gate и решение Совета.
Неполные контракты и переходный институт
Ни одна текущая Оферта или программная модель не может заранее перечислить все будущие способы человеко-машинной работы с профессиональным знанием. Это не означает отсутствия правил. Это означает, что договорный контур неизбежно остается неполным: он задает базовые права, ограничения и процедуру, а новые пограничные случаи требуют интерпретации, фиксации и последующего уточнения.
Публичная научная постановка неполных контрактов дана в материале Альянса «Фабрика: от одного заказа к системе кооперационных цепочек». В этой статье понятие используется в общем институциональном смысле. Научная валидация его применения к текущей архитектуре запрошена у Елены Тищенко, но пока не получена; поэтому мы не приписываем Елене авторство или одобрение этой формулировки.
Альянс в этой логике действует как переходный институт координации профессионального знания и человеко-машинной работы. Он использует действующую Оферту, открытые компоненты платформы, неполные контракты, Совет, доступы, комментарии и проверяемые версии, пока рынок, право и экономика не создадут основание для более детальной юридической и программной инфраструктуры.
Переходность не означает временность ответственности. Наоборот, пока автоматические правила неполны, выше роль человека, источника и версии. Любое машинное действие должно оставаться внутри доступа; внешний перенос, отдельное обучение внешней модели или самостоятельный коммерческий ИИ-продукт требуют отдельного согласования; спорный случай возвращается к людям, а не разрешается статистическим решением агента.
Это и есть граница между координационной системой и автономной заменой экспертов. Система помогает удерживать связи и последствия решений, но не присваивает себе право говорить от лица автора, определять закрытость чужого вклада или окончательно разрешать конфликт интересов.
Итерационная эволюция небольшими связанными шагами
В рабочей архитектурной дискуссии Елена Тищенко предложила рассматривать будущую конструкцию как координационную систему и развивать ее небольшими связанными итерациями. Здесь кооперация — один из режимов совместного действия, а координация — более широкая архитектура ролей, правил, прав, ограничений, синхронизации, сопровождения и разрешения конфликтов.
Практический цикл выглядит так:
один связный шаг → проверка → обратная связь → новая версия.
Связность шага означает, что изменение не остается локальной редакционной правкой. Если исправляется авторство, одновременно проверяются source note, метаданные, каталог, манифест и будущая синхронизация. Если меняется доступ, проверяются зеркала и режим работы ИИИ. Если принимается новое требование, оно получает компонент, критерий, статус и версию.
Итерационная стратегия не снижает научную строгость. Она переносит строгость из обещания полной будущей системы в проверяемость каждого перехода. Вместо проекта идеальной модели прав создается ограниченный экспертный RC. Вместо общей декларации об авторстве проводится аудит конкретного корпуса. Вместо автоматической сертификации строится маршрут подтвержденного кейса, квалификационного gate и взаимной проверки версии.
Рабочее место эксперта и профессиональная рекомендация
Рабочее место эксперта должно отвечать не на вопрос «что система знает обо мне вообще», а на более строгий вопрос: с какими объектами связан подтвержденный профиль и в каком качестве.
Для каждого найденного объекта нужны URL, KA или DocKA, связь с RLTR, TR или TRxTR, уровень доступа, режим зеркала, версия и основание связи. Отношения разделяются на авторство, соавторство, участие, источник, валидацию и упоминание. Эксперт видит не только результат поиска, но и то, что требуется исправить или подтвердить.
Такой поиск не создает вторую базу экспертов. Он собирается из канонических объектов и доказательств платформы. Эксперт может поставить требование к конкретному объекту, а цифровой след и архитектурный контур проводят его через проверку и disposition.
Профессиональная рекомендация строится на подтвержденном кейсе и постановке эксперта на соответствующую эталонную траекторию. Дополнительно требуются актуальная квалификация и совпадение роли, стадии, задачи и границы метода. Авторство статьи, участие во встрече или активность на платформе сами по себе не дают профессионального допуска.
Общий рейтинг не заменяет квалификационный отбор и не является сертификатом компетенции. Он может дать дополнительный вес только внутри уже проверенного контура — за активность, вклад в развитие сообщества и пополнение общего знания. Сначала система отвечает на вопрос «подходит ли человек по доказательствам», и лишь затем может сравнивать несколько подходящих кандидатов.
Взаимная сертификация в этом контексте относится не к абстрактной личности и не к рейтингу. Эксперт проверяет, что конкретная версия корректно отражает его вклад и границу метода; архитектурный контур проверяет совместимость этого требования с общей системой; релиз подтверждает состав, доступ и хеш; при необходимости другой эксперт проверяет применимость. Сертифицируется конкретное отношение и конкретная базовая линия, а не человек навсегда.
Совет как человеческий арбитраж
Большинство требований можно разрешить редакционно и архитектурно: уточнить источник, изменить связь, сузить объект, сменить доступ, вернуть название, вынести материал в закрытый контур или поставить отдельный gate.
Если после этого остается конфликт, окончательное решение принимает Совет большинством присутствующих. До решения спорный объект может оставаться на ревью, в резидентском доступе или только в индексном представлении — в зависимости от характера риска.
Совет не заменяет source audit и не голосует вместо проверки фактов. На рассмотрение выносится уже структурированный пакет: объект, заинтересованные стороны, подтвержденные отношения, требование, риск, варианты, последствия для базовой функции, позиция архитектуры и критерий решения.
Такой арбитраж важен именно потому, что система координационная. Не всякий конфликт прав можно корректно свести к автоматическому правилу. В коллективном знании встречаются добросовестные, но несовместимые позиции: автор хочет максимально узкой границы, соавторы — сохранить общий материал, а система — не потерять открытый стандарт. Здесь нужна не имитация нейтральности алгоритма, а прозрачное человеческое решение с версией и основанием.
Закрытый RC и переходная базовая линия
Закрытый экспертный release candidate — не уменьшенная публичная версия и не архив замечаний. Это контролируемый объект, на котором можно проверить состав, происхождение, доступ, авторские отношения, глубину представления, работу локального поиска и поведение ИИИ до следующего расширения.
Закрытый экспертный RC 0.5.1-expert-rc.3 собран и прошел внутренний контур проверки со статусом CLOSED_EXPERT_RC3_PASS / SEND_HOLD: P0 live-readback и повторная чистая сборка завершены. Перед адресной отправкой остаются два организационных условия — утвержденный именной список получателей и согласованный канал передачи (named roster/channel), а также отдельное разрешение на отправку. Публичный GitHub-релиз, обновление post/3871 и комментарий под post/4220 остаются на HOLD; закрытые ссылки, пароли и внутренние материалы в публичную статью не переносятся.
После отдельного разрешения требования к конкретной версии предполагается фиксировать в комментариях к одному каноническому посту статьи или релиза. Отдельный параллельный реестр на платформе не создается. Комментарий остается человекочитаемым и может содержать компактные служебные поля: requirement_id; заинтересованную сторону; требование или наблюдаемый риск; класс; компонент; критерий проверки; статус; версию и хеш.
Такая ветка комментариев будет рабочим реестром требований к конкретной версии, а не юридическим реестром согласий. Цифровой след сохраняет требование, архитектура классифицирует его, Writer и технический контур вносят подтвержденные изменения, независимый gate проверяет результат, а Совет решает конфликт базовой линии.
Переходная базовая линия считается зафиксированной, когда известны состав версии, принятые и отложенные требования, открытые конфликты, режимы доступа, манифест и хеш; исправления авторства и названий подтверждены; а закрытый RC прошел адресную взаимную проверку после снятия предусмотренных release-gates. Это не финал системы, а надежная точка, от которой можно делать следующий связный шаг.
Когда понадобится более глубокая инфраструктура
Часть требований 45-страничного отзыва относится не к текущему пилоту, а к будущей зрелой системе: программным правам на фрагменты, раздельным согласиям по способам машинного использования, runtime-контролю, коммерческим экспертным агентам и более сложному распределению дохода.
Возврат к этим требованиям должен происходить по наблюдаемым условиям:
- появился устойчивый коммерческий контур;
- повторяются оплачиваемые профессиональные запросы через систему;
- значимое число экспертов регулярно работает в одном режиме;
- возникает самостоятельный коммерческий ИИ-продукт;
- планируется внешнее обучение модели;
- один и тот же конфликт прав или применения повторяется и не разрешается действующими доступами, протоколом и Советом.
До наступления этих условий преждевременная автоматизация создает ложную точность. После их наступления отсутствие программной поддержки станет уже измеримым системным ограничением. Тогда отложенное требование возвращается в архитектурную балансировку с новыми данными, владельцем ресурса и критерием результата.
Мы сознательно не используем в публичном тексте неподтвержденный экономический ориентир масштаба экспертного контура. Для инженерного решения достаточно качественного условия: коммерческий объем и повторяемость должны быть доказаны наблюдаемыми операциями, а не прогнозом.
Практический пример: как система разобрала десять требований
45-страничное ревью Алины Цуцу было переведено из общего возражения в десять проверяемых требований. Для каждого система отделила защищаемую потребность от предложенного способа реализации, сопоставила ее с позицией независимого системного рецензента и зафиксировала решение, статус и проверку.
| Требование | Позиция системного рецензента | Решение | Статус | Проверка |
|---|---|---|---|---|
| 1. Остановить открытое распространение до появления управляемой проверки прав, доступа и состава версии. | Выпуск должен быть воспроизводимым, а новая версия — проходить повторную проверку. | Открытое распространение остановлено на период закрытого тестирования, но развитие прототипа не заморожено. | ACCEPTED_MODIFIED |
Закрытый RC, манифест, SHA и install/update/readback gates; открытый релиз остается на HOLD. |
| 2. Развести публикацию текста, включение в Библиотеку и способы машинного использования. | Тип знания, машинная операция и политика исполнения — разные оси. | Открытый текст можно находить и объяснять с атрибуцией; внешнее обучение, самостоятельный коммерческий продукт и ответ от имени эксперта требуют отдельного основания. | ACCEPTED_MODIFIED |
Открытый, доверенный и личный контуры разведены; внешний перенос и speak_as_expert без согласования запрещены. |
| 3. Не превращать воспроизводимую авторскую методику в общую исполняемую инструкцию. | Закрытые веса, критерии и последовательность интерпретации должны быть отдельным модулем. | Эксперт предъявляет границу собственной методики, а система отделяет ее от общепрофессионального знания и архитектуры KA. | ACCEPTED |
Закрытый метод исключается из общего релиза либо остается карточкой и отдельным пакетом; ИИИ не говорит от имени эксперта. |
| 4. Признать агентную функцию skill и риск замещения экспертной работы. | Skill задает поведение ИИ, но сам по себе не становится автономным экспертом и не доказывает присвоение индивидуальной методики. | Агентная функция признана; утверждение о присвоении методики не подтверждено. | NOT_ACCEPTED_AS_STATED |
KA6 и skill отделены от индивидуальных методов; профессиональная проверка включается там, где самостоятельное движение не дает надежного результата. |
| 5. Развести автора, соавтора, участника, источник, редактора, архитектора и валидатора. | Главный риск — смешение ролей; карточка вклада должна собираться из канонических источников. | Отношение к материалу определяется подтвержденным вкладом, а валидация не превращается в соавторство автоматически. | ACCEPTED |
Введены типы вкладов и исправлены приоритетные ошибки авторства, валидации и названий. |
| 6. Сделать выпуск прослеживаемым по источнику, версии, доступу, составу и повторной проверке. | Состояния доступа нельзя смешивать, а смена версии сбрасывает прежнее подтверждение. | Прослеживаемость закреплена как общее релизное требование. | ALREADY_IMPLEMENTED |
Manifest, SHA-256, tree hash, clean export, fresh install, update, owner preservation и redownload gates. |
| 7. Дать эксперту возможность увидеть свой вклад, исправить атрибуцию, ограничить или удалить материал. | Представление должно строиться из канонических данных, а не создавать вторую базу. | Используются существующие профиль, каталог, ссылки, комментарии и локальный ИИИ; эксперт отмечает границы собственного вклада. | ACCEPTED_MODIFIED |
Profile match, дополнительный аудит вклада и штатные маршруты исправления и удаления. |
| 8. Сделать рекомендацию эксперта прозрачной и не заменять его работу открытым знанием. | Авторство, рейтинг и профессиональный допуск — разные отношения. | Рекомендация строится на подтвержденном кейсе, квалификации и соответствующей RLTR; рейтинг остается дополнительным весом внутри допуска. | ACCEPTED_MODIFIED |
Проверяются кейс, роль, стадия, задача, граница метода и доступность; авторство само по себе рекомендации не дает. |
| 9. Создать слой подключаемых экспертных модулей без раскрытия закрытой методики. | Тип знания, операция и политика исполнения должны быть разделены; глубокие разрешения нужны для реальных операций. | Приоритетно создается поэтапный открытый каталог модулей: открытая карточка в общей Библиотеке и отдельный закрытый или платный пакет авторской методики. Полные runtime-permissions проектируются позже по реальным модулям и операциям. | ACCEPTED_MODIFIED |
Сначала паспорт и карточка, затем версионированный закрытый пакет и каталог; runtime-gates — после подтвержденной необходимости. |
| 10. Создать governance требований, отзыва, конфликтов, Совета и повторной проверки версии. | Governance не должен дублировать источники истины и обязан поддерживать конфликт, отзыв и повторную верификацию. | После отдельного разрешения требования фиксируются в комментариях к одному каноническому посту, переводятся в рабочую очередь и при остаточном конфликте передаются Совету. | ACCEPTED_MODIFIED |
Статусы ведут требование от предложения через решение к реализации и проверке; новая обязательная программная сущность пока не создается. |
Итог этого разбора: девять из десяти требований приняты, изменены по способу реализации или уже реализованы. Одно требование не принято в исходной формулировке: наличие агентной функции признано, но присвоение индивидуальной методики не подтверждено. В пункте 9 отложена не задача экспертных модулей, а преждевременная разработка полной runtime-модели разрешений до появления реальных модулей, операций и повторяющихся ограничений.
Как система защищает релиз
Источник и доступ → авторство и роль вклада → режим full / index_only / exclude → clean export, no-leaks gate и правило one URL = one identity → fresh install и update tests → SHA и целостность архива → upload, обратное скачивание и повторная проверка → live readback и закрытие прежней ссылки.
Итог: не компромисс, а управляемая эволюция
Балансировка требований не означает выбрать среднее между экспертом и системой. Она означает сохранить базовую функцию, признать обоснованные риски, не смешать уровни решения и сделать каждый переход проверяемым.
45-страничный отзыв Алины Цуцу оказался ценен не тем, что дал готовую архитектуру, а тем, что превратил скрытые противоречия в требования. Исследовательская миграция оказалась ценна не тем, что была окончательной, а тем, что создала объект проверки. Аудит 242 объектов оказался ценен не количеством строк, а переводом принципов авторства, валидации и названий в конкретный контракт миграции.
Следующая базовая линия строится на нескольких простых, но строгих правилах: эксперт управляет своим подтвержденным вкладом; коллективная архитектура не закрывается одной стороной; ИИИ не говорит от имени человека; рекомендация опирается на кейс, квалификацию и траекторию; рейтинг остается дополнительным весом; спор разрешают люди; релиз проверяется по составу, доступу, версии и хешу.
Так координационная система развивается без двух крайностей — без бесконтрольного ускорения и без остановки до появления идеального права и идеального кода. Один связный шаг, проверка, обратная связь, новая версия: именно эта последовательность превращает конфликт требований в инженерный ресурс развития.
Связанные материалы
- DocKA0.1 «Модельно-ориентированный системный инжиниринг 2.0» — научная основа работы с функциями, компонентами, связями, ограничениями и жизненным циклом системы.
- Научная постановка неполных контрактов — публичная рамка переходного института; ее применение к текущей архитектуре требует отдельной научной валидации.
- Оферта Альянса — действующая рамка участия и использования материалов; статья не заменяет ее юридической интерпретацией.
- Свод знаний Альянса — открытая архитектура областей знаний и переход к применению.
- Рабочий контур проверки экспертного вклада — канонический объект для последующей фиксации требований после отдельного разрешения на комментарии.