Validation of the data is one thing but, sometimes, you want to use the best part of the input dataset for something else. The get_sundered_data() function works with an agent object that has intel (i.e., post interrogate()) and gets either the 'pass' data piece (rows with no failing test units across all row-based validation functions), or, the 'fail' data piece (rows with at least one failing test unit across the same series of validations).

  type = c("pass", "fail", "combined"),
  pass_fail = c("pass", "fail"),
  id_cols = NULL



An agent object of class ptblank_agent. It should have had interrogate() called on it, such that the validation steps were actually carried out.


The desired piece of data resulting from the splitting. Options for returning a single table are "pass" (the default) and "fail". Each of these options return a single table with, in the "pass" case, only the rows that passed across all validation steps (i.e., had no failing test units in any part of a row for any validation step), or, the complementary set of rows in the "fail" case. Providing NULL returns both of the split data tables in a list (with the names of "pass" and "fail"). The option "combined" applies a categorical (pass/fail) label (settable in the pass_fail argument) in a new .pb_combined flag column. For this case the ordering of rows is fully retained from the input table.


A vector for encoding the flag column with 'pass' and 'fail' values when type = "combined". The default is c("pass", "fail") but other options could be c(TRUE, FALSE), c(1, 0), or c(1L, 0L).


An optional specification of one or more identifying columns. When taken together, we can count on this single column or grouping of columns to distinguish rows. If the table undergoing validation is not a data frame or tibble, then columns need to be specified for id_cols.


A list of table objects if type is NULL, or, a single table if a type is given.


There are some caveats to sundering. The validation steps considered for this splitting has to be of the row-based variety (e.g., the col_vals_*() functions or conjointly(), but not rows_distinct()). Furthermore, validation steps that experienced evaluation issues during interrogation are not considered, and, validation steps where active = FALSE will be disregarded. The collection of validation steps that fulfill the above requirements for sundering are termed in-consideration validation steps.

If using any preconditions for validation steps, we must ensure that all in-consideration validation steps use the same specified preconditions function. Put another way, we cannot split the target table using a collection of in-consideration validation steps that use different forms of the input table.

Function ID


See also


# Create a series of three validation # steps focus on test row values for # the `small_table` tibble object; # `interrogate()` immediately agent <- create_agent(tbl = small_table) %>% col_vals_gt(vars(d), value = 100) %>% col_vals_equal( vars(d), value = vars(d), na_pass = TRUE ) %>% col_vals_between( vars(c), left = vars(a), right = vars(d), na_pass = TRUE ) %>% interrogate() # Get the sundered data piece that # contains only rows that passed all # validation steps (the default piece) agent %>% get_sundered_data()
#> # A tibble: 9 x 8 #> date_time date a b c d e f #> <dttm> <date> <int> <chr> <dbl> <dbl> <lgl> <chr> #> 1 2016-01-04 11:00:00 2016-01-04 2 1-bcd-345 3 3423. TRUE high #> 2 2016-01-04 00:32:00 2016-01-04 3 5-egh-163 8 10000. TRUE low #> 3 2016-01-06 17:23:00 2016-01-06 2 5-jdo-903 NA 3892. FALSE mid #> 4 2016-01-11 06:15:00 2016-01-11 4 2-dhe-923 4 3291. TRUE mid #> 5 2016-01-20 04:30:00 2016-01-20 3 5-bce-642 9 838. FALSE high #> 6 2016-01-20 04:30:00 2016-01-20 3 5-bce-642 9 838. FALSE high #> 7 2016-01-26 20:07:00 2016-01-26 4 2-dmx-010 7 834. TRUE low #> 8 2016-01-28 02:51:00 2016-01-28 2 7-dmx-010 8 108. FALSE low #> 9 2016-01-30 11:23:00 2016-01-30 1 3-dka-303 NA 2230. TRUE high