| Node | Kind | State | Records | Tools | ms |
|---|---|---|---|---|---|
| intake | transform | passed | 1 | 0 | |
| map_terrain | agent | passed | 1 | 9 | 376942 |
| hypothesize | agent | passed | 3 | 0 | 199238 |
| gather_witnesses | agent | passed | 3 | 22 | 2703543 |
| witness_gate | gate | passed | 1 | 0 | |
| adjudicate | agent | passed | 1 | 0 | 246650 |
| citation_gate | gate | passed | 1 | 0 | |
| propose_remediation | agent | passed | 1 | 2 | 233932 |
| human_approval write | human | passed | 1 | 0 | |
| write_back write | tool | passed | 1 | 0 | |
| report | transform | passed | 1 | 0 |
| id | Claim | Source | Supports | Refutes |
|---|---|---|---|---|
| e1 | The feature_adoption view's client_events column is computed solely as a correlated subquery COUNT(*) over feature_usage_events where u.feature = d.feature AND u.source = 'client_event', with the feature/day list supplied FROM release_deploy_log — this is the sole counting path h1 concerns. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.feature_adoption,PR |
- | - |
| e2 | In feature_usage_events, 'price_alerts' has exactly one row across all days and all sources — source='deploy_marker' on day 20 only — and ZERO rows with source='client_event' or any other source, so the view's WHERE u.source='client_event' filter has no real price_alerts client-usage rows to discard. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.feature_usage_ev |
h2, h3 | h1 |
| e3 | The identical source='client_event' filter yields client_events=825 for the live feature quick_reorder (days 12–36) while yielding 0 for price_alerts, demonstrating the filter literal matches real emitted client-usage rows and is not the cause of price_alerts' zero. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.feature_adoption,PR |
- | h1 |
| e4 | feature_usage_events.source takes exactly the documented pair {client_event, deploy_marker} and no variant client literal (e.g. 'client_event_v2', 'app_client') is documented or actually present, so there is no alternate source literal carrying discarded price_alerts usage and no differently-keyed price_alerts feature (only 'price_alerts' and 'quick_reorder' feature keys exist). | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.feature_usage_ev |
- | h1 |
| e21 | The marts.feature_adoption view derives client_events solely as a correlated COUNT(*) over feature_usage_events rows WHERE source='client_event', keyed by feature; release_deploy_log only supplies the feature/day list via the FROM clause. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.feature_adoption,PR |
- | - |
| e22 | In feature_usage_events, price_alerts has exactly one row (source='deploy_marker', day 20) and zero rows under any other source value, whereas quick_reorder has 825 rows all source='client_event' spanning days 12-36. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.feature_usage_ev |
- | h1 |
| e23 | Across days 20-36, feature_usage_events contains quick_reorder client_event rows on every single day (26-40 per day) but zero price_alerts rows of any source after the lone day-20 deploy_marker. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.feature_usage_ev |
h2 | h3 |
| e24 | release_deploy_log records price_alerts as shipped on day 20 (deploy_id D-0020, shipped=1) and is one of only two deploy rows, so the feature_adoption view does emit a price_alerts row whose client_events evaluates to a genuine 0 rather than a missing row. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.release_deploy_l |
- | - |
| e11 | release_deploy_log records price_alerts as deployed on day 20 with shipped=1 (quick_reorder on day 12, shipped=1), so the price_alerts deploy demonstrably landed inside the day 20-36 window. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.release_deploy_l |
h2 | - |
| e12 | In feature_usage_events, price_alerts has exactly ONE row (source='deploy_marker', day 20) and ZERO rows with source='client_event' under any day or any other source literal, while quick_reorder has 825 source='client_event' rows spanning days 12-36. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.feature_usage_ev |
h2, h3 | h1 |
| e13 | Filtered to source='client_event' over days 20-36, feature_usage_events returns 576 rows for quick_reorder and no row at all for price_alerts, showing the client-usage counting path and ingest are demonstrably healthy for a peer feature in the exact window while price_alerts contributes nothing. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.feature_usage_ev |
h2 | - |
| e14 | The feature_adoption view derives client_events solely as COUNT(*) of feature_usage_events where u.feature=d.feature AND u.source='client_event', with the feature/day list coming from release_deploy_log, so price_alerts's reported usage is exactly its count of source='client_event' rows — which is zero — meaning the metric faithfully reflects the raw rows rather than mis-computing. | datahub_schema urn:li:dataset:(urn:li:dataPlatform:dbt,witnessgraph.marts.feature_adoption,PR |
h2 | - |
| e15 | No candidate refuter of h2 is present in the observable data: the only price_alerts row in the window is a system-written source='deploy_marker' (not a user client_event), so h2's refutation criterion ('one or more price-alerts rows showing users reached the feature') is NOT met; conversely h2's decisive confirmer — the rollout/feature-flag exposure config — is unobservable because the warehouse catalog exposes no flag/rollout/exposure relation. | warehouse_query urn:li:dataset:(urn:li:dataPlatform:postgres,witnessgraph.raw.feature_usage_ev |
h2, h3 | - |
This page is built from the run ledger alone. It never reads the agent's own summary of what it did.