Модель данных

Эта страница описывает логическую модель данных — что означают ключевые сущности и как они связаны. DDL здесь сознательно нет: авторитетная схема живёт в миграциях платформы.

Иерархия контракта

Компания (ai_company) — вершина иерархии; простая сущность.
Контракт (salescontracts) — центральная единица работы: одна ниша, один бренд, одна контент-программа. Активный контракт двигает весь цикл Collect → Generate → Publish.
Конфиг (scrapper_config) — 1:1 с контрактом; всё, что параметризует его пайплайн: онтология тем, описание бренда (оно же кормит бренд-защиту), источники, пин версии пайплайна, эндпоинт публикации и метка целевого сайта.
Пул авторов (scrapper_lc_authors) — ростер подписей сайта контракта.
Сайт (hugo_instance) — один задеплоенный целевой сайт; связан с контрактом через метку инстанса в конфиге.

Производство и доказательства

Прогон (pipeline_run / run_step) — запись одного исполнения пайплайна и его пошаговый прогресс. Инфраструктурные записи, не бизнес-сущности: сюда смотрят, чтобы узнать, что произошло на самом деле.
Исследовательский факт (research_fact) — одно извлечённое, привязанное к источнику утверждение в корпусе контракта; несёт значение (число, цену, дату), которым статьи заземляют цифры. У фактов есть статусы, включая карантин для гигиены корпуса.
Статья (generated_articles) — произведённый материал. Поле article хранит финальный HTML, который и публикуется; отдельное поле с обогащённым текстом — неформатированная редакторская форма. Большое JSON-поле extra накапливает сигналы по статье (скоры дедупа, результаты grounding, класс источника) — по конвенции только merge, никогда overwrite.
Опубликованный URL (published_url + проверка внешнего URL) — реестр соответствий источник↔слаг. Публикация засчитывается только после того, как живой URL проверен на доступность — это proof-of-publication платформы.

Учёт и наблюдаемость

Usage event (usage_event) — токен-точный учёт стоимости каждого LLM-вызова с атрибуцией к прогону и контракту.
Error event (error_event) — единый сток ошибок всей платформы, читается через API (см. Как читать ошибки).
Поисковые метрики (таблицы analytics) — недельные ряды search console по сайтам плюс тематическая отдача для петли фидбека.

Метамодельное наследие

Бизнес-сущности несут общий набор системных полей из метамодели платформы: глобальный числовой id (guid), ревизию оптимистичной блокировки (rsid), указатель жизненного цикла (lcid / lcstep — какой стейт-машине следует сущность и где стоит) и аудит-поля (владелец, кто обновил, таймстемпы). Два практических следствия:

Состояние жизненного цикла — это данные. «Контракт активен» — это значение шага лайфцикла, а не boolean-колонка: движок лайфциклов продвигает сущности по их стейт-машинам.
Ссылки — на уровне приложения. Связи на диаграмме выше поддерживаются приложением, а не FK базы, поэтому проверки целостности живут в коде и верифаерах, а не в constraints.