Editorial AI Standard Knowledge Base

Базовый редакционный стандарт, из которого собираются разные AI-инструменты для редакции.

EAS-KB — не готовый промпт для одного чат-бота. Это набор редакционных принципов, методов и ограничений: общая отправная точка для редакционных ассистентов, фактчекеров, систем мониторинга, поиска тем, переводческих и редактирующих помощников, редакционных агентов, интеграций с CMS и исследовательских инструментов.

EAS-KBодин редакционный стандарт
↓
Fact-checkerпроверка утверждений
Editorial Assistantпоток и черновики
News Monitorсигналы и приоритеты
Court Monitorрешения судов
Translation Assistantперевод с атрибуцией
CMS Agentпубликация
Story Finderпоиск тем
One editorial foundation, many applications
13 модулей · 154 правила · 199 записей в реестре тестов · 12 внешних источников · 6 сентября 2026
Продолжение линии «Модель не читает мысли: контекст и база знаний редакции» и «Ассистент, который знает вашу редакцию».
↓ листайте

Не копировать вслепую. Адаптировать.

Одна и та же база у двух редакций даст два разных приложения — и это не дефект базы, а её устройство. Стандарт, который подошёл бы всем без настройки, был бы бесполезен каждому.

EAS-KB = baseline, not a universal newsroom policy.

EAS-KB
+
Newsroom rules
+
Application purpose
+
Language
+
Jurisdiction
+
Tools and permissions
=
Editorial AI application

Уже сделано за вас

  • 13 модулей канона
  • 154 сформулированных правила
  • методика проверки фактов
  • схемы профилей
  • набор проверочных сценариев
  • машиночитаемый реестр правил

Делаете вы

  • стандарты своей редакции и house style
  • местное право
  • язык
  • политика работы с источниками
  • правила использования ИИ
  • кто и на каком шаге утверждает публикацию

Основные редакционные модули

Канон — тринадцать модулей. Девять основных ложатся в четыре зоны ответственности; остальные три обслуживают сборку приложений, источники и релизную политику. Берут не всё сразу, а то, что нужно конкретному приложению.

Truth

01 принципы и иерархия правилприоритеты и ограничения
03 источники и researchкак оценивать источники и доказательства
04 верификацияметодика фактчекинга

Editorial judgment

02 редакционное суждение и разбор входачто перед нами, в чём новость, что проверять
05 fairness, независимость, общественный интересправо на ответ

Publication responsibility

06 приватность, вред, чувствительный контентдети, уязвимые люди
07 исправления и подотчётность

AI workflow

08 редакционное управление ИИответственность человека, синтетические медиа
13 рабочий процесс, контроль вывода и эскалация
04 · верификация — самый большой модуль, около 5 700 слов. Написан как редакционный учебник, с разбором формулировок и примерами: «задержан» ≠ «осуждён», «объявлено» ≠ «утверждено». Его можно брать в работу сегодня, ничего не адаптируя.

Fact-checking: не просто True / False

Проверка утверждения — это не один ответ, а последовательность решений. Рабочее состояние отдельно от вердикта, вердикт отдельно от уверенности, уверенность отдельно от того, что делать редакции.

Пример демонстрационный, не настоящий факт. Утверждение «количество случаев выросло вдвое»: система обязана отдельно спросить, откуда цифра, какой baseline, какой период, какая география, сопоставимы ли показатели и подтверждает ли источник именно двукратный рост.

CLAIMчто именно проверяем
↓
EVIDENCEчто нашли и что это доказывает
↓
WORK STATEработа не начата, идёт, завершена, заблокирована
↓
VERDICTвосемь статусов с разными условиями доказательности
↓
CONFIDENCEhigh · medium · low
↓
EDITORIAL RECOMMENDATIONчто делать редакции
Not checked ≠ Unsupported
Unsupported ≠ False
Someone said it ≠ It is true

Сначала определить, что именно мы строим

До того, как писать промпт, отвечают на восемь вопросов. Из этих ответов дальше выводится всё остальное — какие модули брать, что приложению разрешено и где стоит человек.

Purposeкакую проблему решает
Usersкто пользуется
Inputчто приходит
Outputчто должно получиться
Toolsк чему есть доступ
Actionsможет ли приложение что-то делать во внешнем мире
Risksобвинения, персональные данные, дети, суды, политика, breaking news
Human controlгде обязательно решение человека
Fact-checker Input: article / URL / claim Output: verification report Web search: allowed CMS publication: not allowed Human approval: required before publication

Как база превращается в приложение

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

Хороший промпт — только одна часть системы.

EDITORIAL KNOWLEDGE BASE
что правильно
↓
APPLICATION BRIEF
что мы хотим построить
↓
DEVELOPER SPECIFICATION
как правила превращаются в поведение приложения
↓
IMPLEMENTATION
prompt + knowledge + code + tools + UI
↓
TESTS
проверяем, работает ли это на самом деле

Спецификация переводит редакционные правила на язык продукта

Слева — редакционная норма, справа — то, во что она превращается в приложении. Норму нельзя выполнить «в целом»: у неё должны появиться поля, состояния и запреты.

Спецификация отвечает не только на вопрос «что должна сказать модель», но и «как должно вести себя приложение».

Unsupported claim must not be presented as fact.
work_state = not_checked verdict cannot be false evidence must be recorded limitations must be visible
Serious allegations may require a response from the affected party.
right_of_reply_required = true publication_gate = editor_review AI may draft outreach AI may not claim that outreach was sent unless the action actually occurred

Из чего состоит спецификация

Восемь разделов. Ни один из них не заменяется удачной формулировкой в промпте.

Workflowшаги материала
Statesnot_checked · checking · supported · unsupported · contradicted · blocked
Output schemaформа ответа, а не свободный текст
Tool permissionsк чему приложение имеет доступ
Approval gatesгде обязательно решение человека
Failure statesисточник недоступен, доказательств мало, инструмент упал
Logging / provenanceчто и на основании чего было сделано
Testsсценарии, на которых это проверяется

ИИ должен возвращать не только текст

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

{ "claim": "...", "work_state": "supported", "verdict": "verified", "confidence": "high", "evidence": [], "limitations": [], "safe_wording": "..." }

Контракт задан условиями, а не словами

В examples/evidence-record-contract.json записаны условия, которые машина проверяет сама:
If work_state is not completed_for_scope, verdict and confidence must be null. false requires at least one evidence record with direction contradicts. disputed requires at least one supports and one contradicts evidence record.
К контракту приложены десять проверочных случаев, часть из них заведомо неправильные — чтобы проверка ловила ошибку, а не только подтверждала успех.

Один стандарт, разные приложения и редакции

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

Не нужно делать отдельную копию всего стандарта под каждую редакцию.

EAS-KBобщий стандарт
APPLICATION PROFILEчто делает инструмент
purpose, users, inputs, outputs, capabilities, prohibited actions, risk profile.
Фактчекер может: извлекать утверждения, искать источники, оценивать доказательства, предлагать более осторожные формулировки. Не может: публиковать автоматически, выдумывать доказательства, связываться с источниками без разрешения.
NEWSROOM PROFILEкак работает редакция
язык по умолчанию, house style, политика права на ответ, разрешённые ИИ-инструменты, защита источников, порядок одобрения публикации, местные правовые требования.
DERIVED POLICYполитика этого инструмента в этой редакции

Recommendation ≠ Authorization ≠ Execution

Особенно важно для агентов. ИИ говорит «стоит запросить комментарий у мэрии» — редактор разрешает отправку — система действительно отправляет письмо через подключённую почту. Это три разных события, и путать их нельзя.

RECOMMENDATIONИИ предлагает
→
AUTHORIZATIONредактор разрешает
→
EXECUTIONсистема выполняет
"Story should be published" ≠ "Editor approved publication" ≠ "CMS published the story"
Когда что-то пошло не так, останавливается только затронутое действие, а работа, которую можно безопасно отделить, продолжается:
МаршрутКогдаЧто придерживаемЧто продолжаем
Ordinary editorрутинный выбор, фактов достаточно, спорного нетничего сверх обычного порядка публикациичерновик, отбор, вёрстка, ограниченная рекомендация
Senior editorсерьёзное обвинение, спорная идентификация, важная неопределённостьнеобоснованное утверждение, раскрытие личности, решение о публикацииразбор доказательств, черновик запроса на комментарий, нейтральный текст
Специалист с редакторомправовое ограничение, угроза конфиденциальности источника, безопасность ребёнказатронутое раскрытие, использование, сбор или внешнее действиезащищённое резюме, предложение по редактуре, узкий фактический анализ
Владелец приложенияподозрительная встроенная инструкция, чужой получатель, утечка данныхдействие инструмента или передача данныхкарантин, безопасное описание проблемы, работа без затронутого доступа

Не всё решается промптом

Промпт говорит модели, как себя вести. Знания дают методологию и справку. Код и runtime обеспечивают то, что нельзя надёжно оставить промпту.

Промпт говорит «не публикуй без одобрения», а runtime держит publish permission = false, пока editor_approval ≠ true.

Prompt cannot replace permissions.

EDITORIAL STANDARD
↓
APPLICATION POLICY
↓
system instructionsknowledgeoutput schematool permissionsruntime controlsapproval gatestests
↓
AI APPLICATION

Валидатор — это не ИИ

tools/validate_public_package.py — обычный тест целостности: на месте ли файлы, уникальны ли идентификаторы правил, сходится ли реестр с текстом, корректен ли JSON, нет ли мусора в публичной версии. Он может подтвердить, что правило VER-009 существует. Он не может подтвердить, что модель применит его правильно в сложной журналистской ситуации.

Валидатор проверяет

  • правильно ли собран стандарт

Поведенческие тесты проверяют

  • правильно ли ведёт себя ИИ
это совершенно разные проверки

Сделано в пакете

  • структура собрана и проверена
  • 154 правила с идентификаторами
  • реестр сценариев, которые надо проверить

Делаете вы, на своём приложении

  • прогоняете эти сценарии на своей модели
  • смотрите, как она себя ведёт на ваших материалах
  • решаете, что уходит в публикацию
Ни один документ не может гарантировать, что модель поведёт себя правильно. Это проверяется только на вашем приложении и вашими материалами — и решение остаётся за редакцией.

Практический порядок

Семь шагов от редакционной задачи до работающего инструмента. Канон берут не целиком, а той частью, которая относится к делу.

Берите только релевантную часть канона.

Выбрать редакционную задачу
Описать Application Brief
Выбрать нужные модули
Сделать Developer Specification
Собрать промпт, знания и инструменты
Добавить правила своей редакции
Протестировать на реальных сценариях
Задача: Press Release Editor Нужные модули: принципы, редакционное суждение, источники, верификация, рабочий процесс Не обязательно: весь модуль приватности, сложный судебный workflow

Две формы одного стандарта

Одни и те же правила нужны двум разным людям в двух разных видах: редактору — текстом, который читают, инженеру — реестром, который подключают.

Не два стандарта, а два представления одного.

EAS-KB
EDITORIAL REFERENCEредакторам и тем, кто пишет промпты
модули для чтения человеком, методика проверки, редакционное суждение, fairness, приватность, исправления, принципы работы с ИИ, процессы.
DEVELOPER COMPANIONразработчикам и инженерам
деривация приложений, реестр правил, схемы, профили приложений и редакций, реестр тестов, фикстуры, валидатор.

База знаний говорит, что правильно.

Спецификация говорит, как это должно быть реализовано в конкретном приложении.

Промпт говорит модели, как вести себя внутри этой реализации.

Код обеспечивает то, что нельзя надёжно оставить промпту.

Тесты проверяют, работает ли всё это на самом деле.

↓ Скачать базуКак этим пользоваться
EAS-KB is a starting point. Adapt, test, review.
1 / 16