Асистент прес-служби, який знає дату: архітектура TRACE для текстів від імені посадовця

Найнебезпечніша помилка в дописі посадовця не безграмотна, а правдоподібна. Ця стаття — про те, як розкласти AI-асистента прес-служби за чотирма шарами TRACE так, щоб такі помилки зупиняв код, а не прохання в промпті.

Помилка, яку не помітить ніхто, крім усіх

Уявіть звичайний ранок прес-служби. Треба написати допис від імені керівника: подякувати партнерам, згадати двох посадовців, назвати установу, дати одну цифру. Мовна модель зробить це за двадцять секунд, і текст буде гладким.

Тепер уявіть, що один із названих посадовців тиждень тому перейшов на іншу посаду. Установа півроку тому змінила назву, і стара досі трапляється в половині архівних дописів. А цифра правильна, але минулорічна. Жодна з цих помилок не виглядає як помилка. Вони проходять повз втомленого редактора і стають видимими лише тоді, коли їх помітять читачі, тобто всі одразу.

Звичайна відповідь на це — «додамо RAG». Але векторне сховище повертає найсхожіший фрагмент, а не той, що був чинним на дату публікації. Для нього «керівник департаменту» з дописів за три роки і «керівник департаменту» з минулого тижня — майже той самий вектор. Питання «хто ким був на дату допису» — це питання до часу, а не до схожості.

Я спроєктував і зібрав пілот такого асистента для прес-служби посадовця. Нижче — архітектура, а не історія конкретного замовника: ім’я, канал і установу я свідомо не називаю. Мене цікавить, що з цього переноситься на будь-яку прес-службу.

Що система робить і чого не робить

Межі визначено першими, бо від них залежить усе інше.

Робить: готує чернетку допису в стилі керівника за коротким завданням; перевіряє в ній кожне ім’я, посаду, назву установи, число й дату проти темпорального графа знань; позначає неперевірене; веде журнал, хто і коли погодив текст; після затвердження записує допис і його твердження назад у граф.

Не робить: не публікує. Інструмента публікації в системі немає взагалі, а мережа робочого середовища не пропускає до месенджера. Затверджений текст людина копіює і публікує сама. Агент також не формулює позиції, оцінки й обіцянки від першої особи з власної ініціативи: такі речення система розпізнає і відправляє на погодження керівництву.

Це не обмеження пілоту, а принцип: агент — інструмент прес-служби, а не замінник позиції керівника.

Чому саме TRACE

TRACE — інженерний фреймворк для агентних систем в операційно-критичних доменах. Його рамкова стаття (arXiv:2605.03838) поєднує чотиришарову референсну архітектуру з явним розподілом між класичним ML і LLM-валідаторами, набір метрик довіри, прив’язаних до метрологічних стандартів GUM, VIM та ISO/IEC 17025, і принцип економності моделі. Ключова думка: використати велику мовну модель — це свідоме проєктне рішення, а не архітектура за замовчуванням.

До прес-служби фреймворк пройшов кілька доменів, і кожен додав щось, що знадобилося тут.

• Клінічна підтримка рішень (arXiv:2604.26671). Перший інстанс: детерміноване клінічне ядро, асистент, який валідує контекст конкретного пацієнта, ярусна ескалація моделей і лікар як останній рецензент. Звідти — вибіркова перевірка саме критичних тверджень і обмежений, датований контекст.
• Промислова мультидоменна платформа для видобування нафти й газу. Той самий поділ на шари в трьох піддоменах (технології, експлуатація, документообіг) показав, що домінантний шар зміщується з типом доказів. Для сигналів датчиків головну роль відіграє класичне ML, а для правил і текстів — детерміноване ядро плюс LLM-валідатори. Прес-служба — випадок другого типу. Детерміноване ядро цієї лінії можна подивитися наживо: демо бурової блокувальної перевірки на відкритих даних Utah FORGE з принципом «неоцінене ≠ пройдене».
• Судова аналітика (Zenodo, 10.5281/zenodo.22128390). AI-асистент для порталу правових позицій Верховного Суду: модель готує проєкт правової позиції з тексту рішення, уповноважений працівник суду його затверджує. Це найближчий родич прес-служби. Там само чернетку пише модель, а підпис ставить людина. Там само шар L3 трактується як нормативний документ, яким керують без участі розробників.
• Інституційні системи загалом (AIID-2026, 10.5281/zenodo.22917150). Теза про TRACE як розподіл когнітивного навантаження між шарами ШІ і людиною. Підхід «мовна модель для всього» породжує автоматизаційне упередження і непрогнозоване навантаження на операторів. Значущий людський нагляд вимірюється індексом навантаження на рецензента і часткою скасувань.
• Контракт гарантій під час виконання (arXiv:2609.39717, код, Zenodo). Формальна схема, за якою провалена або неоцінена обов’язкова перевірка змушує агента повторити, ескалювати, відкласти чи зупинитися. Сукупна оцінка не може дозволити дію. Звідси правило, на якому тримається затвердження допису: зелені позначки не компенсують одну червону.
• Дослідницький агент наукової школи (блог). Та сама логіка в науці: кожне число в рукописі має ланцюг доказів до артефакту на диску, а агент не вірить собі на слово.

Прес-служба виглядає легшим доменом: ніхто не помре від невдалого допису. Але структура ризику та сама. Є публічна відповідальність конкретної людини, є правдоподібна помилка, яку дорого спростовувати, і є спокуса довіритися гладкому тексту. Чим цей інстанс новий: часом. У попередніх доменах контекст здебільшого або фізичний, або нормативний. Тут він біографічний: хто ким був і як називалася установа саме на дату тексту.

TRACE розкладає систему на чотири шари:

Далі — що саме лежить у кожному шарі і чому.

L1. Граф знань, який знає дату

Серце системи — темпоральний граф знань. Він має два шари.

Канон веде людина. Це люди, посади, установи, місця, теми. Кожна посада — ребро з датами valid_from і valid_to. Кожна установа має історію назв із періодами. Стара назва не зникає, а стає аліасом з датою, до якої вона була чинною.

Епізоди — дописи і твердження з них. Їх видобуто з архіву каналу за кілька років: кожне твердження має тип (факт, обіцянка, офіційна позиція, оцінка), дату події, якщо вона відома, і дослівну цитату з допису. Код перевіряє, що цитата символ у символ збігається з фрагментом тексту. Твердження, якого немає в тексті, відкидається до потрапляння в граф.

Три рішення виявилися важливішими, ніж здавалося на старті.

«Граф не знає» — це не «граф заперечує». Багато посад відомі лише з дописів: перша й остання згадка, а не дата призначення і звільнення. Такі межі позначено як precision: attested. Якщо дата публікації виходить за них, перевірка не каже «помилка», а каже «граф цього не знає, перевірте». Різниця між суперечністю і незнанням — головне, що відрізняє корисну перевірку від дратівливої. Без неї система або мовчить, або кричить на кожне ім’я. Це той самий принцип, що й у буровій блокувальній перевірці: неоцінене — окремий стан, а не мовчазне «пройдено».

Граф лише доповнюється. Виправлення факту — це нове твердження і ребро SUPERSEDES до старого, а не редагування. Граф зберігається як текстові файли в git (YAML для канону, JSONL для епізодів), тож час запису дає історія комітів. Стан знань на будь-який момент відновлюється з git. Це дешева бітемпоральність: «коли це було правдою» лежить у ребрах, «коли ми про це дізналися» — у git.

Пошук за лемами, а не за рядками. Українська мова відмінює імена й назви. «Петренка», «Петренкові» і «Петренком» — одна людина, і пошук має це знати. Тому індекс будується за множинами лем (pymorphy3 з українським словником), а аліаси канону розгортаються в запит автоматично.

Індекс — SQLite з повнотекстовим пошуком. Він похідний: не комітиться, збирається скриптом за кілька секунд на старті кожної сесії. Сервера бази немає, векторної бази теж.

До L1 належать і детерміновані перевірки чернетки: ліміти довжини каналу, стоп-список (дані воєнного часу блокують затвердження, кальки й канцеляризми лише позначаються), посади й назви установ на дату публікації. Якщо межа посади точна і дата за нею — це помилка. Якщо межа «за згадками» або запису немає — попередження.

L2a порожній. Це рішення, а не пропуск

Шостий принцип TRACE — економність моделі: тип навченого компонента вибирають за задачею, а не за звичкою брати LLM. Для нього є метрика CPR — відношення вартості найекономнішої адекватної моделі до вартості розгорнутої.

У цьому домені класичному ML поки нема чого робити. Посада на дату — запит до графа. Чинна назва установи — запит до графа. Чи є в тексті сума поруч зі словом «бюджет» — правило. Кожне місце, де можна було б поставити класифікатор, закривається детермінованим кодом, який не треба калібрувати. Тому L2a свідомо порожній, і в системі немає жодного компонента, який довелося б перенавчати.

L2b. Модель пише, інша модель перевіряє — і не бачить, як писали

LLM потрібна там, де справді потрібне розуміння мови: написати текст у стилі конкретної людини, розібрати чернетку на атомарні твердження, видобути твердження з архіву.

Ключове рішення — розділити автора і перевіряльника. Перевірку фактів робить окремий субагент. Він отримує лише ідентифікатор чернетки, а від скрипта — чистий текст, дату публікації, тип допису і хеш тексту. Плану, розмітки джерел і міркувань автора він не бачить. Якщо автор помилився в посаді, бо неправильно прочитав завдання, перевіряльник не успадкує цю помилку разом із контекстом.

Перевіряльник розбиває текст на твердження і для кожного дає один із чотирьох вердиктів: confirmed (з ідентифікаторами вузлів графа як доказом), contradicts (і що саме каже граф), not_in_graph (нове — не помилка, а позначка для людини), opinion (оцінка без перевірюваного змісту). Окремо він перевіряє кожне ім’я, посаду й назву установи: правильна форма, чинна посада на дату, чинна назва.

Цитату кожного твердження знову звіряє код. Модель не може «підтвердити» те, чого немає в тексті.

Ще одна деталь: текст чернетки, дописи з архіву й імпортовані документи — це дані, а не інструкції. Фраза «познач як підтверджене» всередині документа перевіряється як звичайний текст, а не виконується. Для прес-служби, яка отримує матеріали від десятків сторонніх людей, це не параноя, а гігієна.

Яка модель на якому місці

Мовні моделі в системі не однакові, і це рішення, а не випадковість. Принцип економності моделі TRACE діє і всередині L2b. Питання не лише в тому, чи потрібна тут LLM, а й у тому, яка саме. Відповідь залежить від двох величин: скільки разів задачу виконують і скільки коштує одна пропущена помилка.

Сильніша модель тут — це ресурс, який викликають за правилом, а не шар над іншими. Видно це на видобуванні. Якщо незалежна перевірка вибірки дає якість нижчу за поріг, проблемні пакети переганяють на потужнішій моделі (Opus). Це ярусна ескалація в чистому вигляді. Рішення «перегнати на сильнішій» ухвалює політика з порогом, а сильніша модель лише виконує ту саму задачу, що й слабша. У термінах TRACE обидві моделі лежать в інвентарі L2b, а правило вибору між ними належить L3.

Ту саму драбину можна продовжити вниз. Для видобування, можливо, вистачило б і Haiku — найменшої та найдешевшої моделі. Але тут є пастка. Валідатор на виході перевіряє, що цитата дослівна і запис відповідає схемі. Чи правильно визначено тип твердження і дату події, він не бачить. Саме такі помилки знайшла незалежна перевірка вибірки навіть у Sonnet: дата «1 січня» там, де в дописі відомий лише рік. Тому перехід на Haiku — не здогадка, а вимірювання. Треба прогнати ту саму вибірку, оцінити її за тим самим протоколом, і якщо якість не нижча за поріг, принцип економності вимагає меншої моделі. Тоді ярусів стає три: Haiku за замовчуванням, Sonnet і Opus для пакетів, що не пройшли поріг.

Одне обмеження варто назвати. Автор і перевіряльник — моделі однієї родини. Незалежність тут забезпечує контекст: перевіряльник не бачить міркувань автора. Але модель іншої родини дала б ще й незалежність помилок, бо дві моделі однієї родини частіше помиляються однаково. Для пілоту цього достатньо. Для постійної роботи перевіряльника іншої родини варто розглянути, як у дослідницькому агенті, де автор ніколи не буває суддею.

L3. Ескалація як нормативний документ

У TRACE L3 — це політика, яка вирішує, коли результат іде на вищий ярус. У прес-службі вищий ярус — це люди з правом погодження.

Правила ескалації оформлено не як налаштування в коді, а як нормативний документ прес-служби: людський текст і один машиночитаний блок YAML з версією та полями «хто затвердив» і «коли». Код читає цей блок, а змінює його керівник прес-служби через окрему навичку з явним підтвердженням. Зміна тону чи правил ескалації — рішення людини з датою, а не коміт розробника.

Погодження керівництва вимагають чотири види речень:

1. нова обіцянка від першої особи;
2. офіційна позиція щодо суспільного питання;
3. цифри бюджету — сума поруч зі словами «бюджет», «кошторис», «фінансування» в тому самому реченні;
4. оцінка від першої особи.

Ескалацію визначають двічі й незалежно: детерміновано за текстом (тригерні леми, тип допису, числа з грошовими одиницями) і за типами тверджень, які знайшов перевіряльник фактів. Збіг двох каналів — додаткова надійність, розбіжність — сигнал для людини.

До L3 належить і життєвий цикл чернетки: planned → drafted → checked → approved | rejected. Перехід між станами робить лише скрипт.

Найслабше місце: мовна модель сесії виконує частину роботи L3. За каноном TRACE L3 — це політика зі станом над інвентарем L2, а не мовна модель. Підхід, де LLM-оркестратор керує ієрархією LLM-агентів, змішує вибір класу моделі з політикою її виклику (arXiv:2605.03838). У цій системі так розділити все не вдалося. Модель хмарної сесії Claude Code вибирає навичку за реплікою оператора і вирішує, коли кликати субагентів. Ці рішення ймовірнісні. Тому все, що має бути гарантовано, винесено з її рук. Перехід між станами робить скрипт, ескалацію визначають правила з нормативного документа, затвердження потребує трьох обов’язкових умов, а хук не дає завершити хід із неперевіреною чернеткою. Модель може помилитися з маршрутом, але не може обійти ці умови. Її помилки маршрутизації вимірюються окремим тестом. Модель сесії в налаштуваннях не закріплена, тож після її оновлення тест треба проганяти знову: нова модель може інакше розуміти ті самі описи навичок.

L4. Людина, без якої текст не затверджується

Затвердити чернетку може тільки скрипт, і тільки за трьох умов. Усі три обов’язкові й не компенсують одна одну — так, як це сформульовано в контракті гарантій під час виконання:

• перевірка фактів відповідає поточному тексту. Результат перевірки прив’язаний до SHA-256 тексту. Змінили кому після перевірки — перевірку треба повторити;
• правила пройдено, а кожна суперечність з графом закрита з причиною;
• погодження записано, якщо спрацювала ескалація: хто, коли і через який канал.

Після затвердження допис і його твердження йдуть у граф як нові епізоди з позначкою «перевірено людиною». Цикл замикається: наступна чернетка перевірятиметься і проти цього тексту.

Тут є чесне обмеження, яке варто назвати. На пілоті системою працює один оператор з одного облікового запису. Умови користування забороняють давати свій акаунт іншим, а командного тарифу поки немає. Тому погодження керівника записує оператор з його слів. Журнал фіксує засвідчене, а не підписане погодження, а повідомлення в месенджері лишається другим джерелом. Для пілоту це прийнятно. Для постійної роботи — ні: кожен, хто погоджує, має працювати від власного облікового запису.

Гарантії тримаються на коді, а не на промпті

Найважливіший принцип усієї системи: інструкція моделі — це побажання, а хук і скрипт — гарантія. Тому я окремо розписав, що в системі ймовірнісне, а що ні.

Там, де модель лишається ймовірнісною, стоїть запобіжник. Навички, які змінюють дані (факти графа чи норми), спершу показують зміну і чекають явного «так». Хибний виклик навички нічого не зіпсує, а лише поставить зайве питання.

Інтерфейс — телефон

Прес-секретар не сидить за терміналом. Тому інтерфейс — хмарна сесія Claude Code на приватному репозиторії, відкрита з телефону. Оператор пише або надиктовує завдання звичайною мовою: «підготуй допис про…», «перевір факти», «додай у граф, що…».

З цього випливають два архітектурні рішення. Перше: уся логіка — навички, субагенти, хуки — живе в самому репозиторії, а не в плагіні, бо плагіни в хмарних сесіях не встановлюються. Друге: кожна зміна чернетки, графа чи норм — окремий коміт, який одразу пушиться, бо віртуальна машина хмарної сесії може зникнути разом із незбереженою роботою.

Репозиторій тут одночасно і код, і база знань, і журнал відповідальності. Це спрощує аудит: усе, що сталося, — у git log.

Як це міряти

Метрологічна частина TRACE вимагає, щоб кожну властивість якості специфікували і вимірювали до запуску, а пороги погоджували із замовником заздалегідь, а не підганяли потім.

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

Окремо про OvR. Дуже низька частка скасувань — не обов’язково добрий знак: вона може означати, що людина перестала читати. Тому її читають разом із сліпим тестом і розбором правок, а не окремо. Про автоматизаційне упередження як головний ризик інституційних систем я писав окремо (AIID-2026), а про те, чому довіру треба вимірювати, а не відчувати, — у попередньому дописі.

Чесний стан на сьогодні. Систему зібрано, наскрізний локальний прогін пройдено, граф видобуто з архіву і канон затверджено. Тест маршрутизації — 64 з 64 реплік на правильну навичку, жодного хибного виклику навичок, що змінюють дані. Але це синтетичний набір: він перевіряє інтерфейс, а не корисність. Пілот із реальними дописами попереду, і цифр, які можна чесно назвати ефективністю, поки немає. Я напишу про них, коли вони будуть.

Що переноситься на іншу прес-службу

Майже все. Для іншого керівника змінюються канон (люди, посади, установи), норми (профіль стилю, стоп-список, правила ескалації) і правила каналу. Ядро — граф, перевірка, затвердження, хуки — лишається тим самим. Facebook, LinkedIn чи Viber додаються як адаптери з власними правилами каналу, без змін у ядрі.

Головний урок ширший за прес-службу. Модель дає швидкість, але довіру дає архітектура: детерміноване ядро, яке знає дату; незалежна перевірка, яка не бачить міркувань автора; правила ескалації, які пише людина; і людина, без підпису якої текст не стає текстом.

Джерела

1. Zabolotnii S. TRACE: A Metrologically-Grounded Engineering Framework for Trustworthy Agentic AI Systems in Operationally Critical Domains. arXiv:2605.03838, 2026. https://arxiv.org/abs/2605.03838
2. Zabolotnii S., Holinko V., Antonenko O. From Black-Box Confidence to Measurable Trust in Clinical AI: A Framework for Evidence, Supervision, and Staged Autonomy. arXiv:2604.26671, 2026. https://arxiv.org/abs/2604.26671
3. Заболотній С., Бабанли Р., Павленко Ю., Литвиненко І. Від судового рішення до правової позиції: автоматизація юридичного аналізу засобами штучного інтелекту в практиці Верховного Суду. Препринт, Zenodo, 2026. https://doi.org/10.5281/zenodo.22128390
4. Заболотній С. TRACE: архітектурна декомпозиція когнітивного навантаження в інституційних системах штучного інтелекту. AIID-2026, Одеса, 2026, с. 9–12. https://doi.org/10.5281/zenodo.22917150
5. Zabolotnii S. Trust Is Not a Score: Runtime Assurance Contracts for High-Risk AI Agents. arXiv:2609.39717, 2026. https://arxiv.org/abs/2609.39717 · код: https://github.com/SZabolotnii/TRACE-RAC-code-supplement · https://doi.org/10.5281/zenodo.23410711
6. Демо бурової блокувальної перевірки TRACE на відкритих даних Utah FORGE 58-32. https://drill-ai-gate.traces.solutions
7. Заболотній С. Агент, який не вірить собі на слово: як я розбудував на основі AutoSci дослідницький фреймворк для наукової школи. Блог, 2026. https://blog.szabolotnii.site/posts/autosci-research-framework-uk/
8. Заболотній С. Якщо довіру до AI не можна виміряти — її не існує. Блог, 2026. https://blog.szabolotnii.site/posts/trust-in-ai-part7-uk/

TRACE: traces.solutions.