Стандарт

Мінімальний стандарт командного артефакту

Версія 0.1 (для пілотів Legal Copilot Ukraine)

Автор: Сергій АвдєйчикОпубліковано 10 липня 2026 р.5 хв читання

Стандарт ґрунтується на об'єктній моделі VeriLex (concept v0.2) на базі JSON Schema 2020-12.

1. Призначення та принципи

Стандарт визначає мінімальні вимоги до робочого пакета (Legal Work Package, LWP) — одиниці командного обміну результатами юридичної роботи. Принципи:

Відкриті формати. Markdown, JSON/JSONL, YAML, CSV, Mermaid, Git. Жодних пропрієтарних контейнерів; пакет читається людиною в будь-якому редакторі та агентом у будь-якому середовищі.
Пропорційність. Три рівні деталізації (базовий / розширений / аудиторський); рівень обирається за ціною помилки, а не «про всяк випадок».
Перевірюваність важливіша за повноту. Кожен обов'язковий елемент існує тому, що його хтось перевіряє — людина або агент.
Сумісність. Пакет, зібраний в одному агентському середовищі (OpenAI Codex, Anthropic Claude Code, відкриті аналоги), має прийматися та перевірятися в будь-якому іншому. Стандарт спирається лише на готові, промислово експлуатовані середовища — власне ПЗ для роботи з пакетами розробляти не потрібно, застосування стандарту може починатися вже сьогодні.
Немає джерела — немає сильного висновку. Агент пропонує — людина вирішує.

2. Вісім типів артефактів (ядро стандарту)

Наслідуються з об'єктної моделі VeriLex v0.2:

Тип	Файл	Призначення
`source_registry`	`sources/source-registry.json`	Реєстр джерел: що лягло в основу, з ідентифікаторами, датами, статусами доступу
`evidence_pack`	`sources/evidence-pack.jsonl`	Витягнуті доказові фрагменти, прив'язані до конкретного місця конкретного джерела
`fact_matrix`	`analysis/fact-matrix.json`	Факти зі статусами, відокремлені від правових оцінок
`rules_matrix`	`analysis/rules-matrix.json`	Застосовні норми та критерії (з редакціями та датами чинності), пов'язані з фактами
`issue_tree`	`analysis/issue-tree.json`	Дерево юридичних питань: аналіз як набір перевірюваних питань
`critique_pack`	`analysis/critique-pack.json`	Слабкі місця, контраргументи, альтернативні позиції — обов'язковий для кожного серйозного висновку
`decision_log`	`logs/decision-log.json`	Журнал ключових рішень: розвилки, альтернативи, невизначеність, хто підтвердив
`handoff_package`	`handoff/handoff.json`	Пакет передачі: що зроблено, що перевірено, що спірно, що робити наступному; посилається на конкретні версії артефактів

3. Загальний конверт метаданих

Кожен артефакт несе конверт:

artifact_type: fact_matrix        # один з 8 типів
schema_version: "0.1"             # версія схеми стандарту
matter_id: MAT-2026-0042          # ідентифікатор доручення/справи
version: 3                        # цілочисловий інкремент; версії незмінні
created_at: 2026-07-10T14:30:00+03:00
created_by:
  actor: "О. Шевченко"
  actor_type: human               # human | agent | joint
  agent_env: "claude-code 2.x"    # якщо брав участь агент
review_status: human_confirmed    # draft | agent_generated | human_review_pending |
                                  # human_confirmed | returned_for_rework | archived
depends_on:                       # з яких версій входів зібрано
  - fact_matrix@2
  - rules_matrix@1
model_call_refs: []               # посилання на журнал викликів моделі (аудиторський рівень)
confidentiality: institutional    # public | institutional | confidential
language: uk

4. Статуси фактів (канонічний набір)

alleged (стверджується) · established (встановлено) · disputed (оспорюється) · inferred (виведено) · missing (немає даних) · rejected (відхилено) · excluded (виключено).

Інваріанти:

established вимагає ≥1 прив'язаного доказу з evidence_pack та підтвердження людиною;
висновок, що спирається лише на alleged/inferred факти, не може позначатися як сильний;
кожне суттєве твердження фінального тексту посилається на fact_id / rule_id / source_id.

5. Ланцюг походження

source → evidence → fact → rule → issue → conclusion → decision_log → handoff

Зв'язки зберігаються в самих артефактах (поля source_id, evidence_ids, fact_ids, rule_ids, issue_id) і утворюють перевірюваний граф. Валідатор зобов'язаний уміти побудувати граф і знайти: висячі висновки (без підстав), невикористані джерела, розриви ланцюга, цикли.

6. Три рівні пакета

Базовий (повсякденна робота)

Обов'язкові: final/ (текст) + source_registry + ключові факти (спрощена fact_matrix) + короткий журнал перевірок + open-questions.md.

Розширений (складні дослідження)

Базовий + повні fact_matrix, rules_matrix, issue_tree, critique_pack, таблиця доказів, граф зв'язків (reasoning-graph.mmd), протокол верифікації.

Аудиторський (висока ціна помилки)

Розширений + decision_log з полями підтвердження, журнал дій (activity.jsonl), ідентифікатори моделей/інструкцій (model_call_refs, версія інструкцій), контрольні хеші файлів (checksums.sha256), ролі учасників, знімок пакета на момент рішення.

7. Обов'язкові перевірки під час приймання пакета

Приймальна сторона (її агент) виконує мінімум:

Схемна валідація всіх JSON/YAML-артефактів.
Перевірка ланцюга: немає сильних висновків без підстав (check_unsupported_claims).
Перевірка цитат: витягнуті фрагменти відповідають першоджерелам (validate_evidence_links).
Перевірка дат: редакції норм чинні на юридично значущі дати (date-check).
Перевірка конфіденційності: пакет не містить даних, заборонених до передачі на цьому рівні (redaction-check) — український словник чутливих даних: РНОКПП/ІПН, паспортні дані, адреси, банківські реквізити, лікарська та адвокатська таємниця.
Перевірка повноти handoff: зазначено невирішені питання та наступний крок.

Пакет, що не пройшов перевірки 1–3, повертається автоматично зі структурованим переліком блокерів (це не «відмова», а нормальний цикл).

8. Правила формування та приймання

Версії артефактів незмінні; виправлення = нова версія. Минулі версії не видаляються, а архівуються.
handoff_package посилається на конкретні версії (fact_matrix@4), а не на «останній стан».
Зауваження оформлюються critique_pack на адресу конкретних елементів (fact_id, conclusion_id) — не прозою в листі.
Фінальний документ (final/*.md) — похідний артефакт: за розбіжності тексту та матриць пріоритет у матриць; розбіжність = дефект пакета.
Мови: артефакти — мовою роботи (uk), метадані та ключі — латиницею за стандартом; допускається паралельне поле _en.
Пакет живе в Git-репозиторії доручення; тег handoff/<n> фіксує момент передачі.

9. Метрики якості пакета

Метрика	Формула	Цільовий поріг пілоту
Source coverage	частка суттєвих тверджень із прив'язкою до джерел	≥ 90%
Unsupported claim rate	частка сильних висновків без підстав	→ 0
Handoff completeness	частка передач, прийнятих без повернення з формальних причин	≥ 80%
Time to review	медіанний час перевірки пакета отримувачем	↓ ≥ 50% проти базлайну
Reproducibility score	частка висновків із відновлюваним ланцюгом «з яких версій входів»	≥ 95%

10. Статус і розвиток стандарту

Версія 0.1 — відправна точка для пілотів; свідомо мінімальна. Зміни — через PR у відкритий репозиторій (питання позиціювання описані окремо); кожна зміна схеми = інкремент schema_version + міграційна нотатка. Повні JSON-схеми восьми артефактів уже існують в об'єктній моделі VeriLex і переносяться у відкритий репозиторій як нормативний додаток до цього стандарту; приклад заповненого пакета — приклад пакета артефактів.

Назад до матеріалів