Active users jumped overnight with no release

MTI-009 · graph metric-truth · 15 ledger records

What this run caught

No violationsFabricated citations, unapproved effects and tool violations are all zero

Adjudication

Agent verdict
instrument_failure
bot_traffic_mixed
Answer key
definition_change
metric_definition_widened
Outcome
wrong
14 of 14 citations resolve

Graph execution

NodeKindStateRecordsToolsms
intake transform passed 1 0
map_terrain agent passed 1 10 680527
hypothesize agent passed 3 0 255505
gather_witnesses agent passed 3 24 3697026
witness_gate gate passed 1 0
adjudicate agent passed 1 0 141376
citation_gate gate passed 1 0
propose_remediation agent passed 1 1 174846
human_approval write human passed 1 0
write_back write tool passed 1 0
report transform passed 1 0

Witness ledger

idClaimSourceSupportsRefutes
e21 The day-24 step in active_users_daily is entirely attributable to is_automated=1 (bot) customer_codes; the is_automated=0 (human) distinct-code count on day 24 (205) stays within the day 1–23 baseline (~140–210). warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
h1, h2 h3
e22 Every distinct customer_code whose first-ever appearance is the step day (day 24) is is_automated=1; zero net-new human customer_codes appear on day 24, and across days 21–30 net-new codes appear only on days 24 and 25. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
h1, h2 h3
e23 The day-24 net-new customer_codes carry a synthetic/batch signature, not human traits: 100% is_automated=1, exactly one session per code, distributed evenly across four channels with only four distinct browser versions each. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
h1, h2 h3
e24 Recomputing active users over the same day-24 rows with automated sessions excluded (is_automated=0, the bot-exclusion rule) reproduces the pre-jump baseline, showing the human population did not actually change on the step day. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
h1, h2 h3
e25 raw.web_sessions exposes is_automated as the automated/human discriminator, and its own DataHub description notes the flag is not populated by every producer. datahub_schema
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
- -
e1 The active_users_daily view computes COUNT(DISTINCT customer_code) FROM web_sessions GROUP BY day with no is_automated predicate and no reference to metric_definition_history, so its implementation never gates on the bot flag. datahub_schema
urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.active_users_daily,
h1 h2
e2 metric_definition_history records a v1 (day 1) definition of active_users_daily as 'distinct customers with at least one non-automated session' and a v2 (day 24) definition of 'distinct customers with any session, including passive_view', i.e. the bot-exclusion rule was edited out exactly on the step day. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.metric_definitio
h1, h2 h3
e3 web_sessions carries zero is_automated=1 sessions on days 1-23 and 142 is_automated=1 sessions on day 24, so automated traffic first enters the substrate on the step day. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
h1 h3
e4 On day 24 every one of the 142 is_automated=1 customer_codes is brand-new (unseen on any day <24), while all 205 is_automated=0 codes were already present before day 24 (0 new), so the entire net-new distinct-code surplus is automated. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
h1 h3
e5 Recomputing the count under the v1 'non-automated' rule (is_automated=0 only) leaves day 24 at 205, inside the day 22-23 baseline (210, 197), so removing automated sessions collapses the ~150-user jump entirely. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
h1 h3
e6 The active_users_daily output itself steps from 197 (day 23) to 347 (day 24) and holds at an elevated level (241-347) through day 36, so the disputed number's discontinuity is dated to day 24, coinciding with automation onset (e3) and the definition edit (e2). warehouse_query
urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.active_users_daily,
h1 -
e11 metric_definition_history records a semantic, broadening redefinition of active_users_daily effective on day 24: v1 (day 1) = 'distinct customers with at least one non-automated session', v2 (day 24) = 'distinct customers with any session, including passive_view'. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.metric_definitio
h2 -
e12 active_users_daily steps discontinuously from 197 (day 23) to 347 (day 24) and stays elevated thereafter, so the single-day jump lands exactly on the day-24 metric_definition_history version-2 boundary. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.active_users_daily,
h2 h3
e13 The active_users_daily view is defined as COUNT(DISTINCT customer_code) FROM web_sessions GROUP BY day, with no is_automated filter and no reference to metric_definition_history, so the computation neither reads the definition store nor applies any bot-exclusion rule and its text is unchanged across the jump. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.active_users_daily,
h1 h2
e14 The entire day-24 increment in active_users_daily is automated sessions (142 distinct is_automated=1 codes appearing first on day 24, 0 on days 20-23) while human (is_automated=0) distinct codes stay flat (~205 vs ~197) and passive_view distinct codes are 0 on every day, so all_users = human + automated and the redefinition's named addition (passive_view) contributes nothing. warehouse_query
urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.web_sessions,PRO
h1 h2, h3
e15 DataHub lineage lists raw.metric_definition_history as a 1-hop UPSTREAM of marts.active_users_daily, but the view DDL reads only web_sessions, so the definition-store link is a declared lineage edge with no computational path by which a definition edit reaches the number. datahub_lineage
urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.active_users_daily,
- h2

This page is built from the run ledger alone. It never reads the agent's own summary of what it did.