Задача и границы#
Для выбранной ячейки выпущенного отчёта нужно объяснить, какие версии данных и преобразований дали её значение. Путь должен вести через статью отчётности к строкам проводок и исходным событиям, сохраняя контекст конкретного выпуска. Ссылка на текущую таблицу вместо исторического входа этой задачи не решает.
Здесь рассматривается аддитивный показатель движений одной валюты без распределений, конвертации и консолидационных исключений. Это предлагаемый инженерный контракт со статусом knowledge, а не описание опыта автора или новой лабораторной реализации. Правила выбора соответствий счетов уже разобраны в отдельной статье; здесь они используются как закреплённая зависимость.
Зерно, ключи и время#
Зерно результата - одна ячейка в конкретном выпуске: release_id, форма и её версия, статья, юридическое лицо, регистр, период, валюта и масштаб. Координаты строки и столбца интерфейса не являются устойчивым ключом: сортировка отчёта может измениться. Сумма задана целыми копейками RUB; дебет положительный, кредит отрицательный, множитель знака представления сохраняется отдельно.
Входное зерно - версия строки проводки. Логический ключ включает источник, юридическое лицо, регистр, документ и номер строки; line_version_id определяет выбранное состояние. Версия события определяется ключом источника и идентификатором версии. Одно событие может дать несколько строк, а одна строка может зависеть от нескольких событий: связь не следует считать взаимно однозначной.
business_date определяет включение в период, observed_at фиксирует получение версии EDWH. Выпуск сохраняет бизнес-границы периода, cutoff доступности и идентификатор входного снимка. Время запуска преобразования не заменяет эти координаты. Правила доступности и поздних изменений заданы контрактом закрытия периода.
Два вида связей#
Техническая lineage показывает зависимость набора или колонки от других наборов и преобразований. Финансовый drill-back дополнительно требует конкретных ключей записей и вкладов в выбранную ячейку. Знание, что таблица отчёта построена из журнала, не определяет, какие строки дали конкретную сумму.
W3C PROV-DM, рекомендация 2013 года, определяет сущности, деятельности и отношения происхождения. Снимок входа можно представить сущностью, расчёт - деятельностью, результат - созданной сущностью. Такая интерпретация не устанавливает бухгалтерские правила и не предписывает предлагаемую ниже структуру вкладов.
OpenLineage 1.53.0 описывает задания, запуски и наборы данных; column lineage facet описывает зависимости выходных полей от входных. Эти метаданные полезны для технического графа, но сами по себе не являются реестром вкладов отдельных проводок. Интеграция OpenLineage в проект здесь не добавляется.
Контракт происхождения выпуска#
| Объект |
Что сохранять |
| Манифест выпуска |
Ключи ячеек, снимок входа, временные границы, валюту и масштаб |
| Преобразование |
Идентификатор запуска, неизменяемую версию кода, параметры и зависимости |
| Правила |
Версии соответствий, структуры отчёта, календаря и знаков |
| Вклад |
Ключ ячейки, версию строки, правило, сумму вклада и единицу |
| Происхождение строки |
Связи версии строки с версиями исходных событий и приёмными партиями |
| Контроль |
Проверенный набор, правило контроля, результат и обнаруженные нарушения |
Реестр вкладов хранит одну запись на пару «ячейка - версия строки» в этой упрощённой модели. Связи с событиями хранятся отдельно: соединение вкладов со всеми событиями может размножить сумму. Суммируют реестр вкладов, а события используют для объяснения происхождения. Нельзя складывать сумму события с суммами его проводок.
Идентификатор версии или хеш не заменяет доступное содержимое. Для воспроизведения сохраняют входные данные и используемые правила либо обеспечивают их извлечение из неизменяемого хранилища. Версия кода без параметров и зависимостей также недостаточна. Сроки хранения и права доступа согласуются отдельно; эта статья не задаёт юридический срок хранения.
Построение и контроль вкладов#
Следующая последовательность - псевдокод, не исполняемый SQL или Python:
Закрепить выпуск, входной снимок и версии преобразований.
Выбрать строки по согласованным бизнес-границам и cutoff доступности.
Получить проверенную классификацию строк выбранным набором правил.
Сохранить вклады с ключами ячеек и версиями строк до агрегации.
Отдельно сохранить связи строк с исходными событиями.
Рассчитать ячейки из реестра вкладов с закреплённым правилом знака.
Сверить ключи, единицы, суммы вкладов и доступность цепочки происхождения.
Зафиксировать результат и контрольный протокол одного выпуска.
Синтетический пример: ячейка статьи A содержит две строки L1/v1 и L2/v1 с вкладами +10000 и -2000 копеек RUB. До применения множителя представления сумма равна 8000. Обе строки могут происходить из одного события E1/v1. В drill-back событие показывается один раз со связями к двум строкам; его сумма не прибавляется к 8000.
Проверяют уникальность пар вклада, существование каждой версии строки, соответствие валюты и масштаба, а также равенство суммы вкладов значению ячейки с учётом знака. Отдельно сравнивают ожидаемый набор классифицированных строк с набором вкладов. Равенство сумм не выявляет потерю двух взаимно погашающихся строк. Полнота исходных событий проверяется сверкой наборов, а не наличием технического графа.
Сохранять значение и происхождение желательно как один согласованный выпуск: готовая ячейка с недописанными связями не получает статус полного drill-back. Это общий принцип согласованности, не утверждение о поведении PostgreSQL, SQLite или Greenplum. Конкретная транзакционная реализация здесь не приводится и не тестировалась.
Ограничения drill-back и альтернативы#
Drill-back возвращает границу доступной детализации: до исходного события, только до проводки или только до агрегата. Если источник передал дневной итог, нельзя обещать восстановление отдельных операций. Недоступный архив, удалённые версии и ограничение прав должны давать явную причину, а не пустой список, похожий на отсутствие входов.
Постраничный просмотр показывает число разрешённых вкладов и разрешённый контрольный итог. Первые строки страницы не считаются полным объяснением суммы. Пользователь без прав на детали может видеть разрешённый агрегат и отметку об ограничении; происхождение не должно раскрывать конфиденциальные поля или пути с секретами. Полное число исходных строк тоже требует разрешения.
Материализованный реестр вкладов ускоряет расследование и сохраняет точный состав выпуска, но требует места. Восстановление связей по запросу уменьшает хранение, однако допустимо только при сохранённых входах, правилах и воспроизводимом алгоритме. Гибрид может хранить связи с разделами снимка и вычислять детали внутри них; это ограничение нужно раскрывать в контракте.
Для отношения, среднего или остатка простой суммы вкладов недостаточно. Отношение требует происхождения числителя и знаменателя; остаток - начального состояния и движений; распределение - весов и корректировок округления. Иерархические итоги могут повторно использовать те же строки, поэтому нельзя складывать конечные статьи с их итогами. Эти расширения требуют самостоятельного определения зерна вклада.
Полномочия в защищённом корпоративном контуре#
Следующий контракт относится к корпоративной системе с проверяемой идентичностью пользователя. Публичный статический сайт содержит только справочный текст и синтетические примеры: сюда не добавляются пользователи, авторизация или закрытые данные. Скрытие ссылки в интерфейсе не защищает файл, уже включённый в статическую сборку.
Решение о доступе связывает субъект, действие, объект и контекст запроса. Такой подход согласуется с определением ABAC в NIST SP 800-162, редакция с обновлением 2019 года. Документ описывает модель управления доступом, а не бухгалтерские требования; поля ниже являются проектным выбором.
| Часть решения |
Предлагаемый контракт |
| Субъект |
Проверенная идентичность и актуальные полномочия по юридическим лицам |
| Действие |
Просмотр агрегата, проводки, исходного события или выгрузка проверяются отдельно |
| Объект |
Юридическое лицо, регистр, выпуск, уровень детализации и классификация полей |
| Контекст |
Время запроса, версия политики и доверенный контекст корпоративной сессии |
Право на агрегат не означает права на проводки, payload события или экспорт. Полномочие для одного юридического лица не распространяется на его контрагента. Дату и снимок финансовых данных закрепляет выпуск, но доступ к старому выпуску проверяют по текущей политике: прежнее разрешение не должно переживать отзыв прав. Для воспроизводимости решения сохраняют версию политики и время проверки, не копируя секреты в журнал.
Проверка выполняется в доверенном контуре до выдачи данных и на каждом переходе от ячейки к строке и событию. Переданный пользователем идентификатор выпуска или строки не доказывает право доступа. Ссылки related и drill-back, поиск, подсказки, счётчики, сообщения об ошибках, выгрузки и кэш используют тот же контракт. Название документа, сниппет, ключ записи или число скрытых строк также могут раскрывать данные. Для отказа выбирают безопасное сообщение, не подтверждающее существование чужого документа. Кэш разделяют по эффективным полномочиям и версии политики; после отзыва нельзя отдавать сохранённый ответ с закрытыми деталями. Асинхронную выгрузку проверяют при формировании и получении; уже скачанный файл отозвать этим способом невозможно.
В PostgreSQL 18 включённая RLS без подходящей политики запрещает строки по умолчанию. Superuser и роли BYPASSRLS обходят RLS; владелец обычно тоже, если не применён FORCE ROW LEVEL SECURITY. Это поведение PostgreSQL, не переносимое обещание для Greenplum или SQLite. RLS сама по себе не задаёт права на поля, поиск или экспорт. Реализация здесь отсутствует.
Итог и доступная детализация#
Для аддитивной ячейки исходного зерна отдельно определяют разрешённый полный итог, сумму разрешённых вкладов и признак полноты объяснения. Сумма видимых строк равна полному итогу только при полном доступе ко всем вкладам того же выпуска, валюты, масштаба и правила знака. При ограничении нельзя обозначать видимую часть как полную сверку.
Синтетический пример: итог разрешённой ячейки равен 8000 копеек RUB, а доступный вклад - 10000. Разность -2000 раскрыла бы сумму скрытого вклада. Поэтому право на полный итог должно учитывать возможность такого вывода. Если сочетание итогов и деталей недопустимо, ограничивают сам итог или набор запросов; простое скрытие строки недостаточно. Разрешённый остаток можно показывать только по явно утверждённой политике, без обещания восстановить скрытые записи.
Внутренний контролёр с отдельным полномочием сверяет полный реестр с выпуском, а читателю выдаётся разрешённый статус контроля. Нельзя менять исторический итог из-за фильтра доступа: отфильтрованный расчёт является отдельным представлением с явно указанной областью. Пагинация не меняет эту область, и сумма одной страницы не равна сумме всех доступных вкладов.
При реализации потребуются отрицательные проверки: прямой запрос чужого ключа, переход к событию другого юридического лица, поиск по закрытому документу, выгрузка после отзыва прав и повтор из кэша. Отдельно проверяют отсутствие утечек через поля и счётчики и корректную маркировку частичного объяснения. Это план проверок, а не выполненные тесты. Исполняемый SQL/Python не добавлен; существующий алгоритм остаётся псевдокодом.
Мост изменений между выпусками#
Lineage объясняет один результат. Мост изменений отвечает на другой вопрос: почему одна и та же ячейка изменилась между выпусками A и B? Сравнивают устойчивый ключ ячейки, период, юридическое лицо или согласованный периметр группы, регистр, валюту, масштаб и знак представления. Если изменились определение показателя или состав компаний, сначала согласуют сопоставимую область либо выделяют отдельный эффект периметра. Без этого разность нельзя называть изменением одной сопоставимой величины.
Для аддитивного денежного показателя определим F(E, R, M, C; Z): E - версии входных событий и их cutoff, R - набор курсов, M - отображения счетов, C - правила корректировок, Z - календарь, код преобразования, параметры, порядок округления и остальные зависимости. Этот мост меняет только E, R, M и C; Z должен совпадать в обоих выпусках. Если изменился Z, его включают как отдельный фактор или признают данную декомпозицию недоступной. Никакое изменение нельзя молча отнести к входным событиям. Контракт курса описан в конвертации валют, классификация - в отображениях счетов, отдельный слой консолидационных корректировок - в исключениях оборотов.
Предлагаемый порядок подстановки - E, затем R, M и C. Сохраняют пять состояний:
| Состояние |
Расчёт |
Эффект относительно предыдущего |
| S0 |
F(EA, RA, MA, CA; Z) |
Исходное значение выпуска A |
| S1 |
F(EB, RA, MA, CA; Z) |
Входные события |
| S2 |
F(EB, RB, MA, CA; Z) |
Курсы |
| S3 |
F(EB, RB, MB, CA; Z) |
Отображения |
| S4 |
F(EB, RB, MB, CB; Z) |
Правила корректировок |
Это математическая схема, не исполняемый SQL/Python. Каждое промежуточное состояние - отдельный диагностический расчёт, а не утверждённый бухгалтерский выпуск. Нельзя просто соединить текущие таблицы с прежними версиями: старые правила могут не покрывать новые счета, а старый набор курсов - новые валюты. Несовместимость отмечают как невозможность данного шага, затем согласуют другую декомпозицию или совместимый периметр. Нулевой курс, пустое соответствие и автоматический выбор текущего правила не являются допустимыми заменами.
Синтетический пример задаёт одну ячейку в целых копейках RUB, дебет положительный, кредит отрицательный; знак представления фиксирован. Пусть диагностические значения S0..S4 равны 10000, 12000, 12600, 11600, 11300. Тогда эффекты равны +2000, +600, -1000, -300; сумма 1300 совпадает с 11300 - 10000. Значения придуманы только для демонстрации арифметики, не получены из лаборатории и не иллюстрируют требования стандарта учёта.
При изменении суммы и курса одновременно взаимодействие факторов попадает в более поздний шаг выбранного порядка. Обратный порядок может дать другие эффекты при том же конечном результате. Поэтому мост фиксирует порядок, а названия эффектов означают последовательные условные изменения, не единственную экономическую причинность. Альтернатива - усреднение по допустимым порядкам; оно требует дополнительных расчётов и отдельного правила распределения взаимодействий. Прямое сравнение реестров вкладов дешевле, но само по себе не отделяет совместное изменение курса и входа.
Контроль и воспроизводимость моста#
Манифест моста хранит ID обоих выпусков, сопоставимый ключ ячейки, порядок факторов, версии всех входов и правил, ID промежуточных расчётов, единицу, округление и контрольные результаты. S0 должен воспроизводить A, S4 - B, а сумма четырёх эффектов - разность B и A. Все сравнения выполняются в одной единице и на одном уровне округления. Если эффекты округляют отдельно для отображения, остаток показывают отдельной строкой по закреплённому правилу, а не прячут в выбранном факторе.
Разность ячеек не заменяет проверку состава: потерянные и добавленные взаимно погашающиеся строки могут дать нулевой эффект. Сравнивают ключи и версии вкладов, отдельно отмечают добавления, удаления и изменения; отсутствие ячейки не приравнивают к нулю без контракта полного покрытия. Перенос строки из статьи A в B объясняет обе ячейки; общий итог может не измениться. Нельзя суммировать эффекты детальных статей вместе с включающими их итогами.
W3C PROV-DM, Recommendation от 30 апреля 2013 года предоставляет сущности, деятельности и отношения происхождения. Применение этих понятий к снимкам и диагностическим расчётам - инженерная интерпретация. PROV не задаёт формулу финансовой атрибуции, порядок подстановки или бухгалтерские корректировки. Здесь также не утверждается конкретное поведение СУБД: транзакционная реализация и SQL не приведены, код не исполнялся.
При ограниченных полномочиях мост наследует контракт доступа обоих выпусков и промежуточных состояний. Даже разрешённая разность может раскрыть скрытый вклад; доступ к одному выпуску не означает доступа к другому. Невоспроизводимый вход, недоступный архив или несовместимые правила дают явное ограничение объяснения, а не статус полного моста.
Вопросы для подготовки: почему смена порядка меняет атрибуцию? Как обнаружить нулевой эффект при смене состава строк? Почему гибридный промежуточный расчёт может быть недопустим, хотя оба конечных выпуска корректны?
Граничные случаи и вопросы#
Проверяют нулевую ячейку с ненулевыми взаимно погашающимися вкладами, пустой вход, повторную загрузку связей, исправление версии события и новый запуск с теми же параметрами. Пустой вход отличают от неполной lineage. Повторная запись не создаёт дубли, а пересчёт создаёт новый выпуск; старые связи не переводятся на текущие версии. Успех задания сам по себе не доказывает полноту происхождения.
Независимые финансовые проверки описаны в сверке данных. Здесь дан проект контракта, а не результат испытания SQL или промышленного решения.
- Почему граф зависимостей колонок не позволяет объяснить состав одной ячейки?
- Как проверить полноту вкладов, если итог равен нулю?
- Что покажет drill-back старого выпуска после исправления исходного события?
Problem and scope#
For a selected cell in a released report, explain which data versions and transformations produced its value. The path must lead through the report item to journal lines and source events while preserving the context of that release. A link to the current table cannot substitute for its historical input.
This article covers an additive movement measure in one currency, without allocations, conversion, or consolidation eliminations. It proposes an engineering contract with knowledge status, rather than describing the author's experience or a new lab implementation. Account mapping rules are covered in a separate article; here they are used as a pinned dependency.
Grain, keys, and time#
The result grain is one cell in a particular release: release_id, report form and version, item, legal entity, ledger, period, currency, and scale. UI row and column coordinates are not stable keys because report sorting can change. Amounts are integer RUB kopecks; debit is positive and credit negative, with a separate stored presentation sign multiplier.
The input grain is a journal line version. Its logical key includes source, legal entity, ledger, document, and line number; line_version_id identifies the selected state. An event version is identified by its source key and version identifier. One event may produce several lines, and one line may depend on several events: the relationship must not be assumed to be one-to-one.
business_date determines period inclusion, while observed_at records when the EDWH received a version. A release retains the business period boundaries, availability cutoff, and input snapshot identifier. Transformation execution time does not replace these coordinates. Availability and late-change rules follow the period-close contract.
Two kinds of relationships#
Technical lineage describes how datasets or columns depend on other datasets and transformations. Financial drill-back also needs specific record keys and contributions to the selected cell. Knowing that a report table was built from a journal does not identify the lines behind a particular amount.
W3C PROV-DM, the 2013 Recommendation, defines entities, activities, and provenance relationships. An input snapshot can be represented as an entity, a calculation as an activity, and its result as a generated entity. This interpretation establishes neither accounting rules nor the contribution structure proposed below.
OpenLineage 1.53.0 describes jobs, runs, and datasets; its column lineage facet describes dependencies of output fields on input fields. These metadata support a technical graph but do not, by themselves, constitute a register of individual journal line contributions. This article adds no OpenLineage integration to the project.
Release provenance contract#
| Object |
What to retain |
| Release manifest |
Cell keys, input snapshot, time boundaries, currency, and scale |
| Transformation |
Run identifier, immutable code version, parameters, and dependencies |
| Rules |
Versions of mappings, report structure, calendar, and signs |
| Contribution |
Cell key, line version, rule, contribution amount, and unit |
| Line provenance |
Links from a line version to source event versions and ingestion batches |
| Control |
Checked set, control rule, result, and detected violations |
In this simplified model, the contribution register stores one record per cell and line-version pair. Event relationships are stored separately: joining contributions to all events can multiply amounts. Sum the contribution register and use events to explain provenance. Never add an event amount to the amounts of its journal lines.
A version identifier or hash does not replace accessible contents. Reproduction requires retaining input data and rules or making them retrievable from immutable storage. A code version without parameters and dependencies is also insufficient. Retention periods and access permissions are agreed separately; this article specifies no legal retention period.
Building and checking contributions#
The following sequence is pseudocode, not executable SQL or Python:
Pin the release, input snapshot, and transformation versions.
Select lines using the agreed business boundaries and availability cutoff.
Obtain validated line classification under the selected rule set.
Retain contributions with cell keys and line versions before aggregation.
Retain relationships from lines to source events separately.
Calculate cells from the contribution register using the pinned sign rule.
Reconcile keys, units, contribution totals, and provenance-chain availability.
Commit the result and control record for a single release.
Synthetic example: the cell for item A contains two lines, L1/v1 and L2/v1, contributing +10000 and -2000 RUB kopecks. Before applying the presentation multiplier, the sum is 8000. Both lines may originate from one event, E1/v1. Drill-back displays that event once with links to both lines; its amount is not added to 8000.
Check contribution-pair uniqueness, existence of each line version, matching currency and scale, and equality between the contribution sum and cell value after applying the sign. Separately compare the expected set of classified lines with the contribution set. Equal totals cannot detect the loss of two offsetting lines. Source-event completeness is checked through set reconciliation, rather than the presence of a technical graph.
Value and provenance should be retained as one consistent release: a completed cell with unfinished relationships does not qualify for complete drill-back. This is a general consistency principle, not a claim about PostgreSQL, SQLite, or Greenplum behavior. No specific transactional implementation is provided or has been tested here.
Drill-back limits and alternatives#
Drill-back reports the available level of detail: source event, journal line only, or aggregate only. If the source supplied a daily total, individual transactions cannot be promised. An unavailable archive, deleted versions, or access restrictions must produce an explicit reason rather than an empty list that looks like an absence of inputs.
Paginated views show the authorized contribution count and authorized control total. The first page of lines is not a complete explanation of the amount. A user without permission to see details may see the authorized aggregate and a restriction indicator; provenance must not expose confidential fields or paths containing secrets. The full source-row count also requires permission.
A materialized contribution register speeds up investigations and retains exact release membership, but requires storage. Reconstructing relationships on demand reduces storage, yet is acceptable only with retained inputs, rules, and a reproducible algorithm. A hybrid can retain links to snapshot partitions and calculate details within them; the contract must disclose this limitation.
A ratio, average, or balance needs more than a simple sum of contributions. A ratio needs numerator and denominator provenance; a balance needs its opening state and movements; an allocation needs weights and rounding adjustments. Hierarchical totals can reuse the same lines, so leaf items must not be added to their subtotals. These extensions each need a separate definition of contribution grain.
Permissions in a protected enterprise environment#
The following contract applies to an enterprise system with a verifiable user identity. This public static site contains reference text and synthetic examples only; no users, authorization, or restricted data are added here. Hiding a link in the interface does not protect a file already included in a static build.
An access decision connects the subject, action, object, and request context. This approach is consistent with the ABAC definition in NIST SP 800-162, updated in 2019. The document describes an access-control model rather than accounting requirements; the fields below are project choices.
| Decision component |
Proposed contract |
| Subject |
Verified identity and current permissions for legal entities |
| Action |
Viewing an aggregate, journal line, source event, or export is checked separately |
| Object |
Legal entity, ledger, release, detail level, and field classification |
| Context |
Request time, policy version, and trusted enterprise-session context |
Permission to view an aggregate does not grant access to journal lines, event payloads, or exports. Permission for one legal entity does not extend to its counterparty. The release fixes financial dates and the data snapshot, but access to an old release is checked against the current policy: a former grant must not survive revocation. Retain the policy version and decision time to reproduce the decision, without copying secrets into the log.
Checks run within the trusted environment before data is returned and at every transition from cell to line to event. A release or line identifier supplied by the user is not proof of authorization. Related-reading and drill-back links, search, suggestions, counters, error messages, exports, and caches follow the same contract. Document names, snippets, record keys, and hidden-row counts can also disclose data. Denials use a safe message that does not confirm another entity's document exists. Partition caches by effective permissions and policy version; after revocation, a cached response must not return restricted details. Check asynchronous exports both when generated and when retrieved; this cannot revoke an already downloaded file.
In PostgreSQL 18, enabled RLS with no applicable policy denies rows by default. Superusers and BYPASSRLS roles bypass RLS; owners normally do too unless FORCE ROW LEVEL SECURITY applies. This is PostgreSQL behavior, not a portable guarantee for Greenplum or SQLite. RLS alone does not define field, search, or export permissions. No implementation is provided here.
Totals and accessible detail#
For an additive cell at the original grain, define the authorized full total, the sum of authorized contributions, and an explanation-completeness indicator separately. Visible lines sum to the full total only when all contributions are accessible for the same release, currency, scale, and sign rule. Restricted detail must not be labeled a complete reconciliation.
Synthetic example: an authorized cell total is 8000 RUB kopecks, while the accessible contribution is 10000. The difference of -2000 would disclose the hidden contribution's amount. Permission to see the full total must therefore account for this inference. If the combination of totals and details is unacceptable, restrict the total itself or the set of queries; simply hiding a row is insufficient. An authorized residual may be shown only under an explicitly approved policy, without promising to reconstruct hidden records.
An internal controller with separate permission reconciles the full register with the release, while the reader receives an authorized control status. Do not change a historical total because of an access filter: a filtered calculation is a separate view with an explicit scope. Pagination does not change that scope, and one page's sum is not the sum of all accessible contributions.
Implementation would require negative checks: directly requesting another entity's key, navigating to an event for another legal entity, searching for a restricted document, exporting after revocation, and replaying a cached response. Also check for leaks through fields and counters and correct labeling of a partial explanation. This is a verification plan, not completed tests. No executable SQL/Python has been added; the existing algorithm remains pseudocode.
A change bridge between releases#
Lineage explains one result. A change bridge answers a different question: why did the same cell change between releases A and B? Compare a stable cell key, period, legal entity or agreed group perimeter, ledger, currency, scale, and presentation sign. If the metric definition or company perimeter changed, first establish a comparable scope or identify a separate perimeter effect. Otherwise, the difference cannot be described as a change in one comparable quantity.
For an additive monetary measure, define F(E, R, M, C; Z): E represents input event versions and their cutoff, R the rate set, M account mappings, C adjustment rules, and Z the calendar, transformation code, parameters, rounding sequence, and other dependencies. This bridge varies only E, R, M, and C; Z must be identical in both releases. If Z changes, include it as a separate factor or report this decomposition as unavailable. No change may be silently attributed to input events. The rate contract is covered in currency conversion, classification in account mappings, and the separate consolidation adjustment layer in intercompany eliminations.
The proposed substitution order is E, then R, M, and C. Preserve five states:
| State |
Calculation |
Effect relative to the preceding state |
| S0 |
F(EA, RA, MA, CA; Z) |
Original value in release A |
| S1 |
F(EB, RA, MA, CA; Z) |
Input events |
| S2 |
F(EB, RB, MA, CA; Z) |
Exchange rates |
| S3 |
F(EB, RB, MB, CA; Z) |
Mappings |
| S4 |
F(EB, RB, MB, CB; Z) |
Adjustment rules |
This is a mathematical outline, not executable SQL/Python. Each intermediate state is a separate diagnostic calculation, not an approved accounting release. Joining current tables to older versions is insufficient: old rules may not cover new accounts, and the old rate set may not cover new currencies. Record an incompatible step as unavailable, then agree on another decomposition or a compatible perimeter. A zero rate, missing mapping, or automatic selection of the current rule is not an acceptable substitute.
A synthetic example defines one cell in whole RUB kopecks, with positive debits and negative credits; the presentation sign is fixed. Suppose the diagnostic values S0..S4 are 10000, 12000, 12600, 11600, and 11300. The effects are +2000, +600, -1000, and -300; their sum of 1300 equals 11300 - 10000. These values were invented solely to illustrate arithmetic, were not produced by the lab, and do not illustrate accounting standard requirements.
When both the amount and the rate change, their interaction is assigned to the later step in the selected order. Reversing the order may produce different effects with the same final result. The bridge therefore records the order, and effect labels represent sequential conditional changes, not a unique economic explanation of causality. An alternative is to average over valid orders; this needs additional calculations and a separate interaction allocation rule. Direct comparison of contribution registers costs less, but does not by itself separate simultaneous changes in rates and inputs.
Bridge controls and reproducibility#
The bridge manifest stores both release IDs, the comparable cell key, factor order, versions of all inputs and rules, intermediate calculation IDs, unit, rounding, and control results. S0 must reproduce A, S4 must reproduce B, and the four effects must sum to B minus A. Perform all comparisons in the same unit and at the same rounding level. If effects are rounded separately for display, show the remainder as a separate line under a fixed rule rather than hiding it in a selected factor.
Cell differences do not replace checks of membership: missing and added offsetting rows can produce a zero effect. Compare contribution keys and versions, identifying additions, deletions, and changes separately; do not equate a missing cell with zero without a complete coverage contract. Moving a row from item A to B explains both cells while the overall total may remain unchanged. Do not sum effects for detailed items together with totals that include them.
W3C PROV-DM, Recommendation of 30 April 2013 provides entities, activities, and provenance relations. Applying these concepts to snapshots and diagnostic calculations is an engineering interpretation. PROV does not prescribe a financial attribution formula, substitution order, or accounting adjustments. No database-specific behavior is asserted here either: no transactional implementation or SQL is provided, and no code was executed.
With restricted permissions, the bridge inherits the access contract for both releases and intermediate states. Even a permitted difference may expose a hidden contribution; access to one release does not grant access to the other. An input that cannot be reproduced, an unavailable archive, or incompatible rules imposes an explicit limit on the explanation rather than allowing a complete-bridge status.
Practice questions: why does changing the order change attribution? How can a zero effect conceal a change in row membership? Why might a hybrid intermediate calculation be invalid even when both final releases are correct?
Boundary cases and questions#
Check a zero cell with nonzero offsetting contributions, empty input, repeated relationship loading, correction of an event version, and a new run with identical parameters. Distinguish empty input from incomplete lineage. Repeated writes must not create duplicates, and recalculation creates a new release; old relationships must not be redirected to current versions. Successful job completion alone does not prove provenance completeness.
Independent financial checks are covered in data reconciliation. This article presents a proposed contract, rather than SQL test results or a production solution.
- Why can a column dependency graph not explain the membership of a single cell?
- How can contribution completeness be checked when the total is zero?
- What will drill-back show for an old release after its source event is corrected?