IRONSTICK← Головна сторінка

IRONSTICK — Міст настільного ШІ

Один локальний міст, чотири рівноправні настільні ШІ — Claude Desktop / Claude Code, ChatGPT Desktop, Qwen Desktop і Kimi Desktop — плюс вбудований чат ШІ IRONSTICK. Що таке міст, як він ліцензується, як він співвідноситься з чатом у застосунку, як його встановити, як відображається кожен доступ, що з ним можна робити — і повний каталог із 175 інструментів. Видання для Windows.

1. Що таке міст

Міст з’єднує Ваш власний настільний ШІ — Claude Desktop (або Claude Code), ChatGPT Desktop, Qwen Desktop чи Kimi Desktop — із запущеним застосунком IRONSTICK на тому самому комп’ютері. Після цього ШІ може читати матеріали Ваших справ через спеціально створені інструменти — хроніки, повні тексти документів, електронні листи, строки, основні дані — і працювати з ними на повну глибину: аналізувати, перевіряти, складати проєкти. З’єднання суворо локальне (127.0.0.1); жоден сервер IRONSTICK не задіяний. Дані, які читає ШІ, обробляються в межах Вашої власної підписки в цього постачальника та на його умовах — повний опис міститься в декларації GDPR про потоки даних.

• Потрібен відповідний настільний застосунок із власним обліковим записом (Anthropic, OpenAI, Qwen або Kimi).
• Працює лише доти, доки запущено IRONSTICK — коли застосунок закривається, закривається і джерело даних.
• Цей канал свідомо передає справжні, непсевдонімізовані дані — саме це дає змогу складати шаблони, готові до подання.
• Документи, позначені як секретні, для мосту невидимі.
• Спільна для всіх чатів пам’ять ШІ створена для тривалих проваджень: записи в активній справі ніколи не спливають, і кожне використання поновлює їхній строк життя — лише мертвий матеріал застаріває через рік.
• Доступ на запис свідомо вузький: пропозиції потрапляють до монітора узгодженості даних на Вашу перевірку; проєкти передаються до текстового процесора; ніщо не записується безпосередньо у Ваші записи.

1b. Навіщо міст?

Тому що робота через підписку зазвичай у рази дешевша, ніж через API. Настільний ШІ працює на фіксованій підписці, яку Ви й так маєте в постачальника; кожен діалог, кожне читання повного тексту, кожен раунд складання проєкту покриваються нею. Та сама робота через вбудований чат IRONSTICK працює на Вашому API-ключі й оплачується за кожен токен — у довгих діалогах над великими справами це швидко накопичується.

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

1c. Ліцензування — чотири мости або пакет

Кожен доступ настільного ШІ — це окремий ліцензований додатковий модуль:

• Доступність закладена у Вашому підписаному ліцензійному ключі: створюються лише ліцензовані мости — неліцензований міст не має інтерфейсу, не має поверхні інструментів і не з’являється в конфігурації.
• Ви ліцензуєте один окремий міст (лише для того настільного ШІ, яким Ви користуєтеся) або пакет із усіх чотирьох — з можливістю розширення пізніше.
• Ліцензовані мости можуть працювати паралельно; над однією справою можуть одночасно працювати кілька настільних ШІ.

1d. Вбудований чат ШІ IRONSTICK — та сама модель, плюс Gemini, без додаткової ліцензії

IRONSTICK також має власний вбудований чат ШІ, і він працює на точно тому самому робочому рівні, що й міст — ті самі інструменти, ті самі шлюзи, та сама прив’язка до джерел і те саме складання шаблонів, готових до подання. Що вміє міст, те вміє й чат у застосунку. Окрім чотирьох постачальників мосту, він додатково пропонує Gemini від Google як постачальника.

• Без додаткової ліцензії. Чат у застосунку вбудований в IRONSTICK; йому не потрібен жоден додатковий модуль мосту.
• Він працює через API постачальників (Ваш власний API-ключ) з оплатою за токени. Оскільки тарифи API дещо вищі, ніж фіксована підписка, чат у застосунку в щоденному використанні може бути дорожчим, ніж використання мосту разом із настільним застосунком постачальника — де модель підписки значно вигідніша.
• Натомість шлях через API в IRONSTICK краще контрольований і керований: псевдонімізація маршрутизатором, діалог згоди, журнал аудиту та обмеження розміру — на тих самих шлюзах, що й міст.

2. Встановлення (кожного з чотирьох)

Порядок дій однаковий для кожного настільного ШІ; відрізняються лише джерело завантаження та кнопка налаштування.

1. Встановіть настільний застосунок, увійдіть під власним обліковим записом і один раз запустіть його (див. рядок постачальника нижче).
2. В IRONSTICK відкрийте Конфігурація → Конфігурація ШІ → ШІ з локальним MCP-сервером (STDIO).
3. Увімкніть «Дозволити доступ конектора для локального настільного ШІ» (це головний перемикач усього каналу).
4. За бажанням увімкніть «Дозволити навігацію настільним ШІ», якщо ШІ може також керувати застосунком — відкривати екрани, справи й документи, експортувати файли. Читання працює й без цього.
5. Натисніть відповідну кнопку «Налаштувати … Desktop». IRONSTICK розгортає власний екземпляр мосту й сам вносить його до настільного ШІ — нічого не потрібно вставляти, нічого не потрібно вводити.
6. Почніть нову розмову (або натисніть у тому самому розділі «Перезапустити настільний ШІ»). Після цього IRONSTICK з’явиться серед конекторів ШІ, а наведені нижче інструменти будуть доступні в кожній розмові.

Екран конфігурації містить посилання для завантаження та посилання на умови використання й політику конфіденційності кожного постачальника.

3. Як доступи відображаються в рядку меню

• Спершу згода. Коли настільний ШІ під час роботи програми вперше торкається даних, IRONSTICK показує блокувальний діалог підтвердження. Відмова блокує цей канал на 10 хвилин; згода відкриває його до кінця роботи програми.
• Власний логотип ШІ з’являється в заголовному рядку поруч з індикатором CPU/RAM під час кожного окремого виклику інструмента і залишається яскравим 3 секунди після останнього виклику — швидкі серії викликів тримають його яскравим безперервно. Якщо символ темний, нічого не читається. Кожен ШІ має власний знак: помаранчева зірка Claude, зелений вузол OpenAI, фіолетовий символ чату Qwen, бірюзова «K» Kimi.



• Випадне меню біля символу ШІ показує, що цей ШІ прочитав під час сеансу: рядок «Робоча інструкція + заборона галюцинацій» (зелена галочка, доки вона дійсна, червоний хрестик після спливу), потім для кожної справи позначки Профіль, Юрисдикція та Дайджест, а також смугу «Прочитано документів r з n».
• Символ мозку з’являється, щойно спільна пам’ять ШІ містить записи, і пульсує 3 секунди щоразу, коли будь-який канал ШІ читає її чи записує до неї. Клік відкриває діалог керування; сам ШІ ніколи не може видаляти пам’ять.
• Навігація з боку ШІ (відкриття екранів/справ/документів) відбувається лише тоді, коли її перемикач УВІМКНЕНО — інакше інструменти навігації відхиляються.
• Паралельний доступ: якщо кілька ліцензованих ШІ працюють одночасно, заголовний рядок показує по одному пульсуючому логотипу для кожного активного ШІ поруч; кожен доступ завжди приписується тому ШІ, який його здійснив.

4. Що Ви з цим робите — приклади

Говоріть із настільним ШІ (або з чатом у застосунку) звичайною мовою; він сам обирає відповідні інструменти. Типові запити:

5. Примітка щодо даних

6. Технічний довідник

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

4. Шістнадцять детермінованих шлюзів проти галюцинацій і для безпеки

IRONSTICK не намагається виховувати підключений ШІ промптами — він забезпечує правильність структурно. Шістнадцять детермінованих шлюзів (чиста логіка, жодного ШІ) стоять між моделлю та Вашими записами. У всьому каталозі інструментів нижче інструменти, захищені шлюзами, мають позначку ШЛЮЗ.

Контекст і навігація

Пошук потрібного запису

Читання справи

Документи та пошук уривків

Судді та судові рішення

П’ять детермінованих інструментів (жодного ШІ) для одного запитання: як вирішує окремий суддя чи прокурор — що він бере з подань, що оминає, наскільки він передбачуваний? Інструменти знаходять і вимірюють; читання рішень і їх оцінка залишаються роботою ШІ, на повних текстах. Рішеннями вважаються лише вхідні документи від суду чи прокуратури.

Зцілення повторним OCR-скануванням — мікросорсинг із людиною в циклі

Коли збережений повний текст виявляється урізаним або зіпсованим старим запуском OCR, ШІ не просто мириться з цим — він зцілює базу даних, а Ви є остаточною інстанцією. Він запитує свіже сканування; Ви обираєте сторінки в IRONSTICK (той самий вибір сторінок, що й під час захоплення документів); повторний скан детерміновано нормалізується (водяні знаки видаляються, шаблони OCR виправляються, пробіли вирівнюються) і розміщується у сховищі чернеток ПОРУЧ із поточним текстом бази даних. Потім ШІ порівнює обидві версії уривок за уривком, залишає правильний варіант, виправляє лише механічні пошкодження OCR — ніколи не перефразовуючи; цифри, імена та суми залишаються недоторканими — і повертає зцілену версію. IRONSTICK показує її Вам повністю, і лише ВАШ клік зберігає її як новий повний текст.

Крок далі: юрист як інструмент точності. ШІ використовує IRONSTICK не лише як джерело даних — там, де автоматична обробка натрапляє на фізичні межі, він свідомо звертається до Вас як до візуального інструмента точності:

• Повна працездатність навіть із гігантськими файлами. Коли PDF перевищує будь-який контекст ШІ (міст застосовує жорсткі межі: 10 МБ, 90 сторінок), процес не закінчується марним «файл завеликий» — натомість ШІ називає точне місце: «сторінка 12, ближче до верху».
• Цілеспрямоване мікрозусилля замість археології файлів. Вам ніколи не доводиться прочісувати файл на 200 сторінок. Ви натискаєте скріпку в записі, який IRONSTICK уже відкрив для Вас, переходите на названу сторінку й передруковуєте саме ті три нерозбірливі слова чи цифри.
• Прямий зворотний зв’язок у повний текст. Ваша транскрипція переноситься дослівно в зцілену версію, проходить той самий діалог прийняття, і аналіз безперешкодно продовжується.

Традиційні системи знають рівно два стани: «успіх» (що б не видав OCR, правильно чи неправильно) і «помилка — будь ласка, обробіть документ вручну». Тут юрист стає мікровиконавцем саме для тих 0,1 % скану, які ШІ не може розв’язати з упевненістю, — симбіоз швидкості ШІ та людського зору.

Електронна пошта, календар і строки

Особи, установи та робочі записи

Робочі правила, формати та пам’ять

Пропозиції (за шлюзом перевірки — ніколи не записують безпосередньо)

Сховище чернеток — великий вміст ніколи не проходить через ШІ

Локальна робоча зона. Будь-який виклик інструмента може містити to_scratch: тоді повний результат записується до файлу чернетки, а ШІ отримує лише шлях і розмір — без попереднього перегляду; і кожен результат понад ліміт конектора (10 000 символів; 20 000 для Claude Desktop і ChatGPT Desktop) автоматично потрапляє туди ж у той самий спосіб — включно з відкривачами наборів інструментів. Великий вміст НЕ проходить через вивід ШІ в ЖОДНОМУ напрямку (швидше, дешевше, без помилок передруку). Шляхи до чернеток можна безпосередньо використовувати як source_path для deliver_file і update_ki_instruction. Сховище переживає перезапуски: власні нотатки ШІ, його реєстр стану та облік повноти читання зберігаються; дампи інструментів із попередніх днів очищаються під час кожного запуску, а файли без звернень — через 180 днів.

Сховище чернеток — це сейф. З вересня 2026 року кожен файл у ньому зашифровано AES-256 у стані спокою, з тим самим виведенням ключа, що й для бази даних справ і сховища документів — ніщо, що записує ШІ, не лежить відкритим текстом на диску. Читання та запис проходять лише через шлюз IRONSTICK; файл відкритого тексту, поміщений до сховища будь-яким іншим шляхом (файловим інструментом, ручним копіюванням), відхиляється, видаляється й повідомляється ШІ як порушення правил. Файли залишають сховище лише через діалог експорту IRONSTICK, ніколи до теки завантажень. Разом із зашифрованими базою даних, сховищем документів і конфігурацією це закриває останню прогалину: жодні дані справ не лежать незашифрованими на диску користувача — навіть робочі файли ШІ.

Жоден інструмент не скорочує власний результат. evidence_readfull, read_full_case, read_email_body, open_url (цілі закони та судові рішення), read_tagesprotokolle, read_person і read_chronik завжди видають свій вміст ПОВНІСТЮ. Одне центральне правило визначає, куди він надходить: нижче ліміту конектора — у відповідь, понад нього — цілком до файлу чернетки. ШІ ніколи не доводиться заздалегідь вгадувати, наскільки великим буде результат.

Вартовий свіжості: IRONSTICK стежить за кожним файлом чернетки. Щойно змінюються базові дані — новий документ чи запис хроніки у справі, з якої зроблено дамп, запис до календаря чи протоколу — або файл просто застаріває, його вміст замінюється повідомленням про анулювання, яке точно пояснює ШІ, як отримати його заново. ШІ ніколи не може працювати з мовчки застарілими дампами.

Веб, реєстри та валідація

Взаємна перевірка — передати роботу ІНШОМУ настільному ШІ (Claude ⇄ ChatGPT ⇄ Qwen ⇄ Kimi)

Передача та видача

7. Вартові ретельності — міст наглядає за робочою етикою ШІ

Чотири детерміновані вартові ретельності стежать за тим, наскільки ретельно насправді працює підключений ШІ. Це чиста логіка обліку та обробки рядків — жодного ШІ ніде — тож вони не можуть галюцинувати, майже нічого не коштують, і їх неможливо ні в чому переконати:

• Вартовий повноти читання. Коли ШІ отримує дамп усієї справи, файли підготовки справи або повний текст понад ліміт конектора, міст фіксує рядок за рядком, які діапазони він справді прочитав, — і зберігає цей облік між перезапусками. Доки залишаються прогалини, кожна відповідь інструмента — пошуки, grep, усе — містить точні непрочитані діапазони рядків із відсотком. Заявлене «я прочитав усе» просто неможливе; лише повне прочитання дає одноразове підтвердження «COMPLETE — усі рядки прочитано», математично доказовий кінець обов’язку читання, — і вносить прочитання до журналу підготовки.
• Без попереднього перегляду. Будь-який результат понад ліміт конектора (10 000 символів; 20 000 для Claude Desktop і ChatGPT Desktop) записується до сховища чернеток цілком; ШІ отримує лише примітку з назвою файлу, його розміром і двома командами продовження. Ніщо не показується двічі, і ШІ читає великий вміст там, де він зберігається. Це стосується кожного інструмента — включно з відкривачами наборів інструментів; безпосередньо відповідають лише засіб читання інструкцій і самі інструменти чернеток. І жоден інструмент не скорочує власний результат: нижче ліміту він надходить повністю у відповідь, понад ліміт — повністю до сховища чернеток.
• Вартовий повторної видачі. Якщо ШІ продовжує виправляти робочий файл після того, як його вже було видано Вам, на кожне подальше редагування надходить нагадування, що Ви зараз тримаєте застарілу версію і що виправлений файл має бути виданий знову — більше жодного мовчазного «виправив у теці проєктів».
• Вартовий невиданих проєктів. Коли ШІ записує свій щоденний протокол — сигнал «я завершую» — міст поіменно перелічує кожен версіонований проєкт, записаний під час сеансу, який так і не було видано. Завершена робота не може тихо залишитися в робочому сховищі ШІ.
• Вартовий формату електронних листів. Кожен доступ до вмісту електронних листів автоматично містить обов’язкове посилання на інструмент формату листів (поле копіювання теми, поле копіювання тексту, обов’язковий вміст, мовні правила) — ШІ нагадують про єдиний правильний шлях видачі до того, як він зможе імпровізувати власний.
• Вартовий поля копіювання. Щоразу, коли ШІ записує чи редагує текстовий робочий файл, відповідь містить нагадування, що документи потрапляють до користувача лише через інструмент видачі — вставлення готового листа в чат як тексту чи поля копіювання обходить форматування, перевірку та відстеження видачі і є видимим порушенням правил. Єдиним легітимним артефактом у полі копіювання залишається електронний лист, точно за інструментом формату листів.
• Якір справи. Кожна відповідь інструмента, що стосується справи, містить зареєстрований номер справи, клієнта та предмет (шлюз 10) — контекст, вигаданий з пам’яті про іншу справу, спростовує сам себе в тому самому вікні.
• Керування рівнем моделі. Інструкції повідомляють ШІ, який клас моделі потрібен для завдання: перед інструментами процесуальних документів (формат виводу, перевірка, видача) він одним реченням просить Вас перемкнути настільний клієнт на модель найвищого рівня, а після видачі повідомляє, що знову достатньо дешевшої моделі. Коли лічильники пропозицій показують підтримку мережі сторін (дві пропозиції основних даних і одна пропозиція зв’язку чи прив’язки до справи), міст додає — один раз за сеанс — підказку, що для цієї повністю захищеної шлюзами роботи не потрібна модель найвищого рівня. Вирішуєте Ви; ШІ продовжує працювати.

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

8. Компілятор процесуальних документів — видача лише за доказом

Процесуальні документи та листи пишуться в діалозі з настільним ШІ на живій справі — той самий робочий рівень і ті самі шлюзи, що й у власному чаті IRONSTICK. Те, що залишає систему, — це шаблон, готовий до подання, ніколи не готове судове подання: Ви перевіряєте, виправляєте та підписуєте. Перед кожною передачею стоять два шлюзи: детермінована перевірка, описана нижче, і — якщо Ви увімкнете її для активної моделі API в конфігурації — Red/Blue Team: друга модель читає проєкт як адвокат протилежної сторони; суттєві знахідки відправляють його на доопрацювання, щонайбільше два раунди, кожен пункт аналізується по суті й ніколи не приймається сліпо. Якщо ШІ вважає знахідки безпідставними, він повторно подає незмінений файл із письмовою відповіддю на кожну знахідку — рецензент не запускається вдруге на незміненому файлі, а звіт рецензента надходить до Вас разом із цими відповідями. Сама передача відбувається через діалог експорту IRONSTICK, звідки проєкт потрапляє до текстового процесора одним кліком.

Офіційний процесуальний документ не може залишити систему на довірі. verify_pleading, детермінований сканер (жодного ШІ ніде), перевіряє готовий проєкт щодо Ваших живих записів і перевіреної правової бібліотеки за вісьмома класами тверджень:

• Посилання на докази — штампи IS і #-номери, у списку додатків І в основному тексті: існування, належність, цілісність штампа та походження цитат, прив’язане до документа: кожен процитований чи доданий елемент має вважатися прочитаним для ЦЬОГО документа — отриманим повністю або його файл чернетки прочитаним на 100 %; прочитання зараховується на 2 години, кожна видача того самого документа продовжує його, перевірка іншого документа скидає прочитання додатків. Цитування з фрагментів пошуку чи з пам’яті не проходить перевірку. Рядок додатка може вказувати діапазон сторінок («с. 12–15»); обов’язок читання стосується всього документа.
• Цитати законів — процитована стаття має існувати в тексті перевіреної бібліотеки (з толерантністю до крапки-роздільника тисяч, з точністю до меж слів) І мати походження прочитання: ШІ має справді отримати цю статтю з бібліотеки під час цього запуску застосунку — пресові статті, вебрезюме та пам’ять моделі ніколи не обґрунтовують норму й не проходять перевірку. Процитовані підпосилання (частина/пункт) також перевіряються на існування. Джерело, відсутнє в бібліотеці, не прослизає: ШІ має запросити його, і запит потрапляє до Вашого діалогу згоди — позначені джерела завантажуються, перевіряються та зберігаються; непозначені відхиляються, і кожна подальша цитата з них містить видиму примітку «користувач відхилив».
• Дослівні цитати — кожен процитований уривок має бути знайдений повністю в повних текстах справи або в правовій бібліотеці (з толерантністю до помилок OCR). Цитата, не знайдена в жодному джерелі, отримує статус CONTRADICTED і блокує видачу. Прибрати лапки чи трохи переформулювати уривок не допоможе: заблокована цитата запам’ятовується для документа й залишається заблокованою. Повністю викреслена цитата дозволена — і видача прямо повідомляє Вам, які цитати було видалено, бо жодне джерело їх не містить.
• Номери dosar щодо Ваших справ і записів.
• Суми з НУЛЬОВОЮ толерантністю — число має точно збігатися із записаною формою; «14.500» там, де в реєстрі «14.500,00», блокує видачу до виправлення.
• Основні дані сторін — кожне використане ім’я має збігатися із зареєстрованим написанням літера в літеру, включно з діакритикою.
• CNP та IBAN — перевірка контрольних сум (недійсна контрольна цифра — це завжди галюцинація) плюс збіг із реєстром/записами.
• Названі сторони — кожна особа чи компанія, названа в документі, має бути прочитана (профіль) І мати перевірені зв’язки (who_is_connected_with); відмова називає обидва виклики і додатково рекомендує тест на кліки (read_cliques).

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

Додаток — Повний технічний опис мосту

Стан: 175 інструменти-члени · 20 наборів інструментів · ревізія протоколу MCP 2024-11-05. Цей документ вичерпно описує міст — архітектуру, кожен функціональний рівень, кожен шлюз, кожну межу та кожне перенаправлення — виключно прозою.

1. Призначення та позиціонування

Міст з’єднує комерційні настільні застосунки ШІ (Claude Desktop, ChatGPT Desktop, Qwen Desktop, Kimi Desktop) із запущеним застосунком для ведення юридичних справ IRONSTICK на тому самому комп’ютері. Настільний ШІ отримує контрольовану, самоописову поверхню інструментів через Model Context Protocol (MCP); кожен виклик виконується всередині застосунку IRONSTICK щодо живої бази даних, і кожен результат проходить постобробку мостом, перш ніж потрапити до моделі. Цілі проєктування: мінімальне постійне навантаження контексту моделі, структурне забезпечення робочих правил, яке простий текст інструкцій гарантувати не може, захист незбереженої роботи користувача, захист даних від завеликих або хибно спрямованих запитів і повна відсутність читабельних конфігураційних матеріалів у встановленому продукті.

2. Топологія процесів

Міст складається з двох взаємодіючих процесів.

Застосунок IRONSTICK розміщує HTTP-сервер, прив’язаний виключно до петлевого інтерфейсу. Його порт і 48-символьний шістнадцятковий токен доступу визначено в сховищі конфігурації застосунку; кожен запит має пред’являти токен. Цей сервер володіє реєстром інструментів, виконує всі виклики інструментів, застосовує всі шлюзи та постобробники і є єдиним джерелом істини щодо того, що підключена модель може бачити й робити.

Перед кожним настільним ШІ стоїть невеликий нативний виконуваний файл, заздалегідь скомпільований (ahead-of-time) із Dart. Він спілкується з настільним ШІ через JSON-RPC по stdio (стандартний транспорт MCP) і передає роботу HTTP-серверу застосунку. Кожен настільний ШІ має власний каталог встановлення з копією цього виконуваного файлу та приватним файлом конфігурації, що містить: петлевий порт, токен доступу, рядок ідентичності абонента (наприклад, claudedesktop, chatgptdesktop, qwendesktop), шлях до файлу інструкцій, що видається на старті сеансу, і шлях до скрипта видачі. Ідентичність абонента передається з кожним викликом інструмента як внутрішній аргумент і визначає всю поведінку для окремих ШІ, описану далі. Фронтенд також надсилає застосунку сигнал серцебиття приблизно кожні три секунди, поки настільний ШІ підключено; застосунок показує це як індикатор присутності «міст підключено» з часом життя п’ятнадцять секунд, тож користувач завжди бачить, чи підключено зараз зовнішній ШІ.

Під час рукостискання MCP initialize фронтенд повертає ідентичність свого сервера і, вбудований у результат initialize, повний текст інструкцій для старту сеансу. Фронтенди версії 2.6.6 і пізніших шукають супровідний файл до налаштованого шляху інструкцій, назва якого має суфікс core, і надають йому перевагу; так видається стиснена базова інструкція обсягом приблизно п’ятнадцять із половиною тисяч символів замість повного посібника приблизно на п’ятдесят шість тисяч, що скорочує постійне навантаження інструкціями приблизно до чверті. Повний посібник залишається доступним моделі будь-коли через спеціальний інструмент (див. розділ 5).

3. Безпека, ліцензування та згода

Увесь трафік іде лише через петлевий інтерфейс і автентифікується токеном. Інструменти вебдоступу застосовують серверну фільтрацію запитів: дозволено лише публічні цілі http і https; localhost, петлеві діапазони, приватні мережі та адреси link-local відхиляються, тож модель ніколи не можна спрямувати через міст на сканування комп’ютера чи локальної мережі.

Міст і інтеграції настільних застосунків окремих постачальників — це окремо ліцензовані додаткові модулі. Їхня доступність закодована як біти в підписаному ліцензійному ключі; фронтенд і поверхня інструментів неліцензованого модуля просто не виникають.

Для з’єднання Claude Desktop шлюз згоди захищає перший доступ до даних за кожен запуск застосунку: перший виклик інструмента після старту програми відкриває модальне вікно попередження над поточним екраном. Якщо користувач погоджується, доступ вільний до кінця запуску; якщо користувач відмовляє, доступ блокується на десять хвилин, і кожен заблокований виклик повертає настільному ШІ пояснювальне повідомлення з проханням повторити спробу пізніше; після десяти хвилин наступний доступ знову відкриває попередження. Стан зберігається лише в пам’яті й ніколи не записується на диск.

Незалежно від згоди кожне настільне з’єднання охороняє блокування доступу до інструкцій: жоден інструмент — відкривачі наборів інструментів, інструмент виконання членів, усе — не виконується, доки абонент не прочитає інструкції та дослівно не поверне заборону галюцинацій (правило 5) через інструмент підтвердження; відкритими залишаються лише засіб читання інструкцій, інструмент підтвердження та інструмент системної мови. Підтвердження прив’язане до кожного настільного ШІ і спливає через шістдесят хвилин після надання, після двох годин без виклику, опівночі та при кожному новому рукостисканні з’єднання — після спливу абонент має знову прочитати інструкції та повернути випадково обране правило замість того, яке він знає напам’ять. У з’єднанні з Claude кожен чат є окремим абонентом (їх розрізняють за структурованими подіями інструментів локального журналу сеансів Claude, ніколи за текстом розмови), чат, контекст якого було стиснено, негайно блокується, без штрафу, доки не прочитає інструкції знову, а для чату, який звертається до теки даних власними файловими інструментами замість конектора, це фіксується як порушення правил; відмова називає два виклики, що знімають блокування, а випадне меню біля символу ШІ в застосунку показує стан як зелену галочку або червоний хрестик.

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

4. Система інструкцій

Настанови для моделі надходять трьома рівнями зі строго зростаючою конкретністю та строго спадною постійністю перебування в контексті.

Базова інструкція видається один раз, усередині результату initialize. Вона містить мандат (фактично обґрунтована юридична робота на рівні старшого юриста), універсальні правила (мова діалогу дорівнює системній мові IRONSTICK; юрисдикція згенерованих документів береться зі справи, ніколи з діалогу; дисципліна дат; жодного цитування з фрагментів пошуку — кожну сторінку, на яку спирається ШІ, треба відкрити й прочитати через open_url, незалежно від того, який пошук її знайшов; дисципліна цитат і посилань; ліміт у три спроби на кожен невдалий виклик інструмента; дисципліна видачі), а також опис самого механізму наборів інструментів, включно з поясненням поля домашнього набору інструментів, описаного в розділі 6.

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

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

Три з цих правил додатково забезпечуються структурно, а не текстово, шлюзами, описаними в розділах 3 і 7: блокування доступу, дисципліна дат і дисципліна джерел законів. Саме читання інструкцій є останнім правилом універсального блоку: спосіб розблокувати конектор називається лише після всіх попередніх правил, тож модель, яка до нього дійшла, їх прочитала.

5. Поверхня інструментів і рівень наборів інструментів

Плаский список із 175 інструментів помітно погіршує вибір інструментів у сучасних настільних моделях. Тому міст надає скорочену поверхню з двадцяти восьми записів: шість базових інструментів (поточні дата й час; поточний контекст GUI; системна мова; юрисдикція справи; повторне читання інструкцій; підтвердження інструкцій), інструмент видачі, що додається фронтендом, двадцять відкривачів наборів інструментів, інструмент виконання членів і інструмент повного переліку. Усе інше існує лише як члени всередині наборів інструментів.

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

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

Набори інструментів не є модальними; усі відкривачі залишаються доступними для виклику будь-коли, інструмент може свідомо бути членом кількох наборів, а вміст відкриття ніколи не перенаправляється до сховища чернеток (схеми у файлі були б марними). Функціональні шлюзи прибирають цілі групи: якщо користувач не ввімкнув навігацію GUI, відкривач набору інструментів навігації та всі його члени відсутні в кожному списку й кожній відповіді. Інструмент повного переліку перелічує кожного члена з однорядковим призначенням і набором, якому він належить, і існує лише як запасний вихід; основним маршрутизатором є описи наборів інструментів. Загалом двадцять наборів інструментів містять 280 записів членів для 175 різних інструментів.

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

6. Формат визначення інструментів і ланцюг його виробництва

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

Увесь текст, призначений для моделі, без винятку англійською мовою. Ланцюг виробництва йде від одного канонічного вихідного документа через генератори до вкомпільованого оверлею та до структурного плану кластерів, що документує топологію наборів інструментів; генератор жорстко переривається, щойно будь-який опис чи текст виводу — на будь-якій глибині схеми — спрацьовує на детекторі німецької мови, а вартовий дрейфу перериває синхронізацію, коли заява про домашній набір інструментів указує на набір, який насправді не містить цей інструмент як члена. Задекларовані числові межі в схемах інструментів забезпечуються спільною допоміжною функцією обмеження у виконавчих функціях, тож заявлений максимум є справжнім максимумом.

7. Універсальні механізми часу виконання

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

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

Захист від переповнення: будь-який результат, що перевищує ліміт конектора — десять тисяч символів, одна центральна константа, подвоєна до двадцяти тисяч для Claude Desktop і ChatGPT Desktop, — автоматично записується до згенерованого файлу чернетки. Модель отримує лише примітку із загальним розміром і кількістю рядків, назвою файлу, явним запевненням, що нічого не втрачено, двома командами продовження (читання діапазону; пошук за шаблоном у файлі) і прямою забороною повторно запитувати виклик — без попереднього перегляду, тож великий вміст читається там, де він зберігається, і модель звикає працювати зі сховищем чернеток. Єдиний виняток — засіб читання інструкцій, пакет якого завжди надходить повністю; відкривачі наборів інструментів перенаправляються, як і будь-який інший результат. Жоден інструмент не скорочує власний результат — ліміт конектора є єдиним місцем, де вирішується питання розміру. Результати понад десять мегабайтів не перенаправляються, а отримують відповідь з інструкцією звузити запит, що називає застосовні фільтри, оскільки навіть сховище чернеток там обмежує розмір файлу. Звільнені від перенаправлення самі інструменти читання чернеток (внутрішньо обмежені; їх перенаправлення призвело б до рекурсії) і виклики, які вже запросили перенаправлення до чернеток.

Шлюз дати: кожен інструмент, що записує в IRONSTICK, для зовнішніх абонентів відхиляється, якщо цей абонент не отримав поточні дату й час протягом останніх тридцяти хвилин. Відмова називає засіб виправлення — отримати час, потім повторити ідентичний виклик. Вікно прив’язане до кожного постачальника і свідомо коротке, щоб свіжа розмова не могла успадкувати давнє отримання і щоб переходи через північ відловлювалися. Внутрішні абоненти застосунку не зачіпаються. Це існує тому, що інакше зовнішні моделі ставлять на записи «сьогодні» часів свого навчання.

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

Жорстке блокування навігації: вісім екранів оголошено захищеними — чотири форми захоплення (захоплення документа, захоплення документа з прив’язкою до справи, захоплення хроніки справи, захоплення клієнта), форма створення справи, форма прив’язки установи/особи та текстовий редактор. Поки головне вікно користувача показує будь-який із них, кожна функція навігації GUI та експорту відхиляється на рівні обробника — обгортка однаково перехоплює прямі виклики та виконання членів — із повідомленням, що називає захищений екран, забороняє навігацію й інструктує модель відповісти з тими даними, які вона має, і запропонувати відкриття лише після того, як користувач завершить і збереже роботу. Тому модель ніколи не може знищити незбережену роботу користувача перемиканням екранів. Інструмент відкриття вебсторінок явно звільнено від цієї обгортки, оскільки він має той самий префікс назви, але не здійснює навігацію застосунком.

Пропозиція навігації: результати приблизно сорока інструментів, вивід яких описує об’єкт, що його можна відкрити в GUI, — справу, особу, установу, клієнта, конкретний доказ, електронний лист, записи календаря чи строки — отримують один доданий рядок, що пропонує моделі запропонувати користувачеві відкрити об’єкт безпосередньо в IRONSTICK, із зазначенням точного виклику навігації. Там, де аргументи виклику містять ідентифікатор об’єкта, пропозиція конкретна; для результатів пошуку та переліку вона посилається на ідентифікатор знахідки. Рядок явно вимагає згоди користувача перед навігацією, якщо запит користувача вже не був командою показати/відкрити. Пропозиція додається лише після обробки переповнення і лише тоді, коли результат не є помилкою, навігацію ввімкнено і жорстке блокування навігації не активне — блокування завжди має перевагу над пропозицією.

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

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

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

Конвенції результатів: збої повертаються як текст, що починається з префікса помилки, і позначаються як помилки в результаті MCP; моделі наказано виправити й повторити щонайбільше три рази, потім зупинитися й повідомити. Структуровані самоописові маркери, вбудовані в результати (для операцій пам’яті, шлюзів тощо), стабільні й задокументовані у відповідних полях виводу.

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

Вартовий повторної видачі: після успішної видачі файлу, джерело якого лежить у сховищі чернеток, файл-маркер поруч зі сховищем фіксує видану назву й час (видачі, передані як вбудований вміст, так само фіксуються під своєю назвою видачі). На кожне пізніше редагування, запис чи нормалізацію зафіксованого там файлу надходить нагадування, що користувач тримає застарілу видану версію і що виправлений файл має бути виданий знову під новим номером версії. Сама відповідь видачі додатково отримує поточний стан повноти читання із застосунку через внутрішню кінцеву точку, яка не є інструментом, і дорікає за видачу, здійснену попри непрочитані діапазони.

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

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

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

8. Шлюзи взаємодії

Три інструменти свідомо відповідають на перший виклик запитанням замість результату; в усіх них буквальна відповідь «unknown» завжди дійсна й ніколи не карається.

Шлюз видачі: інструмент видачі файлів, викликаний без декларації офіційності, нічого не видає й запитує, чи є видача одним із чотирьох видів офіційних артефактів — процесуальний документ, електронний лист до суду, запис хроніки, щоденний протокол — чи жодним із них. Відповідь «no» дає негайну видачу — але заява перевіряється за вмістом: детермінований детектор перевіряє файл, і вміст, оформлений як лист чи процесуальний документ (формули звертання й завершення шістьма мовами, блок адресата, юридичні маркери, блок ідентифікації), відхиляє заяву про неофіційність і фіксує спробу в журналі; такий вміст не має неофіційного шляху. Відповідь з офіційним видом повертає, все ще без видачі, обов’язкову інструкцію з форматування саме для цього виду, вбудовану у відповідь шлюзу; лише повторний виклик із прапорцем підтвердження, що файл перевірено за цією інструкцією, справді здійснює видачу. Вартовий серії версій додатково відхиляє першу видачу під новою основою назви файлу, поки в теці видачі вже існує версіонована серія з тим самим номером справи — перейменування документа для скидання його лічильника версій структурно неможливе; справді інший документ вимагає свідомої декларації, що фіксується в журналі. Цей шлюз реалізовано всередині самого виконуваного файлу фронтенду, який отримує актуальну інструкцію з форматування із застосунку наживо. Документи й листи ніколи не надходять до користувача як текст чату чи поля копіювання — кожен доступ на запис до текстового робочого файлу містить це нагадування, а єдиним легітимним артефактом у полі копіювання залишається електронний лист за його інструментом формату.

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

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

Шлюз перевірки: для офіційних процесуальних документів інструмент видачі додатково вимагає свіжої атестації від детермінованого засобу перевірки процесуальних документів. Цей засіб сканує готовий файл чернетки за вісьмома класами тверджень — посилання на докази в списку додатків і в основному тексті (штампи й номери, включно з походженням цитат, прив’язаним до документа: кожен процитований чи доданий елемент має вважатися прочитаним для цього документа — отриманим повністю або його файл чернетки прочитаним до кінця; прочитання зараховується на дві години, кожна видача того самого документа продовжує строк для його цитованих елементів на дві години, а перевірка чи видача документа з іншою основою назви скидає прочитання додатків; рядок додатка може вказувати діапазон сторінок, обов’язок читання стосується всього документа), цитати законів щодо перевіреної бібліотеки (стаття, відсутня в перевіреному тексті закону, є спростованою знахідкою; цитата додатково вимагає походження прочитання — кожне читання з бібліотеки фіксується для кожного запуску застосунку з номерами статей, що справді повернулися, і процитована стаття без такого запису про читання є спростованою знахідкою, тож пресові статті, вебрезюме й пам’ять моделі ніколи не можуть обґрунтувати норму; процитовані підпосилання, як-от частина й пункт, перевіряються на існування в текстовій ділянці статті; джерело, відсутнє в бібліотеці, блокує видачу, доки його не буде інтегровано чи відхилено), дослівні цитати — кожна має бути знайдена повністю в повних текстах справи або в правовій бібліотеці; цитата, не знайдена в жодному джерелі, є спростованою й блокує видачу, цитата, з якої лише прибрали лапки чи формулювання якої трохи змінили, залишається заблокованою, а про повністю викреслені цитати користувачеві повідомляється під час видачі —, номери dosar, суми за правилом нульової толерантності (точна записана форма), основні дані сторін літера в літеру, включно з діакритикою, персональні/банківські ідентифікатори через валідатори контрольних сум, і названі сторони — кожна особа чи компанія з реєстру суб’єктів, названа в документі, має бути прочитана (профіль) і перевірена на зв’язки для цього документа, причому відмова називає обидва виклики й рекомендує тест на кліки. Знахідки оцінюються як підтверджені, непідтверджені або спростовані; будь-яка спростована знахідка чи невирішений відсутній закон дає блокувальний вердикт. Атестація прив’язується до точного стану файлу — будь-яке редагування анулює її — а після п’яти невдалих прогонів перевірки цикл жорстко переривається, наказує моделі зупинитися й повідомити та сповіщає користувача безпосередньо в застосунку.

Шлюз згоди для джерел законів: джерело закону, повідомлене моделлю, більше не інтегрується мовчки. Запити збираються в одному діалозі згоди в застосунку — джерело, юрисдикція, ШІ, що запитує, — де позначені записи завантажуються, перевіряються й зберігаються (з негайним запуском робочого процесу), а непозначені відхиляються; відхилене джерело перетворює подальші цитати з нього на видимі примітки «не перевірено за рішенням користувача» замість мовчазних блокувань. Після цього монітор даних містить закони лише для періодичного циклу перегляду.

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

9. Старт сеансу та рамки

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

Інструмент дати й часу відповідає одним рядком (дата, час, часовий пояс, день тижня, синхронізовано через NTP, де можливо, інакше системний годинник) і містить постійний припис, що кожен хід діалогу починається з поточної дати і що дати ніколи не вгадуються. Інструмент контексту GUI повідомляє, який екран головного вікна застосунку відкрито, з навігаційним ланцюжком і відкритими клієнтом і справою. Інструмент системної мови повертає ідентифікатор мови, що визначає діалог і списки між справами; інструмент юрисдикції повертає для кожної справи юрисдикцію, що визначає згенеровані документи й термінологію, є обов’язковим перед будь-якою роботою з документами й інструктує запитати користувача, якщо її не задано. Інструмент ранкового брифінгу повертає сьогоднішній структурований брифінг з ідентифікаторами й маркерами, щоб модель могла діяти щодо кожного пункту; інструмент робочого брифінгу відстежує для кожного настільного ШІ, чи було цей ШІ вже поінформовано сьогодні, і повертає останні щоденні протоколи лише під час першого контакту за день.

10. Сховище чернеток

Сховище чернеток — це робоча тека моделі для всього великого. Воно пропонує запис із можливістю дописування для поступового складання частинами; читання діапазонів із нумерацією рядків, номери яких безпосередньо відповідають порядковим редакторам; точну заміну тексту з вимогою унікальності, повторну спробу з толерантністю до пробілів і типографських лапок, яка все одно вимагає унікальності, і передбачений інструкціями резервний шлях «знайти й скопіювати» за будь-якої іншої невідповідності; вставлення за номером рядка або після маркера; видалення діапазону рядків; атомарну заміну діапазону рядків як безпечну операцію реструктуризації; пошук за шаблоном без урахування регістру та діакритики в одному чи всіх файлах з обмеженням у п’ятдесят знахідок і необов’язковими рядками контексту; структуру markdown, що зіставляє заголовки з діапазонами рядків без читання файлу; перелік каталогу; копіювання; порядкове порівняння двох файлів, що приховує спільні рядки; нормалізацію, орієнтовану на видачу, яка сплощує структурний markdown до конвенцій процесуальних документів, захищає посилання, доповнює короткі посилання на докази до семи цифр і нормалізує закінчення рядків; вирівнювання пробілів; очищення закінчень рядків і невидимих символів; деструктивні вирівняні проєкції (скелет для порівняння в нижньому регістрі або лише згортання діакритики) завжди до окремого цільового файлу; лічильники слів, літер і рядків; і видалення.

Легкий реєстр стану запам’ятовує нотатки ключ-значення для поточного сеансу — насамперед, який файл є поточним основним проєктом — із семантикою отримання, встановлення та очищення, і переживає перезапуски застосунку.

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

11. Система пам’яті

Постійна пам’ять ШІ — це спільний для всіх чатів записник, який поділяють усі підключені ШІ та асистент у застосунку. Запис містить щонайбільше одну тисячу символів — описи набору інструментів та інструментів вимагають стиснення до абсолютної суті й розбиття більшого матеріалу — і прив’язаний щонайменше до клієнта або справи (при прив’язці до справи клієнт виводиться й виправляється автоматично) та за бажанням до доказу, електронного листа, суб’єкта чи установи, усе з перевіркою. Записи мають бути написані системною мовою IRONSTICK незалежно від мови діалогу, і моделі заборонено використовувати власні приватні файли пам’яті для знань про справи, оскільки вони не доходять ні до ШІ-колеги, ні до користувача. Необов’язкова дата виконання робить запис схожим на строк: записи, строк яких настав або прострочений, першими з’являються в протоколі старту сеансу та в поданнях строків застосунку.

Пошук фільтрується за будь-яким із прив’язаних ідентифікаторів і за датою виконання (усе, рівно сьогодні або вікно в десять днів навколо заданої дати), повертає найновіші першими — за замовчуванням двадцять і щонайбільше п’ятдесят знахідок — і позначає записи записника, створені користувачем, як суворо лише для читання для ШІ. Оновлення замінює текст та/або переносить, встановлює чи очищає дату виконання; усе, що не передано, залишається без змін. Оновлення, текст якого перевищує ліміт, відхиляється із заявою про місткість, що називає подану довжину, ліміт, поточну заповненість запису та вільний залишок; кожне успішне оновлення тексту так само повідомляє заповненість і залишок; в обох випадках, щойно вільними залишається менше трьохсот символів, відповідь додає постійну рекомендацію або переробити весь запис, або створити додатковий запис і залишити перехресне посилання в старому. Видалення незворотне й відмовляє щодо записів записника користувача та записів завдань. Прибирання побудоване для тривалих проваджень: записи, прив’язані до справи, звільнені від річного очищення, доки ця справа активна, — вони зникають лише тоді, коли справу переведено в неактивний стан чи архівовано (що негайно очищає її записи) або коли клієнта видалено; річне очищення застосовується лише до записів без справи. Крім того, кожен запис, повернений пошуком у пам’яті, і кожне оновлення запису поновлюють його строк життя, а очищення вимірює вік від найпізнішої з дат створення та останнього звернення — запис, який справді використовується, ніколи не спливає; застаріває лише мертвий матеріал. Записи записника користувача ніколи не спливають автоматично.

Основні дані, особи, зв’язки та документи не належать до пам’яті: описи спрямовують їх до інструментів пропозицій і до захоплення документів.

12. Строки, зустрічі та календар

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

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

13. Щоденний журнал

Система журналу записує та читає щоденний протокол для всіх справ. Дописування адресоване дню (за замовчуванням сьогодні, з датою, отриманою через інструмент часу), завжди дописує до наявного дня з роздільником і ніколи не перезаписує, прив’язує зачеплені справи через список справ і очікує вміст як чистий markdown у стилі протоколу, визначеному в додатку до інструкцій. Інструмент нотаток додає один рядок події до сьогоднішнього протоколу з необов’язковим посиланням на справу. Інструмент формату повертає обов’язковий формат файлу протоколу. Читання працює за датою, діапазоном або з найновіших, з опцією повного тексту та обмеженням справою; пошук — це пошук за ключовим словом без урахування діакритики в назвах і повних текстах з датою, назвою та уривком контексту для кожної знахідки. Обидві форми переліку за замовчуванням повертають десять записів і щонайбільше тридцять. Відкриття набору інструментів уже видає сьогоднішній протокол повністю з приміткою, скільки ще протоколів існує за останні два тижні.

14. Доступ до справ

Розпізнавання справи працює за номером справи, за іменем залученої сторони (з толерантністю до діакритики, охоплюючи опонента, позивача, назву та клієнта — обов’язково щоразу, коли користувач називає сторону без номера, оскільки багато справ узагалі не мають номера) і через список справ клієнта. Пов’язані провадження беруться з ієрархії справ як батьківські, дочірні записи та записи тієї самої групи.

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

Підготовка справи — це інструмент і шлюз. Інструмент підготовки видає одним викликом заголовок (профіль і юрисдикцію) та дайджест кожного документа — ідентифікатор, дату, тип, назву, резюме часу захоплення, перехресні посилання та розмір повного тексту, — який і є хронікою; другий перелік тих самих рядків було вилучено як чисте марнування токенів. Відповідь завжди починається з примітки, де знаходяться заголовок і дайджест (безпосередньо у відповіді, коли вся відповідь залишається нижче ліміту конектора, інакше як два файли чернеток, які треба прочитати до кінця), і п’яти найновіших документів, які треба прочитати повністю. Шлюз підготовки потім відхиляє для зовнішніх абонентів два рівні виводу щодо справи: нотатку чи запис щодо справи (журнал, щоденна нотатка, запис хроніки, нотатка справи), доки профіль, юрисдикцію, дайджест і п’ять найновіших записів хроніки (нотатки без PDF чи транскрипту; зображення дозволено) не прочитано повністю, — тож поточна серія записів хроніки враховує останні з них, не змушуючи читати важкі документи заради простої нотатки; судження щодо справи (перевірка процесуального документа, передача, експорт) — додатково доки кожен процитований чи доданий документ не прочитано повністю. Прочитання облікуються для кожного настільного ШІ в журналі, що зберігається, і дійсні три дні або до наступного вхідного документа справи; вихідні документи та записи доказів ніколи не анулюють прочитання. Той самий журнал живить випадне меню біля символу ШІ. Третій, нижчий рівень охороняє сам вміст справи: кожен інструмент вмісту справи — хроніка, хронологія, пошуки за ключовим словом, уривками й періодом, повні тексти, суперечності, твердження, зобов’язання, строки, календар, кореспонденція, використання, подані докази, ланцюги листів, списки додатків, штампи, медіа, установи, теги, оцінка та нотатки-інструкції — відхиляється для справи, дайджест якої абонент не прочитав, причому відмова називає інструмент підготовки; третя відхилена спроба щодо тієї самої справи облікується як порушення правил. Лічильники підготовки скидаються з кожним читанням інструкцій і стартом сеансу.

Повне читання справи захищене шлюзом, як описано в розділі 8. Дамп до чернеток є найшвидшим повним шляхом: він збирає весь текст справи всередині застосунку, без урізання, нормалізує аномалії OCR (повторювані пробіли, змішані закінчення рядків, нерозривні пробіли, м’які переноси, символи нульової ширини), записує його безпосередньо до сховища чернеток і повертає лише дескриптор зі статистикою; дуже великі справи розбиваються на пронумеровані файли частин. Фільтри обсягу обмежують дамп вхідним, вихідним або обома напрямками, а список ідентифікаторів доказів створює дамп саме цих записів — призначений спосіб повністю прочитати один дуже великий документ, зі справою, виведеною з доказу.

Засіб читання доказів є обов’язковою основою для кожного змістовного твердження: він завантажує запис із витягнутим повним текстом документа (повністю й без урізання; понад ліміт конектора він надходить цілком до сховища чернеток) і, за наявності, повним текстом чату чи транскрипту (що охоплює чати месенджерів і транскрипти телефонних розмов, слухань, допитів і судових засідань), а також кваліфіковане резюме, опис і метадані, які оголошено такими, що не замінюють повний текст. Якщо жоден розділ повного тексту не з’являється, витягнутого тексту не існує, і модель не має права робити змістовних тверджень щодо запису. Список до дванадцяти ідентифікаторів через кому читає кілька записів одним викликом. Інструмент переліку медіа повідомляє про існування, тип, дату й розмір вкладень із зображеннями, аудіо та відео запису чи справи, явно зазначаючи, що вміст медіа не можна прочитати як текст і що інструмент існує для того, щоб запис лише з медіа не класифікувався хибно як порожній.

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

15. Пошук усередині справи

Центральний пошук доказів оцінює всі поля доказів, витягнуті повні тексти документів і вміст транскриптів, поєднуючи багатослівні запити кон’юнктивно, незалежно від діакритики та з підсиленням фраз; результати впорядковано за релевантністю без показу числових оцінок, кожна знахідка позначає, яке поле її спричинило, за замовчуванням повертається п’ятнадцять, а щонайбільше тридцять знахідок, а форма відповіді відповідає вибору в шлюзі з розділу 8. Пошук уривків розбиває документи й транскрипти на вікна абзаців і речень і повертає найкраще збіжні уривки з їхнім посиланням — знаходячи, де саме в тексті щось стоїть, а не лише в якому записі, — зі зіставленням, толерантним до помилок OCR, що долає помилки захоплення, бонусом за фразу й обмеженням рівно однією справою або всіма справами рівно одного клієнта (призначений інструмент для запитань «чи X коли-небудь, будь-де»; ніколи між клієнтами), за замовчуванням вісім і щонайбільше двадцять уривків. Інструмент діапазону дат перелічує докази між двома датами. Спеціальний пошук кореспонденції від сторони обов’язковий, коли користувач запитує документи від певної сторони чи до неї: він зіставляє сторону з толерантністю до діакритики із записами про участь, фільтрує за напрямком (до мене, від мене або обидва), виключає чати й транскрипти, за замовчуванням приховує власноруч зроблені знімки екрана, повідомляючи їх кількість, і впорядковує від найновіших — явно відмінний від пошуку за ключовим словом, який повернув би також записи, що лише згадують сторону.

16. Детерміновані інструменти аналізу

Ці інструменти обчислюють із записів без будь-якої участі ШІ. Хронологія повертає всі елементи справи, упорядковані за датою події за спаданням, із посиланням, позначкою часу, типом запису та назвою, за замовчуванням триста і щонайбільше п’ятсот елементів. Збирач суперечностей свідомо не судить: він збирає до ста двадцяти елементів-кандидатів (за замовчуванням шістдесят), за бажанням відфільтрованих за одним суб’єктом, із посиланням, датою, учасниками та коротким вмістом, і залишає судження та подальше читання повних текстів моделі. Інструмент «хто що сказав» знаходить кожен елемент, у якому трапляється особа, — як учасник, у назві чи тексті або всередині формулювань транскрипту, — незалежно від діакритики, позначаючи джерело кожної знахідки, за замовчуванням сорок і щонайбільше сто. Інструмент мережі учасників підраховує, які особи та суб’єкти трапляються разом в одних і тих самих елементах, глобально або для справи, за бажанням зосереджуючись на одному суб’єкті. Інструмент зобов’язань перелічує відкриті елементи з позначкою строку за датою виконання з кількістю днів, описами, посиланнями та позначками прострочення/терміновості.

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

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

17. Зцілення OCR

Чотириетапний шлях ескалації ремонтує зіпсовані збережені повні тексти, і його явно заборонено використовувати як зручну заміну читанню. Запит повторного сканування просить застосунок заново виконати OCR збереженого оригінального PDF; користувач обирає сторінки в IRONSTICK, а моделі наказано одним реченням повідомити користувача й чекати. Інструмент статусу слід викликати один раз, коли користувач скаже, що сторінки обрано, — цикли опитування заборонено — і, коли все готово, він повертає робоче завдання разом із двома файлами чернеток, що містять свіжий скан і поточний текст бази даних. Правило порівняння та зцілення дозволяє лише механічні виправлення OCR, ніколи не перефразування, із точним збереженням цифр, імен і сум. Там, де місце нерозбірливе в ОБОХ джерелах, модель може перед поданням попросити користувача про візуальну перевірку — щонайбільше три місця на документ, із записом, відкритим у точному місці, і точно названим місцем («сторінка 7, другий абзац — сума?»); коли навігацію вимкнено, запис і сторінку натомість називають у чаті. Інструмент подання передає зцілений файл чернетки застосунку, який показує його користувачеві в модальному вікні; лише збереження користувачем замінює текст у базі даних, і нічого не зберігається автоматично. Остання ескалація, запит на передачу PDF, відкриває запис, і модель просить користувача особисто перетягнути оригінальний PDF у чат — міст свідомо не надає допомоги зі шляхами, жорстко відмовляє, якщо не було попереднього повторного сканування, і відхиляє PDF понад десять мегабайтів або понад дев’яносто сторінок; модель потім читає PDF візуально, будує зцілену версію у сховищі чернеток і подає її через той самий шлюз перевірки. При відмові через розмір чи кількість сторінок процес не закінчується: резервний варіант із транскрипцією все одно відкриває запис, і модель просить користувача відкрити PDF через скріпку й дослівно передрукувати вирішальні місця («сторінка X, ближче до верху, там має бути написано … — будь ласка, наберіть точно») — щонайбільше три місця, що переносяться дослівно в зцілену версію; будь-яка прогалина, що залишилася, відкрито розкривається. Юрист таким чином діє як візуальний інструмент точності саме для тієї частки скану, яку машина не може розв’язати, замість того щоб обробляти документ вручну.

18. Особи, установи, клієнти та пропозиції даних

Інструменти розпізнавання знаходять клієнтів, осіб і установи за фрагментом імені з толерантністю до діакритики; пошук за ключовим словом шукає в іменах, нотатках і полях аналізу, коли відомий лише фрагмент. Детермінована перевірка списку зіставляє документ, що містить список імен, з усіма особами та компаніями в записах, адресуючи його за ідентифікатором доказу або за справою — тоді сканується найновіший запис справи, і він називається у відповіді. У з’єднаннях Claude і ChatGPT перевірка сторін заздалегідь приймає наступні сторони й шукає їх у фоновому режимі, поки опрацьовується поточна; результати зберігаються тридцять хвилин, а порядок шлюзу залишається незмінним. Мережеві інструменти перелічують усіх, хто пов’язаний з однією стороною явними зв’язками та спільними справами, кліки всієї мережі сторін шляхом детермінованого виявлення спільнот (точно подання Всесвіту на екрані осіб, із позначкою підозрілості для незвично щільних груп і необов’язковим розділенням осіб і установ на шари) та найбільш пов’язані сторони; кожна відповідь, що стосується сторони, починається з блоку справ, з якими пов’язана сторона. Засіб читання профілю повертає кожне поле основних даних і аналізу повністю й без урізання. Засоби читання профілів повертають профіль суб’єкта з аналізом і зв’язками, усі зв’язки особи в обох напрямках між особами та установами, профіль установи та установи, формально прив’язані до справи. Засіб читання обліку часу повідомляє пасивно виміряний робочий час (кожен перегляд сторінки триває до наступного, з обмеженням у тридцять хвилин, останній зараховується як одна хвилина) як огляд підсумків і провідних справ, клієнтів і днів або як поденну розбивку однієї справи, за діапазоном дат або за вікном останніх днів, що за замовчуванням дорівнює семи.

Записувати в основні дані безпосередньо неможливо. Два інструменти пропозицій розміщують знахідки в моніторі узгодженості даних застосунку як елементи для перевірки: пропозиція основних даних (лише після того, як користувач підтвердив у чаті, що знахідку слід внести) стосується наявного суб’єкта чи установи — спершу розпізнаних за іменем — або описує новий запис за іменем і полями, з переліком дозволених полів, у якому корпоративні та персональні ідентифікаційні номери мають одне спільне поле, дозволено лише обґрунтовані поля та необов’язкові посилання на докази; пропозиція зв’язку описує зв’язок між двома розпізнаними особами або між особою та установою, рівно з одним контрагентом, обов’язковою категорією, необов’язковим обґрунтуванням і необов’язковими посиланнями на справу, клієнта й докази. Пропозиція може також перейменувати запис (поле Name), встановити його вид (поле PersonKind: фізична чи юридична особа), змінити категорію наявного зв’язку, запропонувати видалення (запису, тегу чи виконаного строку) з обґрунтуванням системною мовою, яке є обов’язковим, або запропонувати два записи як дублікати; новий запис приймається лише після того, як вид було визначено в діалозі, а пропозиція, що стосується опису чи контактних даних особи, відхиляється, якщо абонент не прочитав цей профіль протягом останніх тридцяти хвилин. В обох процесах запис змінюється лише тоді, коли користувач приймає пропозицію в моніторі. На пропозицію нового запису спершу надходить відповідь зі списком подібних наявних записів — нестрого зіставлених, нічого не зберігається — і абонент має або внести дані до одного з них, або явно, параметром, підтвердити, що сторона справді нова; строгий збіг перенаправляється до наявного запису. Кожна збережена нова сторона повертає обов’язкове подальше завдання, що наказує абонентові дослідити та внести зв’язки сторони, включно з вебдослідженням. Третій інструмент пропозицій прив’язує сторону до справи: рівно один суб’єкт чи установа, обов’язкове обґрунтування та необов’язкові посилання на докази стають елементом перевірки прив’язки до справи в тому самому моніторі; прийняття записує прив’язку учасника, на якій будуються подання клік і зв’язків, тоді як про наявну прив’язку, дублікат, що очікує розгляду, чи попереднє відхилення повідомляється замість повторної пропозиції. Застосунок також підраховує пропозиції для кожного абонента: після двох збережених пропозицій основних даних і однієї пропозиції зв’язку чи прив’язки до справи він розглядає сеанс як підтримку мережі сторін, один раз додає підказку, що для цієї повністю захищеної шлюзами роботи не потрібна модель найвищого рівня, і — у чаті застосунку — утримує роботу на середньому рівні моделі. Незалежні фонові процеси живлять той самий монітор: засіб вилучення даних із дедуплікацією на джерелі та періодичне сканування нормалізації, яке пропонує об’єднання й перекласифікацію за трикатегорійною моделлю (фізична особа; юридична особа як будь-яке корпоративне утворення, що не є окремою людиною, причому запис у торговельному реєстрі має перевагу над державною власністю; установа як державні органи без запису в реєстрі) — ніколи не об’єднуючи автоматично.

19. Правова бібліотека

Бібліотека містить повні тексти законів як файли markdown із внутрішнім реєстраційним номером для кожного закону. Інструмент переліку посторінково переглядає перелік (ідентифікатор, юрисдикція, назва, вид, назва файлу, дата останньої перевірки; за замовчуванням п’ятдесят, щонайбільше п’ятсот) і працює лише на читання. Інструмент пошуку обов’язковий перед будь-яким інтернет-пошуком норми: він зіставляє або за позначенням із назвою та описом, або за процитованим уривком із нечіткою толерантністю (достатньо приблизно шістдесяти відсотків слів, а закінчення слів допускаються), вимагає юрисдикції, взятої зі справи, ранжує збіги в назві значно вище за збіги у вмісті (збіг у назві важить дев’ять десятих, кожна знахідка у вмісті — одну десяту, щонайбільше три фрагменти на файл) і повертає для кожної знахідки реєстраційний номер, назву файлу, короткі фрагменти з їхніми точними позиціями символів і готовий виклик для дослівного фрагмента, діапазон якого вже збільшено — щонайменше на п’ятсот символів понад фрагмент, — тож модель сама отримує авторитетне формулювання замість того, щоб довіряти фрагменту. Інструмент фрагментів повертає дослівний вміст одного закону між двома позиціями символів, адресований за реєстраційним номером, обмежений межами файлу, з приміткою на початку, що діапазон можна скоригувати і що весь закон можна завантажити, а завеликі результати автоматично перенаправляються до сховища чернеток; зіставлення цифр у пошуках законів використовує правила меж, толерантні до позначення тисяч крапкою на офіційних порталах. Цілі закони можна завантажити за назвою файлу або за реєстраційним номером, а великі файли автоматично перенаправляються. Інструмент реєстрації — обов’язковий канал повідомлення про будь-який закон, знайдений у відкритому вебі: подаються лише посилання, юрисдикція та необов’язкові назва й речення; фоновий процес завантажує, конвертує, зберігає й оголошує джерело в моніторі даних, а сама модель ніколи нічого не конвертує. Цикл перегляду бібліотеки відстежує дату останньої перевірки кожного джерела. Закон, завантажений користувачем як файл без онлайн-джерела, містить попередження про актуальність у кожній відповіді, оскільки його чинність неможливо перевірити. Відхилення закону в моніторі даних вимагає підтвердження, що називає наслідок: закон залишає бібліотеку, а відхилення оновлення видаляє весь закон, також на офісному сервері.

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

20. Валідатори та реєстри

Детерміновані інструменти перевірки охоплюють: IBAN (формат, довжина для конкретної країни, контрольна сума); національні персональні, страхові та податкові номери за дев’ятьма схемами в шести країнах за контрольними цифрами, з цільовим режимом для кожної схеми та автоматичним режимом, що перевіряє всі схеми й повідомляє дійсні; європейські ідентифікатори платників ПДВ (спершу офлайн-перевірка формату країни, потім офіційний сервіс Союзу наживо, що повертає оприлюднені дані компанії там, де держава-член їх надає); номери EORI щодо сервісу валідації Союзу наживо; ідентифікатори юридичних осіб (спершу контрольна сума, потім глобальний реєстр для статусу й назви); і номери торговельних реєстрів через європейський портал бізнес-реєстрів, що відображається в справжньому браузерному рушії, причому моделі наказано прочитати повернену сторінку й підтвердити знахідку. Кожен валідатор повертає конкретний, обґрунтований результат — дійсний з подробицями, недійсний із зазначенням аспекту, що не пройшов перевірку, не знайдено або сервіс недоступний, включно зі статусом, — ніколи не голе «так» чи «ні», тож справді хибний номер завжди можна відрізнити від збою. Рівень інструкцій робить запуск відповідного валідатора обов’язковим, перш ніж будь-який такий номер потрапить до створеного чи перевіреного документа. Той самий набір інструментів містить інструмент приблизного місцезнаходження користувача (країна, місто та публічна адреса з останнього знімка входу, явно не джерело юрисдикції) та інструмент погоди, що працює за принципом «найкраще, що можливо».

21. Вебдоступ

Два інструменти виходять у відкритий інтернет, обидва подані як доповнення до власних вебможливостей настільного ШІ, з явною інструкцією використовувати їх безпосередньо, коли ШІ не має власного вебдоступу, і забороною використовувати їх для даних, пов’язаних зі справами. Інструмент пошуку виконує запити через вебінтерфейс, що імітує людину, з вибором пошукових систем і повертає знахідки з назвами й посиланнями, призначені для подальшого відкриття засобом відкриття сторінок. Засіб відкриття сторінок завантажує рівно одну публічну URL-адресу за допомогою поетапного конвеєра, який опис перелічує повністю, щоб модель ніколи не здавалася передчасно: HTTP-запит, що імітує людину, зі справжніми заголовками браузера, обробкою перенаправлень і стисненням; автоматичне виявлення перевірок проти ботів з ескалацією до справжнього вбудованого браузерного рушія; виявлення сторінок-оболонок JavaScript із рендерингом, доки не з’явиться вміст; посторінково точне перетворення PDF з використанням текстового шару для кожної сторінки й OCR лише для сканованих сторінок, тож змішані документи працюють; і перетворення офісних і текстових форматів на читабельний текст. Вивід — markdown, повністю: виділяється основний вміст (навігація, реклама й банери cookie видаляються), сторінки без тіла статті зберігають нижній колонтитул, бо там стоять адреса й контактні дані, а там, де виділення залишило б майже нічого, натомість видається вся сторінка. Виклик відповідає протягом сорока п’яти секунд; великий або сканований документ обробляється далі у фоновому режимі й видається одразу під час наступного виклику з тією самою адресою. Портали законів відхиляються, доки не виконано пошук у бібліотеці, згідно зі шлюзом законів.

22. Навігація GUI та експорт

Уся навігація вмикається лише за бажанням через перемикач користувача; без нього вся група не існує. Інструменти навігації відкривають у головному вікні застосунку: справу (за бажанням на вкладці хроніки чи оцінки), список справ клієнта, особу, установу (обидві з виділенням і відкритими подробицями), запис доказу (правильна сторінка хроніки, з виділенням), підготовку досьє (з повністю автоматичним варіантом, зарезервованим для явного бажання користувача отримати повний PDF), щоденний протокол (за бажанням подробиці конкретного дня), монітор електронної пошти (за бажанням подробиці конкретного листа), глобальний пошук із запущеним запитом (зарезервовано для явного бажання; відповіді в чаті натомість використовують внутрішній пошук), область резервного копіювання з негайним запуском резервного копіювання та будь-який названий екран із канонічного списку екранів. Діалоги експорту охоплюють список клієнтів, список строків, огляд справ клієнта, досьє справи у двох типах документів і карту, а також створення пакета ШІ клієнта. Усі інструменти навігації підлягають жорсткому блокуванню й є цілями пропозицій навігації з розділу 7.

23. Письмо, формати та видача

Набір інструментів письма прив’язує створення документів до отриманих специфікацій. Інструмент формату виводу повертає обов’язкову інструкцію генерації для запитаного виду артефакту — для процесуальних документів із розрізненням процесуального документа й простого листа, кожен у формі з представником і без представника, з юрисдикцією, мовою та датою справи, підставленими безпосередньо в інструкцію, і заповнювачами, які модель заповнює даними з конектора; інструмент формату поштового надсилання повертає обов’язкову специфікацію для надсилання листів до суду з послідовною видачею пакетів. Обидва треба виконувати буквально. Передача до редактора передає процесуальний документ у markdown безпосередньо до текстового процесора IRONSTICK із завантаженим текстом, але нічого не зберігаючи — користувач перевіряє та зберігає — і доступна в з’єднанні з Claude. Інструмент захоплення хроніки відкриває попередньо заповнену форму хроніки в правильній справі, сам нічого не зберігаючи.

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

24. Взаємна перевірка між ШІ

Інструмент передачі передає створену роботу іншому настільному ШІ: вміст потрапляє до короткочасного великого сховища, запис завдання посилається на нього, інструкція (обмежена тисячею символів) зазначає, що має зробити колега, а модель потім просить користувача запустити колегу в іншому застосунку. Інструмент вхідних перелічує відкриті завдання, адресовані абонентові, — його власні ніколи не з’являються — з ідентифікатором, дорученням і повним вмістом, за бажанням із фільтром за клієнтом чи справою. Інструмент відповіді закриває завдання (видаляючи його короткочасний вміст) і водночас надсилає оцінку назад як нове завдання початковому відправникові; інструмент завершення закриває без повернення. Читання й запис чернеток є членами цього набору інструментів для роботи з вмістом, яким обмінюються.

25. Файли інструкцій для ШІ

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

26. Супутні інтеграції поза поверхнею інструментів

Один клієнтський супутній компонент доповнює міст, не будучи частиною поверхні MCP: встановлюваний skill-плагін для кожного настільного ШІ (п’ять навичок, що відображають робочу модель наборів інструментів і запуску інструментів, згенеровані й версіоновані конфігуратором застосунку). Конфігурацію фронтенду мосту для кожного ШІ записують відповідні кнопки конфігуратора, які завжди записують ідентичність абонента та шлях інструкцій, щоб захистити від спільного використання конфігурації різними ШІ.

27. Семантика збоїв і відмов — підсумок

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