Это полный перевод для чтения нормативного оригинала на английском, проверенного в редакции репозитория 61e75e9aa9a8719dfb480bf1f5226553b3a21d70. Перевод носит информационный характер и не является новой редакцией спецификации. Оригинал совпадает с исходной редакцией 3fcbb9f828c2f23d109c855ee403c3a4c81f3a96; SHA-256: 5a3311d270bebb16d558010e75064f5b75323f284992641732b1c8097511f948. Английская копия для чтения.

Здесь описан временной профиль date-3fcbb9f: stale_after задаётся датой. Спецификация профиля временных отметок закреплена за другой редакцией OKF 0.2. Требования «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ» и «МОЖЕТ» передают соответственно MUST, MUST NOT, SHOULD и MAY оригинала. Имена полей, значения перечислений и условные имена типов сохраняются.

Open Knowledge Format (OKF)

Версия 0.2

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

Формат намеренно минимален: каталог файлов Markdown с блоками метаданных YAML в начале файлов. Реестра схем, центрального органа управления и обязательных инструментов нет. Если вы можете прочитать файл через cat, вы можете прочитать OKF; если можете клонировать репозиторий через git clone, можете передать набор знаний.

Документ самодостаточен: здесь указано всё необходимое для создания и чтения OKF v0.2. Изменения относительно v0.1 кратко перечислены в §13.

1. Мотивация

Представление знаний для AI-агентов быстро развивается, и появляется много несовместимых соглашений. OKF исходит из того, что знания лучше представлять в общедоступных, устоявшихся форматах, которые:

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

  1. На основе чего это создано и как проверено? (Происхождение.)
  2. Насколько этому можно доверять? (Доверие.)
  3. Верно ли это до сих пор? (Актуальность.)
  4. Текущая ли это версия? (Жизненный цикл.)
  5. Получено ли это число именно предписанным способом? (Подтверждение выполнения вычисления.)

OKF v0.2 явно описывает происхождение, доверие, жизненный цикл и подтверждение вычислений, сохраняя минимум предписаний. Формат ограничивается небольшим набором структурных соглашений, необходимых, чтобы набор знаний описывал сам себя; всё остальное остаётся на усмотрение автора.

Цели

  1. Определить универсальный формат, который могут записывать создатели: люди, агенты и процессы экспорта.
  2. Объяснить потребителям — агентам, интерфейсам, поисковым индексам и детерминированному коду — как читать документы и переходить между ними.
  3. Облегчить обмен знаниями между системами и организациями.
  4. Стандартизировать небольшой набор полей метаданных, по которым можно оценить доверие к набору знаний, поддерживаемому агентами, без предписания среды исполнения.

Что не входит в задачи

2. Термины

3. Структура набора

Набор — дерево каталогов с файлами Markdown. Структура каталогов не зависит от предметной области: создатели организуют понятия так, как удобно для фиксируемых знаний.

path/to/bundle/
  index.md                      # Необязательно. Список каталога для постепенного знакомства.
  log.md                        # Необязательно. Хронологическая история обновлений.
  <concept>.md                  # Понятие в корне набора.
  <subdirectory>/               # Подкаталоги группируют понятия.
    index.md
    <concept>.md
    <subdirectory>/
      ...

Набор МОЖЕТ распространяться как:

3.1 Зарезервированные имена файлов

Следующие имена имеют определённый смысл на любом уровне иерархии и НЕ ДОЛЖНЫ использоваться для документов понятий:

Имя файла Назначение
index.md Список содержимого каталога. См. §8.
log.md История обновлений. См. §9.

Все остальные файлы .md — документы понятий.

Метки остаются самостоятельным элементом формата благодаря полю tags (§4.1). OKF не задаёт отдельный файловый формат для группировки документов по меткам; потребитель, которому нужен просмотр по меткам, может сформировать его при чтении, просмотрев метаданные.

4. Документы понятий

Каждое понятие — файл Markdown в UTF-8 из двух частей:

  1. Блок метаданных YAML, начинающийся отдельной строкой --- в начале файла и заканчивающийся отдельной строкой ---.
  2. Тело Markdown с содержимым свободной формы.

4.1 Блок метаданных

---
type: <Имя типа>                  # ОБЯЗАТЕЛЬНО
title: <Необязательное название>
description: <Необязательное краткое описание>
resource: <Необязательный канонический URI описываемого объекта>
tags: [<tag>, <tag>, ...]          # Необязательно
# ... группы полей доверия, жизненного цикла, происхождения и вычислений (см. §5, §10)
# ... другие пары ключ/значение, определённые создателем
---

Обязательно:

type — единственный ключ, обязательный всегда; понятие, содержащее только type, полностью соответствует формату (§11).

Рекомендуется:

Также могут присутствовать необязательные группы полей происхождения, доверия и жизненного цикла (§5), а для понятий Attested Computation — поля вычислений (§10).

Расширения: создатели МОГУТ включать любые дополнительные ключи. Потребителям СЛЕДУЕТ сохранять неизвестные ключи при чтении и повторной записи; они НЕ ДОЛЖНЫ отвергать документы с незнакомыми полями.

4.2 Тело документа

Тело использует стандартный Markdown. Создателям СЛЕДУЕТ предпочитать структурированный Markdown — заголовки, списки, таблицы и ограждённые блоки кода — свободной прозе: структура помогает и людям читать, и агентам находить сведения.

Обязательных разделов тела нет. Следующие заголовки имеют условно закреплённое значение, и их СЛЕДУЕТ использовать там, где это применимо:

Заголовок Назначение
# Schema Структурированное описание столбцов или полей объекта.
# Examples Конкретные примеры применения, часто в ограждённых блоках кода.
# Computation Утверждённое вычисление понятия Attested Computation. См. §10.

Для привязки отдельных утверждений к внешним источникам используются сноски Markdown с ключами записей sources, а не список цитат в теле (§5.1).

4.3 Пример: понятие, связанное с ресурсом

---
type: BigQuery Table
title: Заказы покупателей
description: Одна строка на завершённый заказ покупателя по всем каналам.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders, revenue]
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-05-28T14:30:00Z }
---

# Схема

| Столбец | Тип | Описание |
|---|---|---|
| `order_id` | STRING | Глобально уникальный идентификатор заказа. |
| `customer_id` | STRING | Внешний ключ к [покупателям](/tables/customers.md). |
| `total_usd` | NUMERIC | Сумма заказа в долларах США. |
| `placed_at` | TIMESTAMP | Время оформления заказа покупателем. |

# Соединения

Соединяется с [покупателями](/tables/customers.md) по `customer_id`.

4.4 Пример: понятие без привязки к ресурсу

---
type: Playbook
title: "Реагирование на инцидент: оповещение об актуальности данных"
description: Шаги разбора оповещения об актуальности в процессе обработки заказов.
tags: [oncall, incident]
generated: { by: human:ahormati, at: 2026-04-12T09:00:00Z }
---

# Условие запуска

Оповещение об актуальности срабатывает, когда `orders` отстаёт от ожидаемого
SLA больше чем на 30 минут. См. [таблицу заказов](/tables/orders.md).

# Шаги

1. Проверить [панель задания загрузки](https://example.com/dash).
2. ...

5. Происхождение, доверие и жизненный цикл

Эти группы метаданных отвечают на вопросы «откуда это взялось», «насколько этому доверять» и «актуально ли это». Все они необязательны. Их отсутствие тоже имеет смысл: непроверенное понятие можно отличить от проверенного, но нельзя отвергать (§11).

5.1 Происхождение: sources

sources записывает материалы, на основе которых создано понятие, внутри или вне набора.

sources:
  - id: ga4-schema
    resource: https://developers.google.com/analytics/bigquery/export-schema
    title: Схема экспорта GA4 в BigQuery
    author: team:ga4-docs
    usage_count: 5000
    last_modified: 2026-05-30
usage_window: { from: 2026-06-01, to: 2026-06-30 }

Каждая запись sources:

Признаки надёжности источника. OKF записывает объективные признаки отдельных источников, чтобы потребитель мог оценить доверие к понятию через источники, из которых оно извлечено. Оценка надёжности числом не хранится: она субъективна, непереносима между потребителями и устаревает. Надёжность выводится из признаков, как и уровни доверия (§5.3), а не хранится. Каждый признак необязателен и находится в записи sources:

usage_count — грубый признак. По нему можно сравнивать активные и неиспользуемые источники, порядки величин и историю одного источника во времени. Он не подходит для точного ранжирования разных видов источников: выполнение запроса по расписанию и сознательный просмотр панели человеком имеют разный вес. Потребителям СЛЕДУЕТ читать его как признак активности и тенденции, а не как оценку.

Цепочка происхождения выражается ссылками, а не отдельным полем. Когда resource указывает на другое понятие OKF, связь происхождения уже существует в графе набора (§6). Поэтому потребитель МОЖЕТ рекурсивно пройти по sources этого источника и учитывать их надёжность далее по цепочке. Внешние конечные источники несут только собственные признаки. Более глубокие цепочки — явное внешнее derived_from или происхождение данных — не входят в v0.2.

Привязка отдельных утверждений. Для привязки конкретного утверждения используйте сноску Markdown, метка которой равна sources[].id:

Таблица `events_` ежедневно разбивается на таблицы `events_YYYYMMDD`.[^ga4-schema]

[^ga4-schema]: Схема экспорта GA4 в BigQuery

Метка сноски — ключ соединения с sources. Потребители определяют источник по соответствующей записи, а не разбирают текст сноски. Метки используют ключи, а не позиции (sources[0]), потому что агенты постоянно переписывают документы: позиционный индекс незаметно приписывает утверждение другому источнику при перестановке списка, тогда как устойчивый id сохраняет связь.

5.2 Доверие: generated и verified

generated фиксирует, как создано текущее содержимое. verified фиксирует, кто или что подтвердило содержимое по источникам или resource. Эти поля разделены, потому что автор понятия и проверивший его участник могут различаться.

generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-20T22:53:05Z }

verified:
  - { by: human:ahormati, at: 2026-06-25T09:00:00Z }
  - { by: process:finance-nightly, at: 2026-06-26T02:00:00Z }

verified: { by: human:ahormati, at: 2026-06-25T09:00:00Z }

5.3 Уровни доверия

Потребители выводят уровень доверия из verified, от низшего к высшему:

Понятие без метаданных доверия всё равно пригодно для чтения; потребители НЕ ДОЛЖНЫ отвергать его (§11). Уровни доверия — рекомендательные признаки, а не управление доступом.

5.4 Жизненный цикл: status

status: stable        # draft | stable | deprecated

Нет status ⇒ stable.

5.5 Жизненный цикл: stale_after

stale_after: 2026-09-23   # абсолютная дата; с этого дня содержимое устарело

Необязательно. Абсолютная дата (YYYY-MM-DD). Понятие устарело, когда today >= stale_after. Абсолютная дата, в отличие от относительного TTL, позволяет решить вопрос простым сравнением дат без обращения ко времени чтения понятия.

6. Перекрёстные ссылки и пути

Понятия МОГУТ ссылаться на другие понятия обычными ссылками Markdown. Поддерживаются две формы:

Ссылка из понятия A в понятие B утверждает связь. Конкретный вид — родитель/потомок, ссылка на материал, соединение, зависимость — передаёт окружающий текст, а не сама ссылка. Потребители, строящие граф, обычно рассматривают все ссылки как направленные рёбра связи без заданного типа.

Потребители ДОЛЖНЫ переносить неработающие ссылки: цель, отсутствующая в наборе, не делает ссылку некорректной; она может обозначать ещё не написанные знания.

6.2 Поля со значением пути

Несколько полей задают путь или URI: resource, sources[].resource, computation, executor.resource и attester.resource (§10). sources[].resource вместо этого может описывать область (§5.1), и тогда не является путём. Каждое поле со значением пути принимает:

6.3 Соглашение о references/

Подкаталог references/ по соглашению содержит копии внешних материалов, инструкции запуска или код как самостоятельные понятия внутри набора. Источники, исполнители и проверяющие вычисления часто указывают туда, например на references/attesters/revenue.py. Это соглашение об именовании, а не требование.

7. Соглашение об участниках

Поля, фиксирующие личность (generated.by, verified[].by), используют единое соглашение об участниках:

Потребители, определяющие доверие (§5.3), ориентируются на префикс human:. Поэтому создатели ДОЛЖНЫ использовать его для содержимого, написанного или подтверждённого человеком.

8. Индексные файлы

Файл index.md МОЖЕТ находиться в любом каталоге, включая корень набора. Он перечисляет содержимое каталога для постепенного знакомства: человек или агент сначала видит, какие материалы доступны, а затем открывает отдельные документы.

Индексные файлы не содержат блока метаданных, кроме одного случая: корневой index.md МОЖЕТ содержать ключ okf_version (§12). Тело содержит один или несколько разделов, каждый из которых группирует понятия под заголовком:

# Заголовок раздела или группы

* [Название 1](relative-url-1) - краткое описание пункта 1
* [Название 2](relative-url-2) - краткое описание пункта 2

# Другой раздел

* [Подкаталог](subdir/) - краткое описание подкаталога

Записям СЛЕДУЕТ включать описание из метаданных понятия, на которое они ссылаются. Создатели МОГУТ автоматически генерировать index.md; потребители МОГУТ формировать его на лету при отсутствии файла.

9. Файлы журнала

Файл log.md МОЖЕТ находиться на любом уровне иерархии и фиксировать историю изменений соответствующей области. Формат — плоский список записей, сгруппированных по датам, от новых к старым:

# Журнал обновлений каталога

## 2026-05-22
* **Обновление**: Добавлена ссылка на таблицу BigQuery для [метрик покупателей](/tables/customer-metrics.md).
* **Создание**: Создана [инструкция Dataplex](/playbooks/dataplex.md).

## 2026-05-15
* **Инициализация**: Создана базовая структура каталогов.

Заголовки дат ДОЛЖНЫ использовать форму ISO 8601 YYYY-MM-DD. Записи журнала — обычный текст; начальное выделенное слово (**Update**, **Creation**, **Deprecation**) является соглашением, а не требованием.

10. Понятие вычисления с подтверждением выполнения

Понятие Attested Computation содержит не только смысл значения, но и утверждённый способ его вычислить, чтобы потребитель мог подтвердить, что агент выполнил предписанное вычисление, а не придумал своё. Происхождение (§5.1) отвечает на вопрос «откуда взялось утверждение», а подтверждение выполнения — «получено ли число предписанным способом». OKF записывает вычисление и средства его проверки; сам формат ничего не исполняет.

10.1 Вычисление — отдельное понятие

Утверждённое вычисление — самостоятельное понятие с type: Attested Computation. Понятие, которому нужно значение (Metric, BigQuery Table), ссылается на него обычной ссылкой Markdown (§6). Отдельное понятие обосновано тремя свойствами:

10.2 Поля контракта

Контракт — поля верхнего уровня в метаданных понятия. Помимо групп происхождения, доверия и жизненного цикла (§5), понятие Attested Computation содержит:

Что находится за resource — навык агента, скрипт, контейнер — вопрос упаковки. OKF задаёт интерфейс, а не упаковку (§1).

---
type: Attested Computation
title: Выручка за финансовый год
description: Признанная выручка за финансовый год по определению финансовой службы.
status: stable
runtime: bigquery
parameters:
  - { name: year, type: integer, required: true }
executor:
  resource: references/skills/run-on-bq.md
  receipt: [job_id, executed_sql, result]
attester:
  resource: references/attesters/revenue.py
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-20T22:53:05Z }
verified: { by: human:ahormati, at: 2026-06-25T09:00:00Z }
stale_after: 2026-09-23
sources:
  - id: rev-policy
    resource: https://wiki.acme/finance/revenue-recognition
    title: Правила признания выручки
---

# Computation

    SELECT SUM(amount) AS revenue
    FROM finance.recognized_revenue
    WHERE fiscal_year = @year

Вычисление привязывает только объявленные `parameters` согласно правилам
признания выручки.[^rev-policy]

[^rev-policy]: Правила признания выручки

10.3 Вычисление

Предоставьте вычисление одним из двух способов:

runtime: bigquery
computation: references/computations/lib/revenue.sql
parameters:
  - { name: year, type: integer, required: true }

Агент МОЖЕТ задавать только значения объявленных parameters; он НЕ ДОЛЖЕН писать или редактировать вычисление. Привязка значений параметров к computation и получение исполняемого результата — задача потребителя. Проверяющий независимо повторяет ту же привязку, чтобы сравнить её с реально выполненным кодом. Поскольку сравнивается развёрнутый, скомпилированный результат из свидетельства выполнения (executed_sql, compiled_sql), переписанный запрос, подменённый файл вычисления или изменённая зависимость не проходят проверку. Типизированный интерфейс, допускающий только параметры, превращает вопрос «выполнилось ли утверждённое вычисление» в механическое сравнение, а не субъективное решение.

10.4 Понятия, использующие вычисление

Документ редко описывает одно вычисление. Обзор отчёта о прибылях и убытках, обсуждающий выручку, прибыль и маржу, остаётся одним читаемым понятием и ссылается на отдельное Attested Computation для каждого показателя:

---
type: Metric
title: Выручка
description: Признанная выручка за финансовый год.
tags: [finance, revenue]
status: stable
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-20T22:53:05Z }
---

# Определение

Признанная выручка — сумма `amount` по строкам, отнесённым к финансовому году;
её получает [вычисление выручки](../computations/revenue.md).

Поскольку каждое вычисление — отдельное понятие, выручка может быть актуальна, а прибыль — уже за пределами stale_after; каждый запуск подтверждается отдельно. Совместное размещение — выбор каталогов (computations/ с index.md), а не блока метаданных.

10.5 Как потребитель использует это (информационный раздел)

Этот подраздел информационный, а не нормативный. Результаты исполнения ниже не хранятся в наборе.

  1. Найти по type: Attested Computation — признаку в метаданных, который можно вынести в index.md. Потребитель открывает понятие напрямую или по ссылке из использующего его понятия.
  2. Загрузить контракт из метаданных и вычисление из тела или файла, указанного в computation.
  3. Задать параметры: агент предоставляет значения объявленных параметров.
  4. Выполнить: исполнитель запускает вычисление с привязанными значениями и возвращает свидетельство выполнения со структурой executor.receipt.
  5. Подтвердить: потребитель запускает проверяющий код на свидетельстве выполнения. Код подтверждает происхождение: выполненное вычисление совпадает с computation, к которому привязаны заявленные параметры, а не с SQL, написанным агентом. Он также подтверждает точность: показанное значение совпадает с достоверным источником свидетельства, повторно прочитанным по идентификатору задания, а не взятым из текста агента.
  6. Принять решение: отказаться показывать значение при неуспешном подтверждении; предупредить или отказать при today >= stale_after. При успехе показать заключение, например ссылку на журнал задания, чтобы основание доверия было видно.

10.6 Проверка документа и подтверждение выполнения

verified (§5.2) и подтверждение выполнения различаются и существуют одновременно:

Понятие с устаревшим определением всё ещё может успешно пройти подтверждение выполнения. Недавно проверенное определение всё равно требует подтверждения каждого запуска. Поэтому нужны оба механизма.

11. Соответствие формату

Набор соответствует OKF v0.2, если:

  1. Каждый незарезервированный файл .md в дереве содержит разбираемый блок метаданных YAML.
  2. Каждый блок метаданных содержит непустое поле type.
  3. Каждый файл с зарезервированным именем (index.md, log.md), если присутствует, следует структуре §8 и §9 соответственно.

Если присутствуют группы полей доверия, жизненного цикла, происхождения или вычислений, создателям СЛЕДУЕТ следовать §5–§10, а потребителям:

Потребителям СЛЕДУЕТ считать все остальные ограничения мягкими рекомендациями. В частности, потребители НЕ ДОЛЖНЫ отвергать набор из-за:

12. Версионирование

Этот документ задаёт OKF версии 0.2. Редакции имеют версии <major>.<minor>:

Наборы МОГУТ объявлять целевую версию через okf_version: "0.2" в метаданных корневого index.md: это единственное место, где index.md может содержать блок метаданных. Потребителям, не понимающим объявленную версию, СЛЕДУЕТ попытаться прочитать набор в меру своих возможностей, а не отказывать.

Рассмотрено и отложено

Следующее намеренно оставлено будущей редакции:

13. Изменения относительно v0.1

v0.2 заменяет OKF v0.1 и повышает минорную версию по §12, кроме двух намеренных несовместимых изменений ниже: они переименовывают или упраздняют поля v0.1. Потребитель v0.2 может прочитать набор v0.1 с описанными здесь резервными способами чтения.

13.1 Несовместимые изменения

13.2 Совместимые дополнения

Все следующие изменения — дополнения: новые необязательные ключи, один новый тип понятия и один новый условный заголовок. При их отсутствии остаётся обычное понятие v0.1.

Всё остальное перенесено без изменений: структура набора, зарезервированные имена файлов, обязательный type, рекомендуемые title/description/resource/tags, перекрёстные ссылки, индексные файлы, журналы и допускающие необязательные данные правила соответствия.

Приложение A: подробный пример — отчёт о прибылях и убытках

Один набор, использующий все группы полей, представлен как миграция отчёта с v0.1 на v0.2. В отчёте два показателя: выручка и валовая прибыль.

Форма v0.1

Один документ: оба показателя в одном понятии, SQL в тексте, который агент может прочитать, проигнорировать или переписать; цитаты — плоский список, единственная временная отметка — timestamp.

---
type: Metric
title: Отчёт о прибылях и убытках за финансовый год
description: Основные показатели отчёта о прибылях и убытках за финансовый год.
tags: [finance, income-statement]
timestamp: '2026-05-28T22:53:05+00:00'
---

# Определение
Отчёт о прибылях и убытках показывает выручку и валовую прибыль за финансовый год.

# Выручка
Признанная выручка — сумма `amount` по строкам, отнесённым к финансовому году:

    SELECT SUM(amount) AS revenue
    FROM finance.recognized_revenue
    WHERE fiscal_year = <year>

# Валовая прибыль
Валовая прибыль по сегментам согласно стандарту распределения затрат:

    SELECT gross_profit FROM fct_income_statement
    WHERE fiscal_year = <year> AND segment = <segment>

# Citations
- https://wiki.acme/finance/fpa-handbook
- https://wiki.acme/finance/revenue-recognition
- https://wiki.acme/finance/cost-allocation

Форма v0.2

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

bundles/finance/
  metrics/income-statement.md      type: Metric  (описывает и ссылается на оба)
  computations/revenue.md          type: Attested Computation  (runtime: bigquery)
  computations/profit.md           type: Attested Computation  (runtime: dbt)
  references/skills/run-on-bq.md, run-dbt.md
  references/attesters/sql-equality.py, dbt-binding.py

metrics/income-statement.md — читаемый документ; доверие к вычислениям относится к объектам его ссылок, а не к этому документу:

---
type: Metric
title: Отчёт о прибылях и убытках за финансовый год
description: Основные показатели отчёта о прибылях и убытках за финансовый год.
tags: [finance, income-statement]
status: stable
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-20T22:53:05Z }
verified: { by: human:ahormati, at: 2026-06-25T09:00:00Z }
stale_after: 2026-12-31
sources:
  - id: fpa-handbook
    resource: https://wiki.acme/finance/fpa-handbook
    title: Руководство по отчётности FP&A
---

# Определение
Отчёт о прибылях и убытках показывает [выручку](../computations/revenue.md) и
[валовую прибыль](../computations/profit.md) за финансовый год по руководству
FP&A.[^fpa-handbook] Каждый показатель получается утверждённым вычислением,
выполнение которого можно подтвердить; это понятие только описывает их.

[^fpa-handbook]: Руководство по отчётности FP&A

computations/revenue.md — BigQuery SQL, проверен человеком, актуален и подтверждён активно используемой панелью с признаками надёжности:

---
type: Attested Computation
title: Выручка за финансовый год
description: Признанная выручка за финансовый год по определению финансовой службы.
tags: [finance, revenue]
status: stable
runtime: bigquery
parameters:
  - { name: year, type: integer, required: true }
executor:
  resource: references/skills/run-on-bq.md
  receipt: [job_id, executed_sql, result]
attester:
  resource: references/attesters/sql-equality.py
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-28T14:00:00Z }
verified: { by: human:ahormati, at: 2026-06-25T09:00:00Z }
stale_after: 2026-12-31
sources:
  - id: rev-policy
    resource: https://wiki.acme/finance/revenue-recognition
    title: Правила признания выручки
    author: team:finance-fpa
    last_modified: 2026-04-02
  - id: exec-rev-dash
    resource: dashboards/exec-revenue
    title: Панель выручки для руководства
    author: team:finance-fpa
    usage_count: 5000
    last_modified: 2026-06-18
usage_window: { from: 2026-06-01, to: 2026-06-30 }
---

# Computation

    SELECT SUM(amount) AS revenue
    FROM finance.recognized_revenue
    WHERE fiscal_year = @year

Признанная выручка по правилам признания выручки,[^rev-policy] подтверждённая
панелью выручки для руководства.[^exec-rev-dash]

[^rev-policy]: Правила признания выручки
[^exec-rev-dash]: Панель выручки для руководства

computations/profit.md — модель dbt, проверенная процессом; дата stale_after уже прошла:

---
type: Attested Computation
title: Валовая прибыль за финансовый год
description: Валовая прибыль по сегментам за финансовый год по стандарту распределения затрат.
tags: [finance, profit]
status: stable
runtime: dbt
parameters:
  - { name: year, type: integer, required: true }
  - { name: segment, type: string, required: true }
executor:
  resource: references/skills/run-dbt.md
  receipt: [run_id, compiled_sql, result]
attester:
  resource: references/attesters/dbt-binding.py
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-14T14:00:00Z }
verified: { by: process:finance-nightly, at: 2026-06-12T08:00:00Z }
stale_after: 2026-06-15
sources:
  - id: cost-alloc
    resource: https://wiki.acme/finance/cost-allocation
    title: Стандарт распределения затрат
---

# Computation

    SELECT gross_profit
    FROM {{ ref('fct_income_statement') }}
    WHERE fiscal_year = {{ var('year') }}
      AND segment = {{ var('segment') }}

Валовая прибыль по сегментам по стандарту распределения затрат.[^cost-alloc]

[^cost-alloc]: Стандарт распределения затрат