Verifiable Legal Document

Проверяемый юридический документ

Contract

• Job-to-be-done: собрать юридический документ, где существенные claims проверяются по внутренним ссылкам, evidence и hashes.
• Inputs: approved structured spec, evidence ledger, source fragments, output format и validation policy.
• Outputs: HTML/DOCX, evidence appendix, manifests/hashes и machine-readable validation report.
• Evidence and safety: не добавляй содержание вне ledger; минимизируй source fragments и проверяй metadata перед распространением.
• Stop conditions: останови build/release при missing evidence, broken anchors, hash mismatch, unsafe path или blocker validation.
• Acceptance test: вручную открой три claim links/backlinks, сверь fragments с источником и повтори validator.

Цель

Сделать проверку тезиса быстрой и локальной: из основного текста пользователь кликает ссылку и попадает в том же HTML/DOCX на точное предложение/абзац приложения, подтверждающее тезис. Приложение хранит provenance, context, version и hash.

Канонический pipeline

источники → адресуемые evidence units → structured spec JSON → validator → self-contained HTML/DOCX → independent audit

Подробная спецификация: references/document-contract.md и docs/VERIFIABLE_DOCUMENT_SPEC.md.

Evidence model

• claim_id — уникальный тезис в основном документе.
• claim_type — fact/legal_proposition/numeric/quotation/interpretation/assumption/recommendation.
• source_id — конкретный источник/редакция.
• unit_id — точное адресуемое предложение или абзац.
• evidence_refs — список unit_id, поддерживающих claim.
• counterevidence_refs — фрагменты, ограничивающие/опровергающие claim.
• source SHA-256 и unit SHA-256 защищают от незаметной подмены.

Режим приложения

1. full — полный нормализованный текст источника разбит на units. Предпочтителен для нормативных актов/судебных решений, если объем, право на воспроизведение и политика позволяют.
2. evidence-pack — точные cited units с достаточным контекстом, metadata, hash и ссылкой/путем к целому источнику. Используй, если полный документ нельзя законно/технически включить.
3. page-image evidence — для скана: релевантная страница/область + OCR/extracted text + marker human-verified или needs-human-verification.

Никогда не заявляй, что приложение полное, если включены только excerpts.

Процедура

1. Убедись, что evidence gate пройден и source register завершен.
2. Для каждого разрешенного источника создай source object. Можно начать с:

python3 tools/verifiable_document/ingest.py \
  --input  \
  --source-id SRC-001 \
  --title "" \
  --authority "" \
  --retrieved-at 2026-07-11T00:00:00Z \
  --output 

Для machine-extracted PDF/DOCX проверь critical units вручную и обнови verification_status.

1. Создай spec по tools/verifiable_document/examples/spec.example.json.
2. Свяжи каждый material claim с точными unit_id. Ссылка не должна вести только на титульную страницу или весь документ.
3. Добавь counterevidence и qualifications там, где источник содержит оговорки.
4. Проверь spec:

python3 tools/verifiable_document/validate.py  --report 

1. Собери документ:

python3 tools/verifiable_document/build.py  --out-dir  --html --docx

HTML является каноническим self-contained форматом. DOCX создается при наличии python-docx и содержит internal hyperlinks/bookmarks.

1. Повтори validation после сборки. Не выдавай документ при blocker errors.
2. Для DOCX выполни visual QA: ссылки/bookmarks, переносы, таблицы, приложения, скрытые метаданные. Если renderer недоступен, явно передай этот пункт человеку.
3. Запусти независимый $legal-qa-audit.

Обязательные проверки

• все material claims имеют evidence;
• все evidence refs разрешаются;
• нет duplicate IDs;
• file hash совпадает с записанным;
• unit hash совпадает с текстом;
• locator и verification status заполнены;
• ссылки ведут на exact unit и есть backlink;
• приложение раскрывает inclusion mode;
• unsupported/assumption claims визуально отличимы;
• adverse/counterevidence не скрыто;
• source metadata и retrieval date видимы;
• нет локальных секретных путей в публикуемом файле.

Ограничение

Техническая валидность ссылок не доказывает правильность юридической интерпретации. Она доказывает только воспроизводимую связь между текстом тезиса и указанным фрагментом. Содержательная проверка остается обязательной.

Definition of done

Validator завершился без errors, reviewer кликом проходит от каждого material claim к точному supporting unit, источник/версия/hash доступны, а validation report и audit findings сохранены рядом с документом.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: sergeionlyart
• Source: sergeionlyart/miniuscodex_lab
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.