Задача и границы#
Три завершённые попытки обработки одной заявки не означают три принятых результата. Знаменатель управленческих удельных расходов должен различать работу, техническое завершение и подтверждённый выпуск. Здесь определяется проектный контракт принятого результата, без оценки сотрудников, весов сложности, распределения затрат и изменения лаборатории.
W3C PROV-DM, рекомендация 2013 года, различает сущности, действия, происхождение и ответственность. Это основа для описания связей результата с обработкой и решением о приёмке, но спецификация не задаёт бизнес-критерии качества или формулу знаменателя. Все правила включения ниже являются предлагаемыми решениями EDWH, не требованиями IFRS, ISO или конкретной СУБД. SQL/Python отсутствуют.
Зерно и идентичность#
Ключ результата (source_system, service_id, result_id) обозначает один ожидаемый результат услуги. Ключ попытки (source_system, attempt_id) обозначает один запуск работы. В выбранной модели попытка относится ровно к одному результату, результат может иметь несколько попыток. Если пакетная попытка производит несколько результатов, сначала нужен явный мост с составом пакета; прямой подсчёт строк соединения непригоден.
Содержимое результата имеет отдельную result_version. Решение приёмки с уникальным decision_id ссылается на точную версию результата, подтверждающую попытку, версию критериев, полномочие принимающей стороны и доказательства проверок. Новый идентификатор попытки или версия содержимого не создают новую единицу выпуска. Новый самостоятельный результат допускается только по определению услуги, например для отдельной заявки, с прослеживаемым основанием идентичности.
Зерно витрины - услуга, юридическое лицо, подразделение, неперекрывающийся бизнес-интервал, версия определения выпуска, снимок источника и release_id. Единица - один принятый результат, без валюты и без отрицательного количества в снимке. Денежный числитель отдельно сохраняет валюту, масштаб и знаки. Совместимость периметра и времени с ним проверяют по контракту удельных расходов.
Критерии и времена#
Версия критериев содержит проверяемые условия, область услуги, интервал действия, владельца и свидетельство утверждения. Например, синтетическая услуга требует наличия обязательных полей и положительного заключения контроля. Флаг «завершено» не доказывает эти условия. Новые критерии не применяют к старым решениям молча: сохраняют исходное решение и отдельный результат переоценки по новой версии.
Различайте completed_at попытки, accepted_at решения, бизнес-время возврата или отзыва и observed_at, когда EDWH узнал событие. Метки времени имеют явный часовой пояс; календарь услуги определяет дату включения. Для этой модели принятие не может предшествовать завершению подтверждающей попытки. Момент загрузки не заменяет момент приёмки.
Выпуск закрепляет два среза: бизнес-cutoff состояния и cutoff известности. Событие влияет на него только при попадании в оба среза. Равные времена упорядочивают по авторитетной последовательности источника; конфликтующие решения без такого порядка блокируют результат. Одного максимального timestamp недостаточно.
Доработка и отзыв#
Ниже принят контракт активного принятого выпуска: результат включается один раз, если на бизнес-cutoff действует приёмка его текущей версии и её исходная дата первого принятия принадлежит выбранному интервалу. Эта дата остаётся закреплённой за результатом после повторной приёмки. Это не счётчик событий приёмки за период.
| Событие |
Состояние результата |
Вклад в снимок |
| Попытка завершена, проверки не пройдены |
Требует доработки |
0 |
| Приёмка версии подтверждена |
Принят |
1 при попадании первой приёмки в интервал |
| Возврат после приёмки |
Требует доработки, прежняя приёмка прекращена |
0 |
| Новая попытка и повторная приёмка |
Принят с новой версией |
Не более 1, в исходном интервале |
| Отзыв приёмки |
Приёмка недействительна |
0 |
Возврат до первого принятия сохраняет нулевой вклад. Возврат после принятия и отзыв оформляют событиями с причиной и ссылкой на прекращаемое решение. Повторная доставка того же события не меняет состояние. Новую версию содержимого нельзя считать принятой по решению для прежней версии.
Синтетический пример: результат R имеет неуспешную попытку A1 и принятую A2 в январе. В январском выпуске известных тогда данных вклад R равен 1, попыток завершено 2. В феврале приёмку отзывают, затем принимают исправление A3. В новом снимке до повторной приёмки вклад R в январском интервале равен 0, после неё равен 1; новый февральский результат не возникает. Исходный январский выпуск сохраняется неизменным. Позднее известие об отзыве меняет новый пересчёт, а не архивный выпуск.
Альтернатива - считать первые приёмки как исторический поток, не вычитая последующий отзыв, и показывать отзыв отдельно. Она отвечает на вопрос «сколько впервые приняли тогда», тогда как выбранный контракт отвечает «сколько из принятого тогда остаётся действительным на срез». Эти показатели нельзя смешивать. Пересчёт периода принятия требует проверки сопоставимости с денежным числителем, а не автоматического переноса затрат между месяцами.
Сверка и покрытие#
Сначала сверяют ожидаемые результаты, попытки и журнал решений в закреплённом периметре. Каждая попытка имеет известный результат; каждое решение приёмки имеет существующую завершённую попытку, точную версию и доказательства по указанным критериям. Отсутствие журналов решений означает неизвестный принятый объём, а не ноль.
Каждый результат на срезе принадлежит ровно одной группе: принят, ожидает обработки или приёмки, требует доработки, отозван либо неразрешён. Сумма количеств групп равна количеству уникальных ожидаемых результатов. Принятый набор сверяют по ключам с действующими решениями, затем считают уникальные результаты; соединение с несколькими попытками не должно размножить вклад.
Отдельно сохраняют количество попыток, повторных попыток и результатов с доработкой. Попытки не складывают с результатами. Если критерии или версия результата неизвестны, итог по затронутому периметру не допускают как полный. Положительный счётчик завершений не доказывает полноту принятого выпуска. Взвешивание применяют лишь после выбора допущенного набора, сохраняя отличие результатов, попыток и эквивалентов.
Критерии допуска#
- Определены единица результата, ключи и связи с попытками и версиями; повторная работа не создаёт дополнительную единицу.
- Каждая действующая приёмка имеет версию критериев, полномочие и доказательства; версия содержимого совпадает с принятой.
- Закреплены календарь, оба cutoff, порядок событий и политика первой приёмки; незавершённая попытка не подтверждает приёмку.
- Возврат и отзыв прекращают конкретное решение, повторная приёмка не удваивает выпуск; исходные выпуски сохранены.
- Наборы и состояния сверены по ключам, отсутствующие решения не подменены нулём; частичный объём явно обозначен.
- Сохраняется lineage до попыток и доказательств. Смена политики оформлена через версию определения выпуска.
Это критерии проектной приёмки, не заявление о выполненных тестах. При нарушении условия показывают диагностику вместо окончательного знаменателя.
Вопросы для самопроверки#
- Почему три завершённые попытки могут давать один или ноль принятых результатов?
- В каком интервале учитывается повторная приёмка после отзыва по выбранному контракту?
- Почему неизвестный журнал решений нельзя заменить нулём даже при полной поставке попыток?
Task and scope#
Three completed processing attempts for one request do not mean three accepted results. The denominator of management unit costs must distinguish work performed, technical completion, and confirmed output. This article defines a proposed accepted-result contract, without staff assessment, complexity weights, cost allocation, or lab changes.
W3C PROV-DM, the 2013 Recommendation, distinguishes entities, activities, provenance, and responsibility. It provides a basis for describing links between a result, its processing, and its acceptance decision, but does not prescribe business quality criteria or a denominator formula. All inclusion rules below are proposed EDWH decisions, rather than IFRS, ISO, or database requirements. There is no SQL or Python code.
Grain and identity#
The result key (source_system, service_id, result_id) identifies one expected service outcome. The attempt key (source_system, attempt_id) identifies one execution of work. In this model, an attempt belongs to exactly one result, while a result may have multiple attempts. If a batch attempt produces multiple results, an explicit bridge describing the batch membership is needed first; counting joined rows directly is unsuitable.
Result content has a separate result_version. An acceptance decision with a unique decision_id references the exact result version, the supporting attempt, the criteria version, the accepting party's authority, and evidence of checks. A new attempt identifier or content version does not create another output unit. A new independent result is allowed only under the service definition, for example for a separate request, with a traceable basis for its identity.
The mart grain is service, legal entity, department, nonoverlapping business interval, output-definition version, source snapshot, and release_id. The unit is one accepted result, with no currency and no negative count in a snapshot. The monetary numerator separately retains its currency, scale, and signs. Check compatibility of scope and time with it using the unit-cost contract.
Criteria and times#
A criteria version contains verifiable conditions, service scope, an effective interval, an owner, and evidence of approval. For example, a synthetic service requires mandatory fields and a positive control assessment. A completed flag does not prove these conditions. Do not silently apply new criteria to old decisions: retain the original decision and a separate reassessment under the new version.
Distinguish the attempt's completed_at, the decision's accepted_at, the business time of a return or revocation, and observed_at, when the EDWH learned of the event. Timestamps have explicit time zones; the service calendar determines the inclusion date. In this model, acceptance cannot precede completion of the supporting attempt. Loading time does not replace acceptance time.
A release fixes two cutoffs: the business cutoff for state and the knowledge cutoff. An event affects it only if it falls within both. Order equal timestamps by the source's authoritative sequence; conflicting decisions without such an order block the result. A maximum timestamp alone is insufficient.
Rework and revocation#
The selected contract measures active accepted output: a result is included once if acceptance of its current version is effective at the business cutoff and its original first-acceptance date belongs to the selected interval. That date remains attached to the result after acceptance is repeated. This is not a count of acceptance events during the period.
| Event |
Result state |
Snapshot contribution |
| Attempt completed, checks failed |
Requires rework |
0 |
| Version acceptance confirmed |
Accepted |
1 if first acceptance falls in the interval |
| Returned after acceptance |
Requires rework, previous acceptance ended |
0 |
| New attempt and repeated acceptance |
Accepted with a new version |
At most 1, in the original interval |
| Acceptance revoked |
Acceptance invalid |
0 |
A return before first acceptance retains a zero contribution. A return after acceptance and a revocation are recorded as events with a reason and a reference to the decision being ended. Redelivery of the same event does not change state. A new content version cannot be treated as accepted under a decision for the previous version.
Synthetic example: result R has failed attempt A1 and accepted attempt A2 in January. In the January release based on information known then, R contributes 1 and there are 2 completed attempts. In February, acceptance is revoked and correction A3 is subsequently accepted. In a new snapshot before repeated acceptance, R contributes 0 to the January interval; afterwards, it contributes 1. No new February result arises. The original January release remains unchanged. Late knowledge of revocation changes a new recalculation, rather than the archived release.
An alternative is to count first acceptances as a historical flow without subtracting subsequent revocations, and report revocations separately. It answers how many were first accepted then, whereas the selected contract answers how many of those accepted then remain valid at the cutoff. Do not mix these measures. Recalculating the acceptance period requires checking compatibility with the monetary numerator, rather than automatically moving costs between months.
Reconciliation and coverage#
First reconcile expected results, attempts, and the decision log within the fixed scope. Every attempt has a known result; every acceptance decision has an existing completed attempt, an exact version, and evidence under the specified criteria. Missing decision logs mean unknown accepted volume, rather than zero.
At the cutoff, each result belongs to exactly one group: accepted, awaiting processing or acceptance, requiring rework, revoked, or unresolved. The sum of group counts equals the number of unique expected results. Reconcile the accepted set by key with effective decisions, then count unique results; joining multiple attempts must not multiply the contribution.
Separately retain counts of attempts, repeat attempts, and results requiring rework. Do not add attempts to results. Unknown criteria or result versions prevent the affected scope from being admitted as complete. A positive completion count does not prove completeness of accepted output. Apply weighting only after selecting the eligible set, preserving the distinction between results, attempts, and equivalents.
Admission criteria#
- The result unit, keys, and links to attempts and versions are defined; repeated work creates no additional unit.
- Each effective acceptance has a criteria version, authority, and evidence; the content version matches the accepted version.
- The calendar, both cutoffs, event order, and first-acceptance policy are fixed; an unfinished attempt cannot support acceptance.
- Returns and revocations end a specific decision, repeated acceptance does not double output, and original releases are preserved.
- Sets and states are reconciled by key, missing decisions are not replaced with zero, and partial volume is clearly identified.
- Lineage to attempts and evidence is retained. A policy change is recorded through an output-definition version.
These are project acceptance criteria, rather than a claim of completed tests. If a condition fails, show diagnostics instead of a final denominator.
Self-check questions#
- Why can three completed attempts yield one or zero accepted results?
- In which interval is repeated acceptance after revocation counted under the selected contract?
- Why cannot an unknown decision log be replaced with zero even when the attempt delivery is complete?