Каталог данных компании показывает владельца и смысл таблицы: агенты связывают описание с кодом

Что искать, если отчёты расходятся? Не название похожей таблицы, а цепочку от показателя до источника. В карточке должны быть определение, ответственный и ссылка на расчёт.

Каталог хранит сведения о данных. В блоге VK Юрий Орлов описывает его как единое место для поиска структуры и связей. Граф происхождения данных, или lineage, показывает, откуда таблица получает данные и кто использует её дальше. Связь одного товара между системами требует управления мастер-данными и правил соответствий.

Возьмём учебный показатель «Оплаты за месяц». В нашем примере финансовый отдел утвердил такое правило: успешные платежи по дате проведения минус возвраты, проведённые в том же месяце. Это выбранное определение примера, не правило бухгалтерского учёта.

Описание «содержит оплаты» не разрешает спор. Из него нельзя узнать, учитывает ли отчёт возвраты и к какому месяцу их относит. Каталог должен сохранять эти решения вместе с именем владельца.

Можно ли восстановить значение таблицы по коду? Код покажет, какие поля складывают и какие записи исключают. Он не ответит, хотел ли финансовый отдел именно такой показатель.

Агент для кода способен подготовить черновик описания по схеме, запросам и тестам. Если определение и запрос расходятся, результатом работы должен стать найденный спор. Молча переписать определение под нынешний запрос означает скрыть возможную ошибку.

Готовые каталоги уже решают часть этой задачи. Arenadata Catalog предлагает владельцев, бизнес-глоссарий и связи объектов. Документация DataHub связывает общие определения с колонками, которые их реализуют. Строить собственный интерфейс для этого необязательно.

Для учебного показателя человек решает, что делать с возвратом за прошлый месяц. Агент находит, как поступает код сейчас, и готовит пример для проверки. Без решения владельца описание остаётся черновиком.

Где держать определения? В месте, которое читают при изменении расчёта, а из каталога вести к нему. В dbt описания моделей и колонок находятся в проекте, в YAML рядом с тестами данных. Это существующий способ держать документацию рядом с работой.

В нашей машине описание проекта тоже живёт рядом с кодом. Открытая карта проекта показывает 387 тысяч строк описаний и 391 тысячу строк кода на 8 октября 2026. Это состояние публичной карты, не объём разработки каталога для клиента.

Файл с описанием сам по себе ещё не управляет агентом. Правила для ИИ-агентов должны быть доступны до правки. Мы проверили это на собственной ошибке: правило лежало в документе, через который исполнитель не входил в задачу.

Для каталога предлагаем перенести этот механизм на расчёты. Правка схемы запускает сверку полей, правка запроса требует пересмотреть связанное определение. Отметка «требует проверки» остаётся, пока владелец не примет изменение.

Существование файла подтверждает только адрес ссылки. Чтобы замечать изменение расчёта, нужно отслеживать его версию или отпечаток кода. Такой сигнал требует ревью, но сам не доказывает правильность смысла.

В уроке «Файл правил целиком» нашего курса агентной разработки описан вход агента в правила проекта. Для каталога полезен тот же приём: в задаче есть указатель на определение и способ проверки, а не просьба «разобраться с данными».

Что заказать разработчику? Реестр, который можно сверить с действующей системой. Сам список таблиц недостаточен: в результате должны быть видны неподтверждённые определения и разорванные связи.

В задаче для агента задайте границу работы по выбранному показателю. Агент получает схему и разрешённые файлы расчёта, собирает список объектов и прикладывает основание к каждому описанию. Неизвестного владельца оставляет неизвестным.

Расчёт может проходить через несколько систем. Преобразование во внешнем сервисе не появится в графе лишь от чтения репозитория. Инженер добавляет способ сбора этих сведений, а до этого отмечает пробел в цепочке.

В учебном примере агент связывает платежи, возвраты и отчёт. Финансовый отдел принимает определение, инженер проверяет расчёт. Запись «владелец: отдел аналитики» без согласования не завершает работу.

Как отличить рабочий каталог от заполненной витрины? Попросите сотрудника, который не участвовал в сборке, найти источник показателя и человека для разбора спорного случая. Ответ должен получиться из карточки, без объяснений автора.

Затем сломайте связь в тестовой копии. Переименуйте поле либо измените фильтр расчёта. До обновления определения каталог должен показать расхождение, а проверка должна указать конкретный объект.

Исправность ссылок не доказывает правильность показателя. В нашем примере файл расчёта может существовать, но считать возвраты иначе. Поэтому отдельно принимают сверку схемы и пример, подтверждённый владельцем.

Для такой приёмки подходят искусственные примеры. Данные людей и агенты требуют отдельного решения о доступе. Записи клиентов не нужны, чтобы проверить ссылку на поле или работу учебного расчёта.

С чего начинать? Выберите показатель, из-за которого уже приходится сверять отчёты вручную. Согласуйте определение и доведите его цепочку до источника. Так станет видно, каких связей и решений не хватает.

Если готовый каталог уже собирает метаданные, сохраните его. Агентам можно поручить интеграцию описаний из репозитория, проверки связей или экран нерешённых вопросов. Собственный реестр имеет смысл, когда эта узкая задача остаётся без решения.

До начала работы замерьте, сколько занимает поиск источника и владельца. После сборки повторите тот же вопрос с другим сотрудником и проверьте реакцию на изменение расчёта. Число заполненных карточек не заменяет эти результаты.

Если вести сборку некому, подписка на агентную разработку «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026: инженер ведёт машину агентов, готовые изменения идут в репозиторий клиента, одна задача на поток, пауза в любой месяц. Реестр и проверки можно обсудить для вашей компании, начав с выбранного показателя.

1. Начните с показателя в отчёте и проследите его до источника.

2. Закрепите определение за владельцем; черновик агента требует его решения.

3. Свяжите описание с кодом и настройте сигнал при изменении расчёта.

4. Принимайте каталог на разорванной связи и вопросе нового сотрудника.

5. Следующий показатель добавляйте после проверки обновлений первого.