| Node | Kind | State | Records | Tools | ms |
|---|---|---|---|---|---|
| intake | transform | passed | 1 | 0 | |
| map_terrain | agent | passed | 1 | 9 | 802880 |
| hypothesize | agent | passed | 3 | 0 | 282610 |
| gather_witnesses | agent | passed | 3 | 22 | 3249295 |
| witness_gate | gate | passed | 1 | 0 | |
| adjudicate | agent | passed | 1 | 0 | 82931 |
| citation_gate | gate | passed | 1 | 0 | |
| propose_remediation | agent | passed | 1 | 2 | 361136 |
| human_approval write | human | passed | 1 | 0 | |
| write_back write | tool | passed | 1 | 0 | |
| report | transform | passed | 1 | 0 |
| id | Claim | Source | Supports | Refutes |
|---|---|---|---|---|
| e11 | staging.events_daily is defined as an unfiltered COUNT(*) over channel_events_raw only — `SELECT date(occurred_at,'+9 hours') AS bucket_date, channel, COUNT(*) AS events FROM channel_events_raw GROUP BY bucket_date, channel` — applying no signup-qualifying predicate and reading no second source. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.staging.events_daily,PROD |
- | h2, h1 |
| e12 | staging.events_weekly_rollup is defined as the same unfiltered COUNT(*) over channel_events_raw as events_daily — `SELECT strftime('%Y-W%W', occurred_at) AS bucket_week, channel, COUNT(*) AS events FROM channel_events_raw GROUP BY bucket_week, channel` — encoding the identical signup definition and differing from the daily model ONLY in the time-bucket expression (raw occurred_at week vs. events_daily's occurred_at+9h date), not an older/narrower definition. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.staging.events_weekly_rol |
- | h2 |
| e13 | The marts signups view is a pure rename pass-through of events_daily — `SELECT bucket_date AS day, channel, events AS signups FROM events_daily` — introducing no additional filter, dedup, or definitional change between events_daily and the reported signup metric. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.signups,PROD) |
- | h2 |
| e14 | metric_definition_history contains exactly one row (version 1, day 1, metric 'active_users_daily') and has NO entry referencing signups, events_daily, or events_weekly_rollup anywhere in the day-1..day-36 window, so no recorded signup-definition edit exists to have landed only in the daily model. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.signups,PROD) |
- | h2 |
| e15 | schema_migration_log contains exactly one row (migration M-0001, day 2, 'CREATE INDEX idx_orders_customer ON orders(customer_code)') — an index on the orders table — and no migration in the window alters the definition of signups, events_daily, or events_weekly_rollup. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.signups,PROD) |
- | h2 |
| e16 | Across the whole window the daily model total (SUM signups=4437), the weekly model total (SUM events=4437) and the channel_events_raw row count (4437) are all exactly equal, while the week of 2026-06-22 shows daily 1194 vs weekly 895; equal grand totals are inconsistent with the daily model applying a broader signup definition (which would inflate the daily total), so the ~1/3 per-week surplus is a time-bucket boundary artifact that must net to zero across weeks, not a mid-window definition change. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.signups,PROD) |
- | h2, h1 |
| e21 | The events_daily view (aliased row-for-row by marts.signups) counts rows from channel_events_raw ONLY and buckets them by local calendar day via date(occurred_at,'+9 hours'); it never reads raw.web_sessions. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.staging.events_daily,PROD |
- | h1 |
| e22 | The events_weekly_rollup view counts rows from the SAME channel_events_raw table with the same COUNT(*) aggregation, differing from the daily model only in its time-bucket expression: it buckets by UTC week strftime('%Y-W%W', occurred_at) with no +9h local shift — so daily and weekly encode the same signup definition, not different ones. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.staging.events_weekly_rol |
- | h2 |
| e23 | Summed over the entire dataset the daily and weekly models return an identical total that equals the raw row count (4437 = 4437 = 4437), so the daily model contains zero rows the weekly model does not and captures no 'extra real customers'; raw.web_sessions (8781 rows) feeds neither model. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.channel_events_r |
- | h3, h1 |
| e24 | For 2026-W25 (the %W week beginning Monday 2026-06-22) the daily-local sum is 1194 vs the weekly-UTC sum 895 (+299 ≈ 33%, i.e. 'about a third more'), but the daily-vs-weekly gap swings BOTH directions across weeks (W22 -61, W23 -5, W24 -328, W25 +299, W26 +2, W27 +93) and the +299 W25 surplus is mirrored by the -328 W24 deficit — a standing week-boundary artifact, not a campaign-week-only surge of net-new signups. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.signups,PROD) |
- | h3 |
| e25 | The +299 local-W25 daily surplus is composed of channel_events_raw rows relocated across the week boundary by the +9h local shift — 394 rows fall in UTC-W24 but local-W25 (and 95 fall in UTC-W25 but local-W26) — i.e. boundary-straddling rows, not net-new distinct identities, so recomputing both models on one shared week convention would make them agree. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.channel_events_r |
- | h3 |
| e1 | DataHub upstream lineage for staging.events_daily lists two source datasets: raw.channel_events_raw and raw.web_sessions. | datahub_lineage urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.staging.events_daily,PROD |
h1 | - |
| e2 | The events_daily view is defined as SELECT date(occurred_at,'+9 hours') AS bucket_date, channel, COUNT(*) FROM channel_events_raw GROUP BY ... — it reads only channel_events_raw and never references web_sessions. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.staging.events_daily,PROD |
- | h1 |
| e3 | The events_weekly_rollup view is defined as SELECT strftime('%Y-W%W', occurred_at) AS bucket_week, channel, COUNT(*) FROM channel_events_raw GROUP BY ... — it also reads only channel_events_raw, so both reconciled branches draw from the same single source and differ only in the time bucket (local +9h day vs UTC %Y-W%W week). | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.staging.events_weekly_rol |
- | h1 |
| e4 | The signups view (marts.signups) is a pass-through of events_daily: SELECT bucket_date AS day, channel, events AS signups FROM events_daily, so the daily signup count terminates at channel_events_raw only and never counts web_sessions rows. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.signups,PROD) |
- | h1 |
| e5 | For week 2026-W25, summing the signups view over local days 2026-06-22..2026-06-28 gives 1194 while events_weekly_rollup reports 895 — the daily side exceeds the weekly side by 299 (~33%, i.e. about a third more). | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.signups,PROD) |
- | - |
| e6 | The 299-row daily surplus for week 2026-W25 traces entirely to the shared source channel_events_raw via the timezone/week-boundary bucketing difference, not to web_sessions: partitioning channel_events_raw by window membership gives 800 rows in both windows, 394 only in the local-day window, and 95 only in the UTC-week window, so daily_only(394) − weekly_only(95) = 299 = the surplus. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.channel_events_r |
- | h1 |
This page is built from the run ledger alone. It never reads the agent's own summary of what it did.