Hi @IM_01,

Warned_records / dropped_records (top-level): These are aggregated per-dataset counts of unique rows that were warned or dropped in that micro-batch/update. They are not a simple sum of failed_records across expectations, because the same row can fail multiple expectations. That row is counted once in warned_records but multiple times in expectations[*].failed_records.

That’s why in your example:

"warned_records": 344,
"expectations": [
  {"name":"valid_case1", ... "failed_records":313},
  {"name":"valid_case2", ... "failed_records":99}
]

344 ≠ 313 + 99  some rows likely violated both valid_case1 and valid_case2.

For fail expectations, the update aborts on the first violation, and data quality metrics are not recorded in the same way as warn/drop. Practically, you do not get meaningful passed_records/failed_records metrics for that expectation in details.flow_progress.data_quality. Instead, you get an expectation violation error event (with the expectation name and offending record) in the event log / error message, but no aggregate counts of how many rows would have failed. So, yes, warned_records is an aggregated, deduped count at the dataset level. No, a FAIL action does not behave like warn/drop in the metrics JSON. you generally won’t see reliable passed_records/failed_records for it, just the failure event.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.