# Observability for Business Automations: Evidence Dossier

**Research snapshot:** October 10, 2026  
**Decision supported:** How can a team see that the expected result happened, not just that a job ran?  
**Perspective:** Decision-maker / operations-data lead choosing the minimum justified observability investment  
**Scope:** Public sources researched independently from scratch; bounded synthetic daily data-delivery process; no private systems or data. Synthetic fixtures and economics are labeled as such. One small deterministic test fixture was executed locally; no production integration, vendor test, notification delivery test, or autonomous repair was performed.

## Decision answer and uncertainty

The core recommendation is to **observe a business obligation, not an automation run**.

For each expected unit of work, create an independently knowable record of what should happen—for example, “the 2026-10-08 business-date export must result in a report showing 2026-10-08 data by 07:20 Europe/Prague.” Then collect evidence from the process stages and close that obligation only when an explicit outcome predicate is true.

That distinction matters because execution telemetry and business correctness are different things. OpenLineage defines `COMPLETE` as the point when execution of a job has concluded; it does not define that state as proof that the business result is correct. Google’s SRE guidance makes the same point from another direction: an HTTP request can return a nominally successful status while returning incorrect content, and detecting that class of failure requires an end-to-end observation of the result. citeturn20view2turn25view0

For the bounded daily data-delivery process in this dossier, the minimum useful model is:

> **Expected work → evidence → case → owner → verified resolution**

not:

> scheduler → job → green checkmark.

A practical implementation should therefore have five properties:

| Required property | What it means |
|---|---|
| **Independent expectation** | A batch/deadline exists even if the automation never starts. |
| **Outcome predicate** | “Done” means the correct business period is available, sufficiently complete and valid—not merely that code exited successfully. |
| **Case identity** | Every affected business batch remains individually identifiable even when notifications are grouped. |
| **Human ownership** | An alert has a named responder/escalation path; notification or acknowledgment is not treated as resolution. PagerDuty explicitly distinguishes acknowledgment (“someone is working on it”) from resolution. citeturn18view1 |
| **Re-verification** | Recovery closes a case only after the outcome checks pass again. |

For a small, low-risk process, this does **not** require buying an observability platform. A checklist plus a durable expectation register can implement the same conceptual model. As materiality, frequency, or out-of-hours operation increases, deterministic monitoring becomes attractive. AI should normally be added only after deterministic detection exists, primarily to summarize evidence or suggest diagnostic steps rather than decide whether the business obligation has been fulfilled. NIST's Generative AI Profile explicitly treats confidently false output and human over-reliance as AI risks; that weakens the case for making an LLM the authority that marks a business obligation resolved. citeturn20view6

The strongest evidence in this research supports the **architecture and failure distinctions**, not a universal ROI claim. Official platform specifications document execution states, freshness checks, data assertions, grouping, escalation and scheduler limitations. Google publishes substantial operational experience with noisy alerting. Schelter et al. provide empirical evaluation of large-scale automated data-quality verification. I did **not** find controlled evidence showing that a particular “business outcome observability” design reduces missed data deliveries or incident-resolution time by a universal percentage. Any ROI, alert-volume threshold or response-time target should therefore be measured locally rather than borrowed from a vendor benchmark. citeturn4view0turn25view3

The important uncertainties are consequently not “which observability vendor is best,” but whether the team can correctly specify the obligation in the first place:

| Uncertainty | Why it matters |
|---|---|
| Can the business outcome be expressed deterministically? | Some outcomes require semantic or human judgment. |
| Is the expected-work register genuinely independent? | If the same broken scheduler generates both the work and the monitoring expectation, a missing run can remain invisible. |
| Are reconciliation rules actually valid? | A wrong invariant can turn a deterministic monitor into a deterministic liar. |
| What constitutes an acceptable late/partial batch? | This is a business contract, not an infrastructure default. |
| What is the actual cost of missing a batch? | Without this, optimal monitoring investment cannot be calculated. |
| How much alert volume will exist in practice? | This determines whether AI triage or sophisticated correlation has any economic justification. |

There is no material Czech-versus-US difference in the central architecture. The concrete business calendar and time zone do matter. A Czech process should make `Europe/Prague` explicit; a US process should similarly use its actual IANA zone rather than depending on a machine's local clock. Kubernetes documents that an unspecified CronJob zone is interpreted according to the controller manager's local time zone, while explicit `.spec.timeZone` is supported; Apache Beam separately distinguishes event time from processing/system-clock time. citeturn19view4turn24view0

## Bounded process and simplest baseline

The process below is a **synthetic design**, not a report of an actual RadekDuha.cz, QuantumSpring.ai or customer workflow.

The recognizable process is a weekday data delivery:

**Purpose:** A business team needs yesterday's sales report before the working day begins.

**Synthetic contract:** For every expected business date `D`, a source export should arrive the following morning. It must be preserved, ingested, transformed and made available as a report whose `as_of_date = D` no later than **07:20 Europe/Prague**.

The concrete times below are proposed inputs, not universal good practice.

| Process element | Synthetic definition |
|---|---|
| Business unit of work | One `business_date` |
| Trigger | Presence of an expected date in a business-calendar register; source arrival may trigger processing, but does not create the expectation |
| Input | Export containing explicit `business_date` and records for that period |
| Primary owner | Data Operations / owner of the data product |
| Consumer | Business-report owner |
| Expected source arrival | 06:30 local |
| Preservation target | 06:35 |
| Ingestion target | 06:45 |
| Transformation target | 07:00 |
| Report deadline | 07:20 |
| Success | Required source preserved; reconciliation valid; critical data assertions pass; report `as_of_date` equals expected date; report available by deadline |
| Exceptions | Missing source, permissions, duplicate delivery/run, partial load, invalid data, stale partition, late report, notification failure, unresolved recovery |

The state machine is intentionally business-facing:

`EXPECTED → SOURCE_RECEIVED → PRESERVED → INGESTED → TRANSFORMED → PUBLISHED → VERIFIED_RESOLVED`

Exceptions do not need to be forced into this happy path. They can exist as parallel evidence/case states such as `SOURCE_LATE`, `RECONCILIATION_FAILED`, `STALE_REPORT`, `NOTIFICATION_FAILED`, `ACKNOWLEDGED`, and `RECOVERING`.

Crucially, `ACKNOWLEDGED` belongs to the **incident/case lifecycle**, not the business-delivery lifecycle. PagerDuty's documented behavior illustrates why: acknowledging an incident tells the system that somebody is working on it and stops escalation, but acknowledgment explicitly does not resolve the incident. citeturn18view1

OpenLineage makes another useful separation. A Job is the defined work, while a Run is one occurrence of it; the specification can attach a nominal scheduled time distinct from the actual execution time, identify input/output datasets and carry data-quality metrics or assertions. This is useful diagnostic context, but even OpenLineage's terminal `COMPLETE` state means execution concluded, not that an independently specified business obligation is satisfied. citeturn20view2turn23view3turn23view4

**The simplest manual/native baseline** needs no new monitoring product. Each business morning, the owner can follow one durable checklist:

| Check | Manual evidence |
|---|---|
| Is today's expected batch defined? | Business-calendar/checklist row exists |
| Did the correct export arrive? | File/object metadata shows expected business date |
| Was that exact input preserved? | Archive entry plus filename/checksum or immutable object ID |
| Did the warehouse receive the intended period? | SQL query by `business_date`, not merely total table row count |
| Did reconciliation pass? | Explicit relationship, e.g. `source_rows = target_rows + explained_rejects` where that equation is valid |
| Did critical business assertions pass? | SQL checks, e.g. duplicate keys, forbidden nulls, invalid statuses or domain-specific aggregate controls |
| Is the report current? | Open/report metadata and verify `as_of_date = expected business_date` |
| Is it on time? | Availability timestamp ≤ declared deadline |
| If not, who owns it? | Case row or ticket with owner |
| Can the row be closed? | Only after the same outcome checks pass |

This baseline is deliberately less glamorous than “AI observability,” but it tests whether the team actually knows what success means. Google SRE reports that monitoring itself can become fragile and burdensome when overly complex and recommends simple, comprehensible rules on the critical alert path. citeturn25view2

Before automating the process, the decision-maker should therefore separate **process redesign from implementation technology**.

| Intervention | Decision question | Why it comes before more tooling |
|---|---|---|
| Remove | Does anybody make a decision from this report? | An unused report does not deserve an automated reliability stack. |
| Clarify | Which business date, deadline and owner define success? | Otherwise “fresh” and “done” have no stable meaning. |
| Standardize | Can every source/report carry the same stable `business_date` or batch identity? | Correlation and reconciliation become deterministic. |
| Simplify | Can a transformation or handoff be eliminated? | Every stage adds another partial-failure and ownership boundary. |
| Automate | Which deterministic checks replace manual inspection? | Automation is now implementing an already specified contract. |
| Add AI | Is remaining diagnostic work frequent and unstructured enough to justify it? | AI should solve residual triage work, not compensate for an undefined process. |

The “remove/clarify/standardize first” sequence is an **editorial architecture recommendation**, not the result of a controlled experiment. Its evidentiary support is indirect: Google describes monitoring complexity as a maintenance burden, while the Schelter et al. data-quality work is built around users first declaring constraints that valid data should satisfy. citeturn25view2turn4view0

## Evidence synthesis and design choices

The most important design move is to maintain an **expected-work register that is created independently of the workflow being monitored**.

For a daily batch system, one row can be generated from the business calendar several days or weeks ahead:

```text
process_id          daily-sales-report
business_date       2026-10-08
timezone            Europe/Prague
due_at_utc           2026-10-09T05:20:00Z
owner                data-operations
required_outcome     sales-report-v1
```

The monitor then asks an anti-join question:

> Which obligations are due, but have no matching verified outcome?

That catches the otherwise awkward case where **nothing happened at all**. A monitor that only reacts to workflow events has no event to consume when a run is never created.

This is particularly important because schedulers themselves do not offer an absolute “exactly one job exists for every business obligation” guarantee. Kubernetes documents that CronJobs may under some circumstances create two Jobs or no Job at all and consequently recommends idempotent Jobs; it also documents missed-schedule behavior and explicit time-zone handling. citeturn19view2turn20view0

The expected-work mechanism needs its own watchdog. Otherwise a broken calendar-generation process can remove the very expectations that would reveal missing batches. A simple deterministic invariant such as “the expected-work table always covers the next ten business days” is enough; **ten days is a proposed local threshold, not an evidence-based universal value**.

**Outcome monitoring should use independent dimensions, not one proxy.** A row count is useful evidence but not proof by itself. Schelter et al.'s data-verification work explicitly motivates checking constraints such as missing values, duplicates, size anomalies and other properties of data rather than assuming that successful ingestion implies valid downstream data. dbt similarly defines data tests as assertions whose failing SQL rows disprove the assertion and supports organization-specific business logic. citeturn4view0turn19view0

A good daily outcome predicate might therefore be:

```text
outcome_ok(D) =
    expected(D)
AND source_received(D)
AND source_preserved(D)
AND reconciliation_valid(D)
AND critical_assertions_pass(D)
AND report_as_of_date = D
AND report_available_at <= deadline(D)
```

The exact reconciliation term is process-specific. `source_rows = target_rows` is often **not** an appropriate universal invariant because legitimate filtering, deduplication or aggregation may change the count. In the worked synthetic example below, the explicitly defined equation is:

```text
source_rows = target_rows + explained_rejected_rows
```

A different process might reconcile monetary totals, unique business keys, control totals or counts by category instead. dbt's data-test model supports arbitrary SQL assertions, while OpenLineage can carry dataset quality metrics and test results as lineage metadata. citeturn19view0turn23view4

**Freshness is necessary but weaker than correctness.** dbt's current documentation allows freshness thresholds to be declared for sources and models, with explicit `warn_after`, `error_after`, loading timestamp fields or queries. That is useful evidence that new data has appeared. It still does not establish that the correct business period, complete batch and correct report are present; those require additional assertions. citeturn20view1

The distinction becomes especially important where a system can update a timestamp while carrying stale or partial business data. Google SRE's analogous example is a request returning an HTTP success code together with wrong content: protocol success is not outcome success, and end-to-end observation is needed to catch it. citeturn25view1

**Time must have at least two meanings.** Apache Beam formally distinguishes event time—the time attached to the data—from processing time—the system clock when the data is processed. It also documents the inherent trade-off among latency, completeness and processing cost when deciding when results should be emitted. citeturn24view0turn24view1

For a business batch that translates into:

```text
business/event time: 2026-10-08
source arrival time: 2026-10-09 06:22 Europe/Prague
processing time:     2026-10-09 06:28 Europe/Prague
report available:    2026-10-09 07:10 Europe/Prague
deadline:            2026-10-09 07:20 Europe/Prague
```

A pipeline that ran at 06:28 on October 9 tells you nothing by itself about whether it processed October 8, October 7, or an incomplete mixture. The business date must remain first-class throughout the lineage.

**Lineage is diagnostic evidence, not the verdict.** OpenLineage can correlate runs with input/output datasets, scheduled versus actual timing, output statistics and data-quality facets. That materially helps answer “which source and transformation produced this stale report?” But because its `COMPLETE` state refers to execution, lineage does not replace an outcome contract. citeturn20view2turn23view3

**Notifications should be grouped; affected cases should not be erased.** Prometheus Alertmanager explicitly supports grouping similar alerts into one notification while retaining visibility into the individual affected instances. That is the right mental model for business automations: reduce notification volume at the transport layer while preserving one durable case identity for every affected business batch. citeturn18view0

For example:

```text
case_id:
daily-sales-report|2026-10-07|stale_report_period
daily-sales-report|2026-10-08|stale_report_period

notification group:
daily-sales-report|stale_report_period
```

The operator may receive one concise notification that says **“2 batches affected”**, but the underlying case store still knows that October 7 and October 8 each require reconciliation and closure.

This is safer than naïvely deduplicating on only `alert_name = report_stale`, which can turn a continuing symptom into one long-lived alert and hide the fact that a second business obligation has now failed. Prometheus's design deliberately distinguishes grouping from the underlying alerts; its documented example groups many instances while allowing the recipient to see precisely which instances are affected. citeturn18view0

**Alert receipt is not business resolution.** PagerDuty's lifecycle is useful evidence here: acknowledgment means a responder is working on an incident and stops further escalation, but it does not resolve it. citeturn18view1

A business-automation case should therefore distinguish:

`OPEN → NOTIFICATION_ATTEMPTED → ACKNOWLEDGED → RECOVERING → VERIFIED_RESOLVED`

and separately record notification-transport evidence:

```text
notification_attempted_at
notification_provider_accepted_at
notification_delivery_receipt_at   # where technically available
human_acknowledged_at
business_outcome_reverified_at
```

None of the first four timestamps is a substitute for the last one.

This also answers the draft alert-fatigue claim target:

> **“Automatizace posílá tolik upozornění, že je nikdo nečte.”**

As written, **“nobody reads them” is too absolute and should be rewritten**. Google reports that excessive paging caused people to skim or ignore alerts and, in its Bigtable case study, that high alert volume consumed engineering effort and obscured the comparatively few issues that actually affected users. But this is reported operational practice from Google, not a controlled estimate that all teams stop reading notifications above some threshold. citeturn20view4turn25view4

A defensible version is:

> **High-volume, non-actionable alerts can cause operators to skim or ignore notifications and can obscure real problems. Keep notifications tied to an actionable business case; group related notifications without deleting the identity of each affected case.**

Google explicitly argues that human pages should be actionable and simple, and its Bigtable case reports reducing noisy alerting so engineers could focus on actual problems. Prometheus provides a concrete mechanism for grouping while retaining affected instances. citeturn25view3turn18view0

The comparison among observability investments therefore looks like this:

| Approach | What proves completion? | Strength | Principal weakness | Upkeep | Appropriate when |
|---|---|---|---|---|---|
| **Manual/native checklist** | Person inspects source, warehouse and report and records closure | Very low setup; forces process clarity | Human omission, absence, holidays, out-of-hours operation; weak at scale | Daily human effort plus checklist maintenance | Few low-risk processes |
| **Deterministic outcome monitoring** | Expected-work anti-join + explicit invariants + report-period/deadline checks | Detects silence and reproducible wrong states; auditable | Checks can themselves become stale or wrong | Schema/calendar/rule/ownership maintenance | Default for material repeatable automation |
| **AI triage after deterministic detection** | Same deterministic outcome predicate; AI only explains evidence | Can summarize logs/lineage and suggest next actions | Confabulation, automation bias, variable output, additional cost/governance | Prompts/models/evaluation plus deterministic system | High enough case volume or diagnostic complexity to justify it |

The first two approaches change **detection**. The third mostly changes **diagnosis**. The NIST risk profile is a reason to preserve that separation rather than allowing an LLM-generated “looks fixed” message to become the authoritative resolved state. citeturn20view6

Lifecycle reliability also changes what must be observable:

| Failure mode | What should be visible | Recovery evidence |
|---|---|---|
| Permission/credential failure | Missing/read/write step plus exact affected batch | Credential restored **and** outcome predicate re-run |
| Retry | Multiple run IDs tied to same business batch | One verified outcome; retries remain diagnostic history |
| Duplicate run/delivery | More than one run/input for same expected batch | Declared canonical input/output and reconciliation |
| Partial transformation | Failing reconciliation or critical assertion | Corrected output passes assertions |
| Stale state | `report_as_of_date ≠ expected business_date` | Correct period visible downstream |
| Scheduler never runs | Due expected-work row with no matching evidence | Batch processed and verified |
| Notification transport fails | Open case exists but delivery canary/receipt missing | Alternate route works; case still independently visible |
| Handover gap | Unresolved case has no current owner | New accountable owner explicitly assigned |
| Recovery fails | Case remains open after retry | No closure until output checks pass |
| Monitoring becomes stale | Expectation horizon, checks or schema no longer match process | Monitor contract revised and synthetic tests pass |

Scheduler retry/idempotency is adjacent rather than central here, but it cannot be ignored entirely: Kubernetes's CronJob documentation is explicit that duplicate or missing job creation can occur, which is one reason the business-date case ID should not simply equal an orchestration run ID. citeturn19view2

## Worked failure, alert-to-action inventory, and portable assets

**Worked example — synthetic, not a customer result.**

Assume the process has been green for October 6.

For business date **October 7**, the source export never arrives. A poorly designed workflow nevertheless runs a generic “latest data” transformation and republishes the previous report. The scheduler is green. The downstream page is reachable. Its content still says `as_of_date = 2026-10-06`.

That is precisely the family of failure for which execution success is inadequate: Google notes that systems can explicitly report success while serving wrong content. citeturn25view1

The independent expected-work row says October 7 was due. The outcome monitor opens two cases:

```text
daily-sales-report|2026-10-07|missing_source
daily-sales-report|2026-10-07|stale_report_period
```

On **October 8**, a new export arrives. The transformation runs green, but ten records are neither loaded nor registered as rejected, a critical data assertion fails, and the report still says October 7. The monitor opens:

```text
daily-sales-report|2026-10-08|row_reconciliation_failed
daily-sales-report|2026-10-08|critical_data_test_failed
daily-sales-report|2026-10-08|stale_report_period
```

There are now **two separate stale-report cases**, one for each business date:

```text
daily-sales-report|2026-10-07|stale_report_period
daily-sales-report|2026-10-08|stale_report_period
```

The notification layer may group those as:

```text
daily-sales-report|stale_report_period
affected_batches = [2026-10-07, 2026-10-08]
```

That reduces interruption while preserving two obligations. This is consistent with Alertmanager's documented grouping model. citeturn18view0

Now add a third failure: the primary Slack/email/webhook transport is unavailable. The delivery cases still exist in the durable case store. A transport watchdog observes that open cases lack expected notification evidence and uses a **different failure path**—for example a secondary paging provider or manual open-case dashboard. A canary through the primary route can detect transport breakage, but even a canary only proves the tested transport path; it cannot prove that a human understood or resolved the incident. This limitation is why the durable case ledger, rather than the chat message, should be the system of record.

The responder eventually restores the missing October 7 input and reprocesses both days. Clicking “acknowledge” does not close either case. Each case closes only after its business-date predicate is re-evaluated and passes. That separation mirrors PagerDuty's documented acknowledgment-versus-resolution distinction. citeturn18view1

**Alert-to-action inventory — proposed design.** Every time threshold below is synthetic and should be negotiated from business impact rather than adopted as a universal standard.

| Condition | Detection independent of job? | Case identity | First owner | Action | Escalation | Resolved only when |
|---|---:|---|---|---|---|---|
| Expected source missing at 06:30 | Yes | process + date + `missing_source` | Data Ops | Check upstream/export availability | Backup/owner if still missing near deadline | Correct source for date exists and is preserved |
| Source arrived but not preserved | Yes | process + date + `source_not_preserved` | Data Ops | Restore archive/write permissions or preservation | Data platform owner | Preserved object + identity/checksum evidence exists |
| Reconciliation fails | Yes | process + date + invariant | Data owner | Identify rejects/duplicates/partial load | Data product owner | Declared reconciliation equation passes |
| Critical data assertion fails | Yes | process + date + assertion | Data owner | Inspect failing records | Domain owner where semantic decision needed | Critical assertion passes or controlled exception is documented |
| Report has wrong business date | Yes | process + date + `stale_report_period` | Report/data owner | Trace source → model → publish step | Business-report owner near deadline | Published report states expected date |
| Report absent after 07:20 | Yes | process + date + `deadline_missed` | Data Ops | Restore/report publish | Responsible leader based on materiality | Report available and all critical predicates pass |
| Notification transport canary missing | Yes, if canary/checker is separate | transport + canary window | Platform/on-call | Check notification route; use alternate path | Secondary contact channel | Canary path works again and missed open cases reviewed |
| Case acknowledged but still unresolved | Yes | original case | Current responder | Continue repair or reassign | Backup/manager after local response target | Business predicate passes, not merely another acknowledgment |

Google's operational guidance supports keeping human-facing alerts actionable rather than paging on every unusual internal signal; its reported Bigtable experience is also counterevidence to the idea that “more alerts equals more safety.” citeturn25view3turn25view4

**Silent-failure checks — proposed minimum set:**

1. **Expected-work anti-join:** due obligation has no verified outcome.
2. **Expectation-horizon watchdog:** future expected rows have stopped being generated.
3. **Business-period check:** report/data period equals the obligation's period.
4. **Reconciliation check:** declared business control equation balances.
5. **Critical assertion check:** domain invariants return no failing records.
6. **Unresolved-case watchdog:** an acknowledged/recovering case remains open beyond its locally chosen response target.
7. **Notification-path canary:** a known synthetic event traverses the delivery path, with an independent checker for missing receipt.

dbt's current data-test model directly supports SQL assertions and storing failing rows for diagnosis, while its freshness configuration can provide a distinct age check. citeturn19view1turn20view1

**Resolved-case criteria — recommended contract:**

```text
A case is VERIFIED_RESOLVED only if:

1. the originally affected expected batch still exists in the obligation register;
2. all mandatory evidence for that exact business_date has been refreshed;
3. the failed invariant now passes;
4. all other critical outcome invariants pass;
5. the downstream report has the expected business period;
6. recovery did not create a new unresolved duplicate/partial batch;
7. resolution time and recovery action are recorded.

Notification accepted      != resolved
Notification delivered     != resolved
Human acknowledged         != resolved
Retry succeeded            != resolved
Job COMPLETE               != resolved
Business predicate passes  == eligible for VERIFIED_RESOLVED
```

That final distinction is an architectural interpretation of the documented differences among run completion, notification acknowledgment and end-to-end correctness. citeturn20view2turn18view1turn25view1

**Portable SQL asset — synthetic reference schema and missing-outcome check.** This is deliberately simple SQL and will require minor type/DDL adjustments across warehouses. Deadline UTC values are assumed to have been generated from the authoritative business calendar so that the SQL does not depend on the warehouse session's local timezone.

```sql
-- Synthetic reference asset.
-- Not executed against a real warehouse.

create table expected_delivery (
    process_id       varchar(200) not null,
    business_date    date         not null,
    timezone_name    varchar(100) not null,
    due_at_utc       timestamp    not null,
    owner_id         varchar(200) not null,
    contract_version varchar(50)  not null,
    primary key (process_id, business_date)
);

create table delivery_evidence (
    process_id               varchar(200) not null,
    business_date            date         not null,
    source_received          boolean      not null,
    source_preserved         boolean      not null,
    source_rows              bigint,
    target_rows              bigint,
    explained_rejected_rows  bigint,
    critical_test_failures   bigint,
    report_as_of_date        date,
    report_available_at_utc  timestamp,
    observed_at_utc          timestamp    not null,
    primary key (process_id, business_date)
);

create table delivery_case (
    case_id            varchar(500) not null primary key,
    process_id         varchar(200) not null,
    business_date      date         not null,
    invariant_name     varchar(200) not null,
    case_status        varchar(50)  not null,
    owner_id           varchar(200),
    opened_at_utc      timestamp    not null,
    acknowledged_at_utc timestamp,
    verified_at_utc    timestamp,
    resolved_at_utc    timestamp
);

-- Independent deadline check:
-- a scheduler/job record is intentionally NOT part of the success condition.

select
    e.process_id,
    e.business_date,
    e.due_at_utc,
    e.owner_id,
    case
        when d.business_date is null
            then 'NO_EVIDENCE'
        when not d.source_received
            then 'MISSING_SOURCE'
        when not d.source_preserved
            then 'SOURCE_NOT_PRESERVED'
        when d.source_rows <>
             d.target_rows + d.explained_rejected_rows
            then 'ROW_RECONCILIATION_FAILED'
        when d.critical_test_failures <> 0
            then 'CRITICAL_DATA_TEST_FAILED'
        when d.report_as_of_date <> e.business_date
            then 'STALE_REPORT_PERIOD'
        when d.report_available_at_utc > e.due_at_utc
            then 'REPORT_LATE'
        else 'VERIFIED_OK'
    end as outcome_status
from expected_delivery e
left join delivery_evidence d
  on d.process_id = e.process_id
 and d.business_date = e.business_date
where e.due_at_utc <= current_timestamp;
```

The ordering in that `CASE` is useful for a concise headline but should **not** be used to discard additional concurrent failures. Production logic should emit all violated invariants as separate cases, as the executable fixture below does.

**Portable synthetic fixture and evaluator — actually executed locally.**

The following is the complete standard-library Python asset used for the worked test. No external APIs, private data or production systems were accessed.

```python
from datetime import datetime
from zoneinfo import ZoneInfo

fixtures = [
    {
        "business_date": "2026-10-06",
        "deadline_local": "2026-10-07T07:20:00",
        "source_received": True,
        "archived": True,
        "source_rows": 1000,
        "target_rows": 995,
        "rejected_rows": 5,
        "critical_test_failures": 0,
        "report_as_of": "2026-10-06",
        "report_published_local": "2026-10-07T07:12:00",
    },
    {
        "business_date": "2026-10-07",
        "deadline_local": "2026-10-08T07:20:00",
        "source_received": False,
        "archived": False,
        "source_rows": 0,
        "target_rows": 0,
        "rejected_rows": 0,
        "critical_test_failures": 0,
        "report_as_of": "2026-10-06",  # stale previous report
        "report_published_local": "2026-10-08T07:05:00",
    },
    {
        "business_date": "2026-10-08",
        "deadline_local": "2026-10-09T07:20:00",
        "source_received": True,
        "archived": True,
        "source_rows": 1200,
        "target_rows": 1180,
        "rejected_rows": 10,  # 10 rows remain unexplained
        "critical_test_failures": 1,
        "report_as_of": "2026-10-07",  # stale
        "report_published_local": "2026-10-09T07:10:00",
    },
]


def evaluate(batch: dict) -> list[str]:
    reasons: list[str] = []

    if not batch["source_received"]:
        reasons.append("missing_source")

    if batch["source_received"] and not batch["archived"]:
        reasons.append("source_not_preserved")

    if batch["source_rows"] != batch["target_rows"] + batch["rejected_rows"]:
        reasons.append("row_reconciliation_failed")

    if batch["critical_test_failures"] != 0:
        reasons.append("critical_data_test_failed")

    if batch["report_as_of"] != batch["business_date"]:
        reasons.append("stale_report_period")

    tz = ZoneInfo("Europe/Prague")
    published = datetime.fromisoformat(
        batch["report_published_local"]
    ).replace(tzinfo=tz)
    deadline = datetime.fromisoformat(
        batch["deadline_local"]
    ).replace(tzinfo=tz)

    if published > deadline:
        reasons.append("report_late")

    return reasons


results = {
    batch["business_date"]: evaluate(batch)
    for batch in fixtures
}

cases = [
    {
        "case_id": (
            f"daily-sales-report|"
            f"{batch['business_date']}|"
            f"{reason}"
        ),
        # Excludes business_date intentionally so notifications
        # for the same symptom may be grouped.
        "group_key": f"daily-sales-report|{reason}",
        "business_date": batch["business_date"],
        "reason": reason,
    }
    for batch in fixtures
    for reason in evaluate(batch)
]

print(results)

print([
    case
    for case in cases
    if case["reason"] == "stale_report_period"
])
```

**Executed result:**

```text
{
  '2026-10-06': [],
  '2026-10-07': [
    'missing_source',
    'stale_report_period'
  ],
  '2026-10-08': [
    'row_reconciliation_failed',
    'critical_data_test_failed',
    'stale_report_period'
  ]
}
```

The stale-report cases remain separately addressable:

```text
[
  {
    'case_id':
      'daily-sales-report|2026-10-07|stale_report_period',
    'group_key':
      'daily-sales-report|stale_report_period',
    'business_date': '2026-10-07',
    'reason': 'stale_report_period'
  },
  {
    'case_id':
      'daily-sales-report|2026-10-08|stale_report_period',
    'group_key':
      'daily-sales-report|stale_report_period',
    'business_date': '2026-10-08',
    'reason': 'stale_report_period'
  }
]
```

**Test status:** the evaluator was executed successfully against the three synthetic fixtures. It was **not** tested against dbt, Kubernetes, OpenLineage, Prometheus, PagerDuty, Slack, email, a warehouse, a source exporter or an actual BI report. The notification-canary design and SQL asset above remain **unperformed architecture examples**, not validated integrations.

## Economics and decision criteria

The economics below are deliberately synthetic. They are designed to expose the decision variables rather than claim a market wage, customer ROI or incident improvement.

Assume:

```text
D  = 250 business days/year
m  = 8 manual-check minutes/day

S  = 24 hours deterministic-monitor setup
u  = 1 hour deterministic-monitor upkeep/month
N  = 24 actionable cases/year
a  = 4 minutes handling overhead/case

Illustrative labor values only:
USD_rate = $80/hour
CZK_rate = CZK 1,500/hour
```

Neither labor rate is intended as a Czech or US market benchmark.

Manual effort:

\[
H_{manual}=D\times m/60
\]

\[
=250\times8/60=33.33\text{ hours/year}
\]

Deterministic monitoring, first year:

\[
H_{det,1}=S+(12\times u)+(N\times a/60)
\]

\[
=24+12+(24\times4/60)=37.6\text{ hours}
\]

Steady state, excluding initial setup:

\[
H_{det,steady}=12+(24\times4/60)=13.6\text{ hours/year}
\]

| Synthetic option | First-year hours | Steady-state hours | At synthetic $80/h | At synthetic CZK 1,500/h |
|---|---:|---:|---:|---:|
| Manual checklist | 33.33 | 33.33 | $2,667/year | CZK 50,000/year |
| Deterministic monitoring | 37.60 | 13.60 | $3,008 first year; $1,088 steady | CZK 56,400 first year; CZK 20,400 steady |

On **labor alone**, deterministic monitoring loses slightly in year one under these assumptions. That is an important counterweight to “automate everything.”

The first-year labor break-even manual-check duration is:

\[
m_{break-even,1}
=\frac{37.6\times60}{250}
=9.024\text{ minutes/day}
\]

The steady-state break-even is:

\[
m_{break-even,steady}
=\frac{13.6\times60}{250}
=3.264\text{ minutes/day}
\]

So under this synthetic model, a process needing only four minutes of manual verification each day may not justify a 24-hour monitoring build on year-one labor economics. A process needing twelve minutes does.

That calculation deliberately omits the most important unknown: **the expected cost of a silent wrong result**.

A fuller decision equation is:

\[
\text{Net Value}
=
\text{manual effort avoided}
+
\text{expected missed-outcome exposure avoided}
-
\text{setup}
-
\text{maintenance}
-
\text{tooling}
-
\text{new alert handling}
\]

The research does not provide a defensible general value for “missed-outcome exposure avoided,” so it should remain an explicit local variable rather than be filled with invented precision.

Under the illustrative labor assumptions, deterministic monitoring costs about **$341 more** than manual checks in year one:

\[
\$3,008-\$2,667=\$341
\]

or **CZK 6,400 more**:

\[
56,400-50,000=6,400
\]

If the organization's measured reduction in expected silent-failure exposure is worth substantially more than that plus software costs, first-year economics can still favor deterministic monitoring. That is a decision model, **not evidence that the monitor actually produces that reduction**.

The case for AI triage is weaker at low volume.

Suppose AI adds, synthetically:

```text
12 hours setup
0.5 hours/month upkeep = 6 hours/year
API/vendor cost = excluded from calculation
human review remains mandatory
```

If it saves `s` minutes of human diagnostic work per case, its labor-only break-even incident volume is:

\[
N_{break-even}
=
\frac{(12+6)\times60}{s}
\]

| Assumed triage saving per case | Required cases/year to recover 18 hours |
|---:|---:|
| 5 minutes | 216 |
| 10 minutes | 108 |
| 15 minutes | 72 |

These are synthetic sensitivities, not observed AI productivity effects. They show why “add an AI incident agent” is not automatically the minimum investment for a process that generates two meaningful exceptions per month. NIST's documented confabulation and human-overreliance risks add governance cost that is not even included in those numbers. citeturn20view6

A sensible **rollout ladder** is therefore:

| Stage | Proposed go criterion | Proposed stop/no-go criterion |
|---|---|---|
| Manual contract | Owner, expected work, deadline and outcome predicate can be written unambiguously | Team cannot agree what “done” means |
| Deterministic shadow monitoring | Synthetic missing/stale/partial cases are all caught and case identity is preserved | Monitor derives its expectation from the same workflow it monitors, or false cases remain unacceptably high |
| Deterministic primary monitoring | Real operating period shows manageable review burden; reconciliation proves useful | Maintenance costs exceed justified risk/effort for a low-materiality process |
| AI-assisted triage | Measured case volume and diagnostic time produce a plausible break-even; deterministic closure remains authoritative | AI creates material factual errors, fails measured time-saving target, or begins influencing closure without independent validation |

The exact pilot duration and thresholds should be chosen locally. As a **proposed starting experiment**, not a standard, I would run the deterministic checks in shadow mode across at least one complete calendar cycle that includes weekends/holidays relevant to the process, inject the failure fixtures above, and require zero synthetic failures to be silently classified as `VERIFIED_OK`.

My decision recommendation is stronger than a generic “observe more”:

**For any automation whose silent wrong result matters, fund the expected-work register and deterministic outcome predicate before funding generalized observability or AI triage.** The leverage comes from making the business obligation machine-checkable. Logs, traces, lineage and AI become much more valuable once there is an authoritative answer to “what failed?”

## Claim-to-source dossier

The table below distinguishes provider documentation, reported operational practice, empirical research, risk guidance and this dossier's interpretations. “Supported” means the cited source directly supports the bounded claim—not that it proves the entire architecture or a causal business outcome.

| Claim / draft target | Primary source and exact scope | Source date | Inspected | Evidence type | Status | Editorial advice |
|---|---|---|---|---|---|---|
| A successful technical execution does not prove the correct business result. | Google SRE, **“The Four Golden Signals → Errors”**: explicit vs implicit failures, including successful protocol response with wrong content; says end-to-end tests are needed for wrong-content cases. https://sre.google/sre-book/monitoring-distributed-systems/ citeturn25view0turn25view1 | 2016 book chapter; current web edition | 2026-10-10 | Primary company operational guidance | **Supported**, by analogy to business automation | **Keep**, phrased as design principle rather than causal empirical claim |
| OpenLineage `COMPLETE` is execution completion, not proof of business correctness. | OpenLineage v1.53.0, **“The Run Cycle → Run States”**: `COMPLETE` signifies execution concluded. https://openlineage.io/docs/spec/run-cycle/ citeturn20view2 | v1.53.0; page date not stated | 2026-10-10 | Open specification/documented behavior | **Supported** | **Keep** |
| Expected schedule/business time should be distinct from actual run time. | OpenLineage **Object Model → Run Facets**, `nominalTime`; Apache Beam **§8.4 Watermarks and late data**, event time vs processing time. https://openlineage.io/docs/spec/object-model/ ; https://beam.apache.org/documentation/programming-guide/ citeturn23view3turn24view0 | OpenLineage v1.53.0; Beam current docs, dates not stated | 2026-10-10 | Specification + official framework docs | **Supported** | **Keep** |
| Schedulers can miss or duplicate execution, so expected business work should not be inferred only from run records. | Kubernetes **“CronJob limitations → Job creation”** documents circumstances in which two Jobs or no Job may be created and recommends idempotent Jobs. https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ citeturn19view2turn20view0 | 2026-05-13 page revision | 2026-10-10 | Official platform documentation | **Supported for Kubernetes; architecture extrapolation conditional** | **Qualify**: use as a concrete scheduler example, not a claim about every scheduler |
| Freshness can be checked independently from a transformation's exit status. | dbt Developer Hub, **`freshness` configuration**: source/model freshness, warning/error ages, loaded timestamp field/query. https://docs.getdbt.com/reference/resource-configs/freshness citeturn20view1turn23view0 | 2026-09-16 | 2026-10-10 | Provider documentation | **Supported** | **Keep**, but state freshness ≠ complete correctness |
| Deterministic business/data assertions can return the exact records that violate an assumption. | dbt Developer Hub, **“Add data tests to your DAG → Overview / Add context to failing rows”**. https://docs.getdbt.com/docs/build/data-tests citeturn19view0turn19view1 | 2026-09-16 | 2026-10-10 | Provider documentation | **Supported** | **Keep** |
| Automated data-quality verification can enforce declared constraints and detect classes such as missing values, duplicates and abnormal data properties. | Schelter et al., **“Automating Large-Scale Data Quality Verification,” Introduction / system design / evaluation**, PVLDB 11(12). DOI: https://doi.org/10.14778/3229863.3229867 ; PDF: https://www.vldb.org/pvldb/vol11/p1781-schelter.pdf citeturn4view0 | 2018 | 2026-10-10 | Peer-reviewed research paper with experimental evaluation | **Supported** | **Keep**, but do not transform system evaluation into a claimed incident/ROI effect |
| Lineage can correlate a run with input/output datasets and quality evidence. | OpenLineage **“Object Model → Run / Dataset Facets”**: run IDs, nominal time, input/output datasets, quality metrics/assertions and output statistics. https://openlineage.io/docs/spec/object-model/ citeturn23view3turn23view4 | v1.53.0; date not stated | 2026-10-10 | Open specification | **Supported as feature/design capability** | **Keep**; qualify that lineage does not itself prove the outcome |
| Similar alerts can be grouped without losing visibility into distinct affected instances. | Prometheus **“Alertmanager → Grouping”**: groups similar alerts into one notification while example retains visibility of exact affected service instances. https://prometheus.io/docs/alerting/latest/alertmanager/ citeturn18view0 | Current docs; revision date not visible | 2026-10-10 | Official platform documentation | **Supported** | **Keep**; this is the strongest direct support for “group notification, preserve cases” |
| Acknowledgment is not resolution. | PagerDuty **“What Acknowledgment Does”**: acknowledgment signals someone is working, halts escalation, but does not resolve the incident. https://support.pagerduty.com/main/docs/escalation-policies citeturn18view1 | Page reported “Updated 2 months ago” as inspected; exact day unavailable | 2026-10-10 | Provider documentation | **Supported** | **Keep** and generalize carefully to business-case lifecycle |
| An alert should have an owner/escalation path rather than merely being emitted. | PagerDuty **“The Incident Lifecycle Through a Policy”** documents ordered escalation until action/acknowledgment; Google SRE asks whether an alert is urgent/actionable and whether someone can take action. https://support.pagerduty.com/main/docs/escalation-policies ; https://sre.google/sre-book/monitoring-distributed-systems/ citeturn18view1turn25view3 | PagerDuty ~2026-08; Google SRE 2016 book | 2026-10-10 | Provider behavior + primary-company practice | **Supported as design guidance** | **Keep**, not as proof of a universal response-time threshold |
| “Automations send so many alerts that nobody reads them.” | Google SRE reports frequent pages may be skimmed/ignored and its Bigtable case says high-volume alerting consumed engineering time and obscured real user problems. https://sre.google/sre-book/monitoring-distributed-systems/ citeturn20view4turn25view4 | 2016 book chapter | 2026-10-10 | Attributable operational practice / case report, not controlled experiment | **Absolute wording unsupported; underlying risk supported** | **Rewrite** to “High-volume, non-actionable alerting can cause operators to skim or ignore alerts and obscure important cases.” |
| Human-facing monitoring should favor actionable signals over noisy internal symptoms. | Google SRE **“Tying These Principles Together”** and **Bigtable case**. https://sre.google/sre-book/monitoring-distributed-systems/ citeturn25view3turn25view4 | 2016 book chapter | 2026-10-10 | Reported practice / expert guidance | **Supported as Google practice; external generalizability conditional** | **Qualify** rather than present as universal empirical law |
| Monitoring itself creates maintenance cost. | Google SRE **“Setting Reasonable Expectations for Monitoring”** reports substantial monitoring engineering responsibility and later recommends simplicity because monitoring can become fragile and burdensome. https://sre.google/sre-book/monitoring-distributed-systems/ citeturn20view4turn25view2 | 2016 book chapter | 2026-10-10 | Primary company practice | **Supported** | **Keep**, but do not extrapolate Google's staffing ratios to small companies |
| AI should not be the sole authority for factual incident closure. | NIST AI 600-1 **GAI Risks → Confabulation / Human-AI Configuration** identifies confidently erroneous content and over-reliance risks. DOI: https://doi.org/10.6028/NIST.AI.600-1 ; PDF: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf citeturn20view6 | 2024-07 | 2026-10-10 | Government risk-management guidance | **Supports risk premise; closure recommendation is interpretation** | **Keep as qualified architecture recommendation**, not evidence that AI triage fails operationally |
| Deterministic monitoring necessarily produces positive ROI. | No primary evidence located that supports a universal ROI for this bounded process. | — | 2026-10-10 | Evidence gap | **Unresolved / unsupported** | **Remove universal ROI language**; use local formulas and measured inputs |
| AI triage necessarily reduces incident resolution time. | No controlled evidence located in this research demonstrating that effect for the bounded daily data-delivery process. | — | 2026-10-10 | Evidence gap | **Unresolved** | **Do not claim** without a measured pilot |
| A transport receipt proves the problem was handled. | PagerDuty's explicit acknowledgment/resolution distinction already shows an intermediate response state is not resolution; no primary evidence supports equating transport delivery with business recovery. citeturn18view1 | Current provider docs | 2026-10-10 | Documented lifecycle plus inference | **Contradicted as a closure rule** | **Remove**; store receipt separately from verified resolution |

A source-quality qualification matters here. Most operational alerting evidence in this dossier is **documentation or attributable company practice**, not randomized or quasi-experimental research. The Schelter paper is stronger empirical evidence for automated data-quality verification, but it does not establish that the alert/case lifecycle proposed here causally lowers downtime or improves business decisions. citeturn4view0

The direct VLDB PDF endpoint for Schelter et al. was successfully inspected earlier in the research session, including parsed paper content, but a later verification fetch to the same PDF timed out. The DOI and publication identity remained available. This access issue was not silently replaced with a secondary article.

For PDFs used in the research, including the NIST profile and Schelter paper, rendered pages were inspected in addition to parsed content where required.

## Contradictions, limitations, article angles, and freshness triggers

The evidence does not support a simplistic “more observability is always better” conclusion.

**There is a genuine tension between symptom-based alerting and pre-deadline prevention.** Google SRE strongly favors paging for actionable, user-visible symptoms rather than internal causes. For a business report, however, waiting until a stakeholder discovers that the 07:20 report is stale defeats much of the purpose. citeturn25view0turn25view3

The reconciliation is to distinguish urgency:

```text
06:30 source late warning   → case/ticket, perhaps no page
07:10 risk of deadline miss → stronger escalation if impact merits it
07:20 business outcome absent → actionable outcome alert/page
```

Those times are synthetic. The important principle is that an early predictive signal and a missed business obligation need not use the same channel.

**“Every page should be novel” also requires interpretation for batch operations.** A missed October 7 batch and a missed October 8 batch may have the same technical root cause but are two distinct business obligations. Google warns against repetitive, rote paging and argues that algorithmic responses should be automated. citeturn25view3turn25view4

The right response is therefore not to collapse the two business cases into one identity. Preserve both cases, group their notifications, and if the operational response is repeatedly identical, automate the repair or downgrade the interruption rather than pretending that only one batch was affected.

**Grouping can itself become a visibility failure.** Prometheus's documented grouping pattern works because one notification can still show the exact affected instances. If an implementation says only “Daily report stale” without listing the two affected business dates, it has implemented suppression rather than useful grouping. citeturn18view0

**Freshness can give false confidence.** A recent maximum timestamp is not sufficient when a batch is partial, mislabeled or contains the wrong period. dbt's freshness checks and data tests solve different problems; they should not be conflated. citeturn20view1turn19view0

**Lineage can also give false confidence.** A beautifully populated lineage graph can prove which jobs and datasets participated without proving that the downstream business artifact is correct. OpenLineage's own object model distinguishes run state from optional quality assertions and output statistics. citeturn20view2turn23view4

**A deterministic rule can be wrong.** Nothing in the cited tooling prevents a team from encoding the wrong business invariant. Schelter et al.'s approach relies on declared constraints, and dbt's tests are likewise assertions supplied by project authors. The usefulness of deterministic monitoring therefore depends on periodically validating those assertions against domain reality. citeturn4view0turn19view0

**A monitor that shares the failure domain of the workflow can remain silent with it.** If the job scheduler, expected-work generator, monitor, case store and notification system all depend on the same database or credential, the architecture has not actually solved silent failure. Google recommends keeping the critical monitoring path simple and loosely coupled partly because monitoring itself can be fragile. citeturn25view2

Complete independence is expensive, however. A tiny low-risk business automation may rationally accept a manual morning review rather than build redundant monitors, transports and storage systems. This is a condition where the “deterministic observability platform” recommendation fails economically.

**Not every business outcome is machine-verifiable.** “Invoice was generated with the right amount” is relatively amenable to reconciliation. “Customer understood the proposal and is ready for a decision” is not. For such workflows, the expected-work model remains useful, but the final evidence may be a human attestation rather than a SQL predicate.

**Streaming systems need a different unit of obligation.** The daily `business_date` works for bounded batches. OpenLineage explicitly distinguishes bounded batch jobs from continuous streaming jobs, and Beam's event-time/watermark model illustrates why continuous systems need windows, completeness assumptions or service-level objectives rather than one terminal job state. citeturn20view2turn24view1

**AI evidence remains materially weaker than the deterministic case.** NIST gives good reasons to constrain generative-AI authority, but this research did not establish a measured break-even or incident-resolution benefit for AI triage in this exact process. citeturn20view6 A sensible experiment would compare blinded or alternating cases on human diagnostic time, factual error rate and successful next-action rate while leaving detection and closure deterministic. That would generate local evidence rather than importing vendor promises.

The strongest unresolved research gaps are therefore:

| Gap | Why it matters |
|---|---|
| Causal evidence on outcome-based monitoring versus job-status monitoring | Architecture is plausible and well-supported conceptually, but effect size is unknown |
| Empirical alert-volume → operator-response curves in business data operations | No defensible universal “too many alerts” threshold emerged |
| Controlled evidence for LLM incident triage in bounded business-data workflows | Needed before claiming ROI or faster resolution |
| Quantitative cost of maintaining deterministic rules over multiple years | Google reports maintenance burden, but small-company economics are not established |
| Best practice for independent monitoring of low-code/SaaS automations | The conceptual model transfers, but provider-specific constraints vary |
| Human/business validation of semantic reports | Deterministic data checks cannot always prove that a report supports the intended business decision |

For publication, several genuinely distinct article angles emerge rather than one generic “observability” article:

| Candidate angle | Central proposition | Evidence strength |
|---|---|---|
| **The green checkmark is not the result** | A successful workflow run is execution evidence; monitor the business artifact independently | Strong design/documentation support |
| **Your automation needs a definition of done** | Write expected work, deadline and observable outcome before choosing a tool | Strong architecture argument; causal effect unmeasured |
| **Group alerts, never erase obligations** | One notification may represent many affected batches, but every batch must remain reconcilable | Strong direct platform support from Alertmanager plus case-lifecycle reasoning |
| **Acknowledged is not fixed** | Receipt, acknowledgment, retry success and verified business recovery are different states | Strong documented support |
| **The cheapest observability stack may be a checklist** | Manual → deterministic → AI is a rational investment ladder | Synthetic economic argument; requires local parameters |
| **AI should investigate; invariants should close the case** | Use AI for bounded diagnostic leverage, not as the authoritative proof of resolution | Risk-guidance-supported recommendation; operational effect unmeasured |
| **Silent failure needs an independent expectation** | A monitor that only listens to workflow events cannot detect a workflow that never emitted an event | Strong architectural reasoning plus scheduler limitations |
| **Fresh is not necessarily correct** | Timestamp freshness, completeness, semantic validity and downstream period correctness are separate dimensions | Strong provider/docs/research support |

Useful supporting assets for those angles are already contained in this dossier: the process state model, alert-to-action inventory, resolved-case contract, SQL reference schema, synthetic three-day fixture, executed Python evaluator and synthetic economics. No external downloadable asset is required to reproduce those examples.

The material should be re-checked when any of the following freshness triggers fires:

| Trigger | What to revisit |
|---|---|
| dbt major/version change | Freshness/test syntax and behavior; current cited page is dated 2026-09-16 citeturn23view0turn23view1 |
| Kubernetes CronJob behavior/version change | Scheduling, time-zone, duplicate/missed Job caveats; cited page last modified 2026-05-13 citeturn20view0 |
| OpenLineage specification changes beyond v1.53.0 | Run-state meanings, quality facets, nominal-time semantics citeturn20view2turn23view3 |
| Prometheus Alertmanager grouping/dedup behavior changes | Case-versus-notification implementation assumptions citeturn18view0 |
| PagerDuty lifecycle/escalation changes | Ack/resolution and ownership behavior; cited page reported an update roughly two months before inspection citeturn18view1 |
| NIST issues a successor AI risk profile or strong new incident-triage evidence appears | AI role, autonomy boundaries and economics citeturn20view6 |
| Source/report contract changes | Business date, deadline, expected-work calendar and reconciliation rules |
| New holiday/time-zone/business-calendar requirement | Expectation generation and due-time conversion |
| Notification provider changes | Transport canary and alternate-route assumptions |
| Alert workload changes materially | Re-evaluate grouping, escalation and whether AI triage now crosses its local economic threshold |

The decision-oriented bottom line is therefore narrower than “implement observability”: **make the expected business result an explicit, independently monitored object.** Treat scheduler success, HTTP acceptance, row presence, freshness, lineage, notification delivery and human acknowledgment as pieces of evidence—not as synonyms for completion. Preserve one case per affected business obligation, reduce noise by grouping notifications rather than deleting cases, and let recovery finish only when the outcome predicate passes again. The current evidence supports that design much more strongly than it supports any particular vendor, alert threshold, AI agent or claimed ROI. citeturn25view1turn18view0turn18view1turn20view2