Pointblank https://posit-dev.github.io/pointblank/blog/ quarto-1.10.18 Wed, 04 Jun 2025 00:00:00 GMT Data Validation Libraries for Polars (2025 Edition) Rich Iannone https://posit-dev.github.io/pointblank/blog/validation-libs-2025/ Data validation is a very important part of any data pipeline. And with Polars gaining popularity as a superfast and feature-packed DataFrame library, developers need validation tools that work seamlessly with it. But here’s the thing: not all validation libraries are created equal, and choosing the wrong one can lead to frustration, technical debt, or validation gaps that could bite you later.

In this survey (conducted halfway through 2025) we’ll explore five Python validation libraries that support Polars DataFrames, each bringing distinct strengths to different validation challenges.

Note

Great Expectations, while being one of the most established data validation frameworks in the Python ecosystem, is not included in this survey as it doesn’t yet offer native Polars support. See this issue and this discussion for the inside baseball.

Recommendations

Here are the unique strengths for each library:

Library ⭐ Best Features
Pandera 3,838 Statistical testing, schema-centric validation, mypy integration
Patito 468 Pydantic integration, model-based validation, row-level objects
Pointblank 173 Interactive reports, threshold management, stakeholder communication
Validoopsie 63 Built-in logging, composable validation, impact levels, lightweight Great Expectations alternative
Dataframely 319 Collection validation, advanced type safety, failure analysis

Based on these strengths, here are my recommendations for which libraries to use according to use case:

Use Case Best Libraries Description
Type-safe pipelines Pandera, Dataframely, Patito Static type checking and compile-time validation
Stakeholder reporting Pointblank Sharing validation results with non-technical teams
Row-level object modeling Patito Converting DataFrame rows to Python objects with business logic
Statistical validation Pandera Testing data distributions and statistical properties
Data quality improvement Pointblank, Validoopsie Gradual quality improvement with threshold tracking

Setup

We are going to run through examples with Pandera, Patito, Pointblank, Validoopsie, and Dataframely, using this Polars DataFrame as our test case:

import polars as pl

# Standard dataset for all validation examples
user_data = pl.DataFrame({
    "user_id": [1, 2, 3, 4, 5],
    "age": [25, 30, 22, 45, 95],  # <- includes a very high age
    "email": [
        "user1@example.com", "user2@example.com", "invalid-email",  # <- has an invalid email
        "user4@example.com", "user5@example.com"
    ],
    "score": [85.5, 92.0, 78.3, 88.7, 95.2]
})

We’ll try to run the same data validation across the surveyed libraries, so we’ll check:

  • schema validation (correct column types)
  • user_id values greater than 0
  • age values between 18 and 80 (inclusive)
  • email strings matching a basic email regex pattern
  • score values between 0 and 100 (inclusive)

Now let’s dive into each library, starting with the statistically-focused Pandera.

1. Pandera: Schema-First Validation with Statistical Checks

Pandera is a statistical data validation toolkit designed to provide a flexible and expressive API for performing data validation on dataframe-like objects. The library centers on schema-centric validation, where you define the expected structure and constraints of your data upfront. You can enable both runtime validation and static type checking integration. Pandera added Polars support in version 0.19.0 (early 2024).

Example

import pandera.polars as pa

# Define schema using our standard dataset
schema = pa.DataFrameSchema({
    "user_id": pa.Column(pl.Int64, checks=pa.Check.gt(0)),
    "age": pa.Column(pl.Int64, checks=[pa.Check.ge(18), pa.Check.le(80)]),
    "email": pa.Column(pl.Utf8, checks=pa.Check.str_matches(r"^[^@]+@[^@]+\.[^@]+$")),
    "score": pa.Column(pl.Float64, checks=pa.Check.in_range(0, 100))
})

# Validate the schema
try:
    validated_data = schema.validate(user_data)
    print("Validation successful!")
except pa.errors.SchemaError as e:
    print(f"Validation failed: {e}")
Validation failed: Column 'age' failed validator number 1: <Check less_than_or_equal_to: less_than_or_equal_to(80)> failure case examples: [{'age': 95}]

This example demonstrates Pandera’s declarative approach, where you define what your data should look like rather than writing imperative validation logic. The schema acts as both documentation and as a validation contract. Notice how multiple checks can be applied to a single column (here, the age column receives two checks), and the validation either succeeds completely or provides error information about what failed.

Comparisons

Both Pandera and Patito use declarative, schema-centric approaches, but differ in their design philosophies:

  • Pandera uses a dictionary-like schema structure with Column objects for defining validation rules
  • Patito uses Pydantic model classes with familiar Field syntax for validation constraints
  • Pandera focuses heavily on statistical validation capabilities like hypothesis testing
  • Patito emphasizes integration with existing Pydantic workflows and object modeling
  • a key behavioral difference: Patito reports all validation errors in a single pass, while Pandera stops at the first failure

The choice between them often comes down to whether you prefer Pandera’s statistical focus or Patito’s Pydantic integration.

Unlike Pointblank’s step-by-step validation reporting, Pandera validates the entire schema at once. Compared to Patito’s model-based approach, Pandera focuses more on statistical validation capabilities. Unlike Validoopsie’s and Pointblank’s method chaining style, Pandera uses a more declarative, schema-centric approach.

Unique Strengths and When to Use

Here are some of stand-out features that Pandera has:

  • type-safe schema definitions with mypy integration
  • statistical hypothesis testing for data distributions: perform t-tests, chi-square tests, and custom statistical tests directly in your validation schema
  • excellent integration with Pandas, Polars, and Arrow support
  • declarative schema syntax that serves as documentation
  • built-in support for data coercion and transformation

This statistical validation capability goes beyond basic type and range checking to test actual data relationships and distributional assumptions. For example, you can validate that the mean height of group "M" is significantly greater than group "F" using a two-sample t-test, or test whether a column follows a normal distribution. This makes Pandera uniquely powerful for data science workflows where the statistical properties of your data are as important as individual data points meeting basic constraints.

Data practitioners should choose Pandera when building type-safe data pipelines where schema validation is critical, especially in data science workflows that require statistical validation. It’s ideal for users that value static type checking, need to validate statistical properties of their data, or want schemas that double as documentation.

Pandera also excels in environments where data contracts between teams are important and where the statistical properties of data matter as much as basic type checking.

2. Patito: Pydantic-Style Data Models for DataFrames

Patito brings Pydantic’s well-received model-based validation approach to DataFrame validation, creating a bridge between Pydantic-style data validation and DataFrame processing. The library’s primary goal is to provide a familiar, Pydantic-style interface for defining and validating DataFrame schemas, making it particularly appealing to developers already using Pydantic in their applications.

Patito launched with Polars support from the beginning (in late 2022). Native Polars integration is touted as one of its core features, reflecting the growing adoption of Polars in the Python ecosystem.

Example

import patito as pt
from typing import Annotated

class UserModel(pt.Model):
    user_id: int = pt.Field(gt=0)
    age: Annotated[int, pt.Field(ge=18, le=80)]
    email: str = pt.Field(pattern=r"^[^@]+@[^@]+\.[^@]+$")
    score: float = pt.Field(ge=0.0, le=100.0)

# Validate using the model
try:
    UserModel.validate(user_data)
    print("Validation successful!")
except pt.exceptions.DataFrameValidationError as e:
    print(f"Validation failed: {e}")
Validation failed: 2 validation errors for UserModel
age
  1 row with out of bound values. (type=value_error.rowvalue)
email
  1 row with out of bound values. (type=value_error.rowvalue)

This example showcases Patito’s model-centric approach where validation rules are embedded in class definitions. The use of Python’s type hints and Pydantic’s Field syntax makes the validation rules self-documenting. Notably, Patito reports all validation errors at once, providing a fairly comprehensive view of data quality issues, whereas other libraries (e.g., Pandera) stop at the first failure.

Column Validation Approaches: Pandera vs Patito

Pandera offers a much more extensive and flexible system for column validation compared to Patito’s field-based approach. While Patito provides a solid set of built-in field constraints (like gt, le, regex, unique, etc.) that cover common validation scenarios, Pandera’s Check system is designed for both simple and highly sophisticated validation logic.

The key architectural difference seems to lie in extensibility and complexity. Pandera’s Check objects accept arbitrary functions, allowing you to write custom validation logic that can be as simple as lambda s: s > 0 or as complex as statistical hypothesis tests using scipy. You can create vectorized checks that operate on entire Series objects for performance, element-wise checks for atomic validation, and even grouped checks that validate subsets of data based on other columns. Patito’s Field constraints, while clean and declarative, are more limited to the predefined validation types that Pydantic and Patito provide.

Pandera also supports advanced validation patterns that Patito doesn’t directly offer, such as wide-form data checks (validating relationships across multiple columns), grouped validation (where checks are applied to subsets of data based on grouping columns), and the ability to raise warnings instead of errors for non-critical validation failures. While Patito does support custom constraints through Polars expressions via the constraints parameter, this requires knowledge of Polars expression syntax and, depending on where you’re coming from, could be less intuitive than Pandera’s function-based approach.

For most common validation scenarios, Patito’s field-based validation is simpler and more readable, especially for teams already familiar with Pydantic. However, for complex data validation requirements, statistical validation, or when you need maximum flexibility in defining validation logic, Pandera’s Check system provides significantly more power and extensibility.

Unique Strengths and When to Use

  • Pydantic-style model definitions with familiar syntax for Pydantic users
  • rich type system integration with Python’s typing system
  • model inheritance and composition for complex data structures
  • seamless integration with existing Pydantic-based applications
  • row-level object modeling for converting DataFrame rows to Python objects with methods
  • mock data generation for testing with .examples() method

People should choose Patito when they’re already using Pydantic in their applications and want consistent validation patterns across data processing and application logic. It’s great when you need to validate DataFrames and then work with individual rows as rich Python objects with embedded business logic and methods (e.g., a Product row that has a .url property or .calculate_discount() method). Patito is also good when you need to generate realistic test data and want object-oriented interfaces for their data models.

3. Pointblank: Comprehensive Validation with Beautiful Reports

Pointblank is a comprehensive data validation framework designed to make data quality assessment both thorough and accessible to stakeholders. Originally inspired by the R package of the same name, Pointblank’s primary mission is to provide validation workflows that generate beautiful, interactive reports that can be shared with both technical and non-technical team members.

Pointblank launched with Polars support as a core feature from its initial Python release in late 2024, built on top of the Narwhals and Ibis compatibility layers to provide consistent DataFrame operations across multiple backends including Polars, Pandas, and database connections.

Example

import pointblank as pb

schema = pb.Schema(
    columns=[("user_id", "Int64"), ("age", "Int64"), ("email", "String"), ("score", "Float64")]
)

validation = (
    pb.Validate(data=user_data, label="An example.", tbl_name="users", thresholds=(0.1, 0.2, 0.3))
    .col_vals_gt(columns="user_id", value=0)
    .col_vals_between(columns="age", left=18, right=80)
    .col_vals_regex(columns="email", pattern=r"^[^@]+@[^@]+\.[^@]+$")
    .col_vals_between(columns="score", left=0, right=100)
    .col_schema_match(schema=schema)
    .interrogate()
)

validation
Pointblank Validation
An example.
PolarsusersWARNING0.1ERROR0.2CRITICAL0.3
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#4CA64C 1
col_vals_gt
col_vals_gt()
 user_id 0 ✓ 5 5
1.00		 0
0.00		 ○ ○ ○ —
#EBBC14 2
col_vals_between
col_vals_between()
 age [18, 80] ✓ 5 4
0.80		 1
0.20		 ● ● ○
#EBBC14 3
col_vals_regex
col_vals_regex()
 email ^[^@]+@[^@]+\.[^@]+$ ✓ 5 4
0.80		 1
0.20		 ● ● ○
#4CA64C 4
col_vals_between
col_vals_between()
 score [0, 100] ✓ 5 5
1.00		 0
0.00		 ○ ○ ○ —
#4CA64C 5
col_schema_match
col_schema_match()
 — SCHEMA ✓ 1 1
1.00		 0
0.00		 ○ ○ ○ —
2026-07-22 23:16:31 UTC< 1 s2026-07-22 23:16:31 UTC
Notes

Step 5 (schema_check) ✓ Schema validation passed.

Schema Comparison
TARGET EXPECTED
COLUMN DATA TYPE COLUMN DATA TYPE
1 user_id Int64 1 user_id ✓ Int64 ✓
2 age Int64 2 age ✓ Int64 ✓
3 email String 3 email ✓ String ✓
4 score Float64 4 score ✓ Float64 ✓
Supplied Column Schema:
[('user_id', 'Int64'), ('age', 'Int64'), ('email', 'String'), ('score', 'Float64')]
Schema Match Settings
COMPLETE
IN ORDER
COLUMN ≠ column
DTYPE ≠ dtype
float ≠ float64

This example demonstrates Pointblank’s chainable validation approach where each validation step is clearly defined and can be configured with different threshold levels. The resulting validation object provides rich, interactive reporting that shows not just what passed or failed, but detailed statistics about the validation process. The threshold system allows for nuanced responses to data quality issues.

Comparisons

Unlike Pandera’s schema-first approach, Pointblank focuses on step-by-step validation with detailed reporting and flexible failure thresholds that can be set at both the global and individual validation step level. Both Pointblank and Validoopsie use numeric threshold values for granular control over acceptable failure rates, but they differ in their primary focus: Pointblank emphasizes comprehensive reporting and stakeholder communication, while Validoopsie prioritizes operational resilience through its impact level system (low/medium/high) that controls whether threshold breaches are logged, reported, or raise exceptions.

While both libraries support custom validation logic, Pointblank’s specially() method integrates seamlessly with its reporting system, whereas Validoopsie provides a structured framework for creating custom validation classes that fit into its modular validation catalog.

Unique Strengths and When to Use

  • beautiful, interactive HTML reports that are great for sharing with stakeholders
  • threshold-based alerting system with configurable actions
  • segmented validation for analyzing subsets of data
  • LLM-powered validation suggestions via DraftValidation
  • comprehensive data inspection tools and summary tables
  • step-by-step validation reporting with detailed failure analysis (via .get_step_report())

Data practitioners might want to choose Pointblank when stakeholder communication and comprehensive data quality reporting are priorities. Because of the reporting tables it can generate, it’s well-suited for data teams that need to regularly report on data quality to relevant stakeholders. Pointblank also excels in production data monitoring scenarios, data observability workflows, and situations where understanding the nuances of data quality issues matters more than simple pass/fail validation.

4. Validoopsie: Composable Checks with Smart Failure Handling

Validoopsie is built around composable validation principles, providing a toolkit for creating reusable validation functions organized into logical modules. Drawing inspiration from Great Expectations but with a much lighter footprint, Validoopsie emphasizes building validation logic from modular, testable components that can be combined in flexible ways to create complex validation workflows. The library had Polars support from its very first release (early-2025).

What sets Validoopsie apart is its sophisticated approach to handling validation failures through impact levels and threshold tolerances. These features that give you fine-grained control over how your validation pipeline behaves when things go wrong.

Example

from validoopsie import Validate
from narwhals.dtypes import Int64, Float64, String

# Composable validation checks with impact levels and thresholds
validation = (
    Validate(user_data)
    .ValuesValidation.ColumnValuesToBeBetween(
        column="user_id",
        min_value=0,
        impact="high"  # Critical - will raise exception
    )
    .ValuesValidation.ColumnValuesToBeBetween(
        column="age",
        min_value=18,
        max_value=80,
        threshold=0.1,  # Allow 10% failures
        impact="medium"  # Important but not critical
    )
    .StringValidation.PatternMatch(
        column="email",
        pattern=r"^[^@]+@[^@]+\.[^@]+$",
        threshold=0.05,  # Allow 5% malformed emails
        impact="low"  # Record but don't interrupt
    )
    .ValuesValidation.ColumnValuesToBeBetween(
        column="score",
        min_value=0,
        max_value=100,
        impact="medium"
    )
    .TypeValidation.TypeCheck(
        frame_schema_definition={
            "user_id": Int64,
            "age": Int64,
            "email": String,
            "score": Float64
        },
        impact="high"  # Schema compliance is critical
    )
)

# Get validation results
validation.validate()

# Access detailed results for analysis
print("Validation results:", validation.results)
2026-07-22 19:16:31.174 | INFO     | validoopsie.validate:validate:414 - Passed validation: {'validation': 'ColumnValuesToBeBetween', 'impact': 'high', 'timestamp': '2026-07-22T19:16:31.171704-04:00', 'column': 'user_id', 'result': {'status': 'Success', 'threshold_pass': True, 'message': 'All items passed the validation.', 'frame_row_number': 5, 'threshold': 0.0}}

2026-07-22 19:16:31.175 | ERROR    | validoopsie.validate:validate:406 - Failed validation: ColumnValuesToBeBetween_age - The column 'age' has values that are not between 18 and 80.

2026-07-22 19:16:31.175 | WARNING  | validoopsie.validate:validate:408 - Failed validation: PatternMatch_email - The column 'email' has entries that do not match the pattern '^[^@]+@[^@]+\.[^@]+$'.

2026-07-22 19:16:31.175 | INFO     | validoopsie.validate:validate:414 - Passed validation: {'validation': 'ColumnValuesToBeBetween', 'impact': 'medium', 'timestamp': '2026-07-22T19:16:31.174300-04:00', 'column': 'score', 'result': {'status': 'Success', 'threshold_pass': True, 'message': 'All items passed the validation.', 'frame_row_number': 5, 'threshold': 0.0}}

2026-07-22 19:16:31.175 | INFO     | validoopsie.validate:validate:414 - Passed validation: {'validation': 'TypeCheck', 'impact': 'high', 'timestamp': '2026-07-22T19:16:31.174759-04:00', 'column': 'DataTypeColumnValidation', 'result': {'status': 'Success', 'threshold_pass': True, 'message': 'All items passed the validation.', 'frame_row_number': 4, 'threshold': 0.0}}

Validation results: {'Summary': {'passed': False, 'validations': ['ColumnValuesToBeBetween_user_id', 'ColumnValuesToBeBetween_age', 'PatternMatch_email', 'ColumnValuesToBeBetween_score', 'TypeCheck_DataTypeColumnValidation'], 'failed_validation': ['ColumnValuesToBeBetween_age', 'PatternMatch_email']}, 'ColumnValuesToBeBetween_user_id': {'validation': 'ColumnValuesToBeBetween', 'impact': 'high', 'timestamp': '2026-07-22T19:16:31.171704-04:00', 'column': 'user_id', 'result': {'status': 'Success', 'threshold_pass': True, 'message': 'All items passed the validation.', 'frame_row_number': 5, 'threshold': 0.0}}, 'ColumnValuesToBeBetween_age': {'validation': 'ColumnValuesToBeBetween', 'impact': 'medium', 'timestamp': '2026-07-22T19:16:31.173064-04:00', 'column': 'age', 'result': {'status': 'Fail', 'threshold_pass': False, 'message': "The column 'age' has values that are not between 18 and 80.", 'failing_items': [95], 'failed_number': 1, 'frame_row_number': 5, 'threshold': 0.1, 'failed_percentage': 0.2}}, 'PatternMatch_email': {'validation': 'PatternMatch', 'impact': 'low', 'timestamp': '2026-07-22T19:16:31.173667-04:00', 'column': 'email', 'result': {'status': 'Fail', 'threshold_pass': False, 'message': "The column 'email' has entries that do not match the pattern '^[^@]+@[^@]+\\.[^@]+$'.", 'failing_items': ['invalid-email'], 'failed_number': 1, 'frame_row_number': 5, 'threshold': 0.05, 'failed_percentage': 0.2}}, 'ColumnValuesToBeBetween_score': {'validation': 'ColumnValuesToBeBetween', 'impact': 'medium', 'timestamp': '2026-07-22T19:16:31.174300-04:00', 'column': 'score', 'result': {'status': 'Success', 'threshold_pass': True, 'message': 'All items passed the validation.', 'frame_row_number': 5, 'threshold': 0.0}}, 'TypeCheck_DataTypeColumnValidation': {'validation': 'TypeCheck', 'impact': 'high', 'timestamp': '2026-07-22T19:16:31.174759-04:00', 'column': 'DataTypeColumnValidation', 'result': {'status': 'Success', 'threshold_pass': True, 'message': 'All items passed the validation.', 'frame_row_number': 4, 'threshold': 0.0}}}

This example showcases Validoopsie’s key differentiators: modular validation categories (ValuesValidation, StringValidation, TypeValidation) combined with impact levels that control failure behavior and thresholds that allow controlled tolerance for data quality issues. Unlike other libraries that treat all validation failures equally, Validoopsie lets you specify which validations are critical (“high” impact raises exceptions) versus informational (“low” impact just logs results).

Validoopsie’s most powerful feature is its three-tier impact= system combined with threshold= tolerance:

# Example showing sophisticated failure handling
validation = (
    Validate(user_data)
    # Critical validation - no tolerance
    .NullValidation.ColumnNotBeNull(
        column="user_id",
        impact="high"    # Will raise an exception if any Null values found
    )
    # Important validation with tolerance
    .StringValidation.PatternMatch(
        column="email",
        pattern=r"^[^@]+@[^@]+\.[^@]+$",
        threshold=0.15,  # Allow up to 15% malformed emails
        impact="medium"  # Log failures but don't stop processing
    )
    # Informational validation
    .ValuesValidation.ColumnValuesToBeBetween(
        column="score",
        min_value=90,
        max_value=100,
        threshold=0.8,  # Allow 80% to be outside "excellent" range
        impact="low"    # Just track high performers
    )
)

validation.validate()
2026-07-22 19:16:31.181 | INFO     | validoopsie.validate:validate:414 - Passed validation: {'validation': 'ColumnNotBeNull', 'impact': 'high', 'timestamp': '2026-07-22T19:16:31.180063-04:00', 'column': 'user_id', 'result': {'status': 'Success', 'threshold_pass': True, 'message': 'All items passed the validation.', 'frame_row_number': 5, 'threshold': 0.0}}

2026-07-22 19:16:31.182 | ERROR    | validoopsie.validate:validate:406 - Failed validation: PatternMatch_email - The column 'email' has entries that do not match the pattern '^[^@]+@[^@]+\.[^@]+$'.

2026-07-22 19:16:31.182 | INFO     | validoopsie.validate:validate:414 - Passed validation: {'validation': 'ColumnValuesToBeBetween', 'impact': 'low', 'timestamp': '2026-07-22T19:16:31.181324-04:00', 'column': 'score', 'result': {'status': 'Success', 'threshold_pass': True, 'message': "The column 'score' has values that are not between 90 and 100.", 'failing_items': [78.3, 85.5, 88.7], 'failed_number': 3, 'frame_row_number': 5, 'threshold': 0.8, 'failed_percentage': 0.6}}

Validoopsie strikes a unique balance between operational flexibility and production reliability, making it an excellent choice for teams that need sophisticated failure handling without the complexity of larger validation frameworks.

Comparisons

Validoopsie’s functional approach contrasts with Pandera’s schema-centric methodology and Patito’s object-oriented models. While Pandera focuses on statistical validation and Patito emphasizes Pydantic integration, Validoopsie prioritizes flexibility and operational robustness.

Compared to Pointblank, both libraries offer sophisticated threshold-based failure handling using numeric values (e.g., 0.1 for 10% tolerance), but they differ in their architectural approach: Validoopsie combines numeric thresholds with impact levels (low/medium/high) that control the behavioral response to threshold breaches, while Pointblank integrates thresholds directly into its comprehensive reporting and alerting system. Both support custom validation, but Validoopsie uses a modular validation catalog approach while Pointblank’s specially() method integrates seamlessly with its step-by-step reporting workflow.

Validoopsie is the only library in this survey that provides built-in logging capabilities, making it particularly valuable for production environments where validation events need to be tracked and monitored.

The library’s Great Expectations inspiration is evident in its modular design, but Validoopsie delivers this functionality with a much lighter dependency footprint and simpler API. Teams familiar with Great Expectations will find Validoopsie’s approach familiar but more streamlined.

Unique Strengths and When to Use

Validoopsie’s standout features include:

  • graduated failure handling through impact levels (low/medium/high) combined with numeric thresholds that control both tolerance levels and behavioral responses to failures
  • numeric threshold tolerance allowing controlled acceptance of data quality issues (e.g., “allow 10% email format failures” with threshold=0.1)
  • built-in structured logging using loguru allows for automatic logging of validation results, failures, and performance metrics (unique among these libraries)
  • being a lightweight Great Expectations alternative with similar composability but minimal dependencies
  • an extensive validation catalog organized into logical namespaces (Date, String, Null, Values, etc.)
  • custom validation framework with consistent patterns for creating domain-specific rules

Choose Validoopsie when you need:

  • operational resilience in production pipelines where partial data quality issues shouldn’t stop processing
  • comprehensive validation logging and monitoring for observability in production environments
  • fine-grained control over validation failure behavior with different criticality levels
  • lightweight Great Expectations functionality without the complexity and dependencies
  • custom validation development with a clear, consistent framework
  • modular validation design that promotes reusability across projects

Validoopsie is particularly well-suited for data engineering teams building robust production pipelines where data quality monitoring is important but pipeline availability is critical. Its impact/threshold system makes it uniquely powerful for environments where you need to distinguish between “nice to have” and “must have” data quality requirements.

5. Dataframely: Type-Safe Schema Validation with Advanced Features

Dataframely is a comprehensive data validation framework that brings type-safe schema validation to Polars DataFrames with some of the most advanced features in the ecosystem. The library focuses on providing both runtime validation and static type checking, with particular strengths in collection validation for related DataFrames and extensive integration capabilities with external tools.

Dataframely launched in early 2025 with native Polars support as a core feature, built specifically for the modern data ecosystem with first-class support for complex validation scenarios.

Example

import polars as pl
import dataframely as dy

class UserSchema(dy.Schema):
    user_id = dy.Int64(primary_key=True, min=1, nullable=False)
    age = dy.Int64(nullable=False)
    email = dy.String(nullable=False, regex=r"^[^@]+@[^@]+\.[^@]+$")
    score = dy.Float64(nullable=False, min=0.0, max=100.0)

    # Use @dy.rule() for age range validation
    @dy.rule()
    def age_in_range(cls) -> pl.Expr:
        return pl.col("age").is_between(18, 80, closed="both")

# Validate using the schema
try:
    validated_data = UserSchema.validate(user_data, cast=True)
    print("Validation successful!")
    print(validated_data)
except Exception as e:
    print(f"Validation failed: {e}")

This example showcases Dataframely’s class-based schema approach with several notable features: primary key constraints, comprehensive type validation with bounds, regex pattern matching, and custom validation rules using the @dy.rule() decorator (used here for age range checking).

The cast=True parameter automatically coerces column types to match the schema definitions. This is really useful when working with data from external sources where column types might not exactly match your schema expectations (e.g., integers loaded as strings from CSV files).

Dataframely features soft validation and failure introspection. As one of Dataframely’s standout features, it brings a fairly sophisticated approach to validation failures. Rather than just raising exceptions, it provides detailed failure analysis:

# Soft validation: separate valid and invalid rows
good_data, failure_info = UserSchema.filter(user_data, cast=True)

print("Valid rows:", len(good_data))
print("Failure counts:", failure_info.counts())
print("Co-occurrence analysis:", failure_info.cooccurrence_counts())

# Inspect the actual failed rows
failed_rows = failure_info.invalid()
print("Failed data:", failed_rows)

Comparisons

While both Dataframely and Pandera offer schema-centric validation approaches, they serve different validation philosophies. Pandera excels in statistical validation with hypothesis testing and distribution checks, making it ideal for data science workflows where statistical properties matter. Dataframely, by contrast, emphasizes relational data integrity and type safety, providing more sophisticated failure analysis and collection-level validation capabilities that Pandera doesn’t offer.

The relationship between Dataframely and Patito is particularly interesting since both use class-based schema definitions. However, Dataframely extends far beyond Patito’s Pydantic-focused approach. Where Patito provides clean, simple validation with excellent Pydantic integration, Dataframely offers advanced features like collection validation, group rules, and comprehensive failure introspection. Teams already invested in Pydantic workflows might prefer Patito’s simplicity, while those building complex data systems will appreciate Dataframely’s feature set.

Dataframely and Pointblank represent two different approaches to comprehensive data validation. Pointblank shines in stakeholder communication with its beautiful interactive reports and threshold-based alerting systems, making it perfect for data quality reporting. Dataframely focuses instead on type safety and complex validation logic, with unique collection validation capabilities that no other library in this survey provides. The choice between these two will comes down to whether your priority is communicating validation results or ensuring complex data relationships remain consistent.

When compared to Validoopsie’s method chaining approach, Dataframely offers a more structured, schema-centric methodology with advanced type safety features that Validoopsie doesn’t provide. While Validoopsie excels in operational flexibility and lightweight design for building reusable validation components, Dataframely’s strength lies in its comprehensive type system integration, collection validation capabilities, and sophisticated failure analysis. And that makes it ideal for complex data engineering workflows where relationships between multiple DataFrames matter as much as individual DataFrame validation.

Unique Strengths and When to Use

Dataframely’s standout features include:

  • advanced type safety with full mypy integration and generic DataFrame types
  • collection validation for ensuring consistency across related DataFrames
  • group-based validation rules using @dy.rule(group_by=[...]) for aggregate constraints
  • schema inheritance for reducing code duplication in related schemas
  • production-ready soft validation that separates valid and invalid data

One might choose Dataframely when building complex data systems where:

  • type safety and static analysis are critical for code quality
  • you need to validate relationships between multiple related DataFrames
  • you’re working with production pipelines that need to handle partial data quality issues gracefully
  • schema reuse and inheritance would benefit your codebase organization

Dataframely is particularly well-suited for data engineering teams building robust, type-safe data pipelines where the relationships between different data entities are as important as the validation of individual DataFrames. Its collection validation capabilities make it uniquely powerful for ensuring referential integrity in complex data workflows.

Choosing the Right Library

With five solid validation libraries to choose from, the decision often comes down to your team’s specific workflow, existing tech stack, and validation requirements. Here are some practical considerations to help guide your choice:

Start with your existing tools

If you’re already using Pydantic extensively, Patito will feel natural. Teams that are heavily invested in type checking and statistical analysis should probably gravitate toward Pandera. If you’re building data products that need stakeholder buy-in, Pointblank’s reporting capabilities become incredibly useful in that context. For teams already committed to strong typing and static analysis workflows, Dataframely’s advanced type safety features will feel like a natural extension of your existing practices.

Consider your validation complexity

For straightforward schema validation and type checking, any of these libraries will work well. But if you need statistical hypothesis testing, Pandera is your best bet. For highly custom validation logic that needs to be composed and reused, Validoopsie shines. When validation results need to be communicated to non-technical stakeholders, Pointblank’s interactive reports are basically unmatched. If you’re dealing with complex relational data where multiple DataFrames need to maintain consistency with each other, Dataframely’s collection validation capabilities are unique in the ecosystem.

Think about failure tolerance requirements

One of the most important architectural differences among these libraries is how they handle validation failures. Only Pointblank and Validoopsie offer numeric threshold-based failure tolerance. This is the ability to accept a controlled percentage of validation failures without treating the entire validation as failed.

This distinction can be crucial for production environments where some level of data quality issues is acceptable and you need fine-grained control over when validations should fail versus warn. In many real-world scenarios, poor data quality is a given reality, and the goal becomes gradually improving quality over time rather than enforcing perfection. Thresholds can then be seen not as simple failure tolerances but more like data quality metrics and improvement goals (e.g., you might start with threshold=0.15 for email validation and progressively tighten to 0.05 as upstream systems improve).

Think about your team’s preferences

There’s a human dimension here. Some data teams might prefer the declarative, schema-first approach of Pandera, Patito, and Dataframely, whereas others like the step-by-step, method-chaining style of Pointblank and Validoopsie. There’s really no right or wrong choice here. It’s all about what feels right and most natural for your team’s coding style and mental model.

Don’t feel locked into one choice

My hunch is that many teams already successfully use different libraries for different parts of their data pipeline. They’re leveraging each tool’s strengths where they matter most. So you could conceivably use Patito for Pydantic-style validation, Pandera for statistical checks in your analysis pipeline, Pointblank for generating stakeholder reports, and Dataframely for complex data engineering workflows (use ’em all!). This multi-library approach can be particularly effective in larger organizations with diverse validation needs.

I suppose the key is to start with one library that fits your immediate needs, learn it well, and then consider expanding your toolkit as your validation requirements evolve.

Summary and Wrapping Up

The Python ecosystem offers truly excellent options for validating Polars DataFrames! Choosing is always tough but this is how one could make the decision based on specific needs:

  • for type-safe pipelines, Pandera, Dataframely, or Patito are ideal
  • for stakeholder reporting, Pointblank is a great choice
  • for row-level object modeling, go with Patito
  • for statistical validation, Pandera is perfect
  • for data quality improvement, Pointblank or Validoopsie fit well

Each library has evolved to serve different aspects of the data validation ecosystem. Try them all and, with a little understanding of their strengths, you’ll get good at picking the right data validation tool for your specific use case.

This survey represents our understanding of these libraries as of mid-2025. Given the rapid pace of development in the Python data ecosystem, some details may become outdated or contain inaccuracies (we may have even gotten things wrong at the outset). If you notice any errors or have updates to share, we’d love to hear from you! Please reach out through:

Any feedback you provide helps keep this resource accurate and useful for the community!

]]> https://posit-dev.github.io/pointblank/blog/validation-libs-2025/ Wed, 04 Jun 2025 00:00:00 GMT C’mon C’mon: Let’s Do a Pointblank Workshop! Rich Iannone https://posit-dev.github.io/pointblank/blog/lets-workshop-together/ Recently, I’ve been giving free workshops to data teams on Pointblank. These sorts of engagements energize me, and I truly enjoy hearing what people are concerned with when it comes to data validation. If your team is interested, I would love to schedule something with y’all! Please reach out at rich@posit.co or message me on the (Pointblank Discord).

Workshops have been especially helpful for understanding how people use and share Pointblank’s validation results table. For example, I learned that people like to email or pull up the table for stakeholders so they can walk through problem cases (it’s a great conversation starter for getting to the heart of data quality issues).

A couple of months ago, I gave a workshop to one of Apple’s data teams. During the Q&A afterwards, someone asked whether you can perform the same validation on different chunks of table rows. This was a very helpful nudge for me to add a segments= argument to all of Pointblank’s validation methods!

We are excited about how things are going with the Pointblank project and are always up for providing a workshop to your data team (at no cost). If this sounds interesting to you please feel free to contact me through email or via Discord. Don’t be shy. Just know that if you have a need for data validation, we’re here to help!

Acknowledgment

I’d like to give special thanks to Rami Krispin for his interest in Pointblank and for facilitating a recent workshop. If you’re interested in more data science insights, check out Rami’s Data Newsletter where he shares valuable perspectives on data engineering, LLMs, and analytics.

]]> https://posit-dev.github.io/pointblank/blog/lets-workshop-together/ Tue, 03 Jun 2025 00:00:00 GMT Overhauling Pointblank’s User Guide Rich Iannone and Michael Chow https://posit-dev.github.io/pointblank/blog/overhauled-user-guide/ The Pointblank documentation just got a major upgrade! We’ve completely overhauled our User Guide. Our goal was to enable readers to start fast on validation and work through the many pieces needed in realistic situations.

We realized that at the core of Pointblank is the validation plan. Its made up of rules, results, and steps.

For example, the first row is a step that checks whether values in column ‘a’ are less than 10. The COLUMNS and VALUES column contain the rules used to configure the step. The PASS column for the first row indicates that all 13 values in the column passed.

In this post, we’ll cover:

  • using a spiral sequence to balance introductory breadth with subsequent depth
  • improving examples with direct explanatory text
  • rounding out API coverage for cross-linking
  • surfacing advanced topics

Let us walk you through the key improvements in our refreshed User Guide!

Introduction: Embracing the Spiral Sequence

We chose to use a spiral sequence for our Introduction and Validation Plan section. The Introduction quickly covers parts of validation plan, while each article of the Validation Plan section dives deeper into different aspects of defining validation rules.

The introduction does a broad pass on the validation plan table diagram, identifying the core pieces of the output and then giving a quick overview of the code that produced it. This sets people up for the Validation Plan section in the guide, where each concept is discussed in depth.

Improving Examples

Examples are everywhere in the User Guide. We’ve tightened up our approach to examples by:

  • presenting example code, output, or both, early in each section
  • showing the actual output you’ll see in your environment
  • following up with explanatory text that guides attention to specific places in the output

This approach makes learning more intuitive. Here’s an excerpt that shows this in practice.

The blue arrow marks the flow of reading and the red arrows map where we anticipate people will look from the text to the output. Focusing explicitly on where we think attention will go forces us to think carefully about exactly what readers will get from the output. The hope is that readers get to work more quickly on new concepts.

Rounding Out API Coverage

Documentation has to balance jobs between a user guide and an API Reference:

  • User Guide: explains concepts that cut across functions (like common arguments across validation methods)
  • API Reference: explains each individual function

Importantly, user guides often link to the API reference so, as part of this work, we made sure that all individual API entries are well-documented and linked to from the guide. Here’s an excerpt from the User Guide that shows links marked:

Surfacing Advanced Topics

There’s a lot of potential slicing and dicing involved in validation, as well as work after validation (post interrogation) to make sense of the results. We added pages to the User Guide for some core situations. In this section, I’ll highlight two advanced topics we added pages for:

  • segmentation: splitting a column into groups, and validating each group
  • step reports: view failing cases (e.g., view rows of data that failed validation)

These are marked in the User Guide sidebar screenshot below:

Segmentation

Here’s a screenshot of a validation report with two validation steps, one for each segment ("low" and "high") in the f column of the small_table dataset.

Notice that segments split columns into groups and apply the same validation to each of the groups. Each group is given its own step.

Each of the 20+ validation methods accept a segment= argument. The value of the Segmentation article in the User Guide is to describe this cross-cutting behavior in a single place.

Compare the segments= parameter in the API Reference (e.g., look at col_vals_gt() and the Segmentation article to get a feel for how each location documents the segments feature.

Step Report

Step reports display failing cases (e.g., rows) for a validation step, so you can dig deeper into validation failures. Here’s a screenshot of a step report for some validation step 2:

Notice the arrow pointing to ‘Step 2’ in the title. Failing values are highlighted in red. Once we know we have failures, it’s important to take action and discover why data is failing. Looking at failing cases in step reports often uncovers obvious causes behind failures.

The get_step_report() entry is one of 50 in the API Reference. Here it is listed the API Reference, in the Interrogation and Reporting section. Critically, it’s only one of 20 entries in the User Guide, which emphasizes its importance in validation workflows.

Looking Forward

The refreshed User Guide is just the beginning of our documentation improvements. We’re committed to continuously enhancing our documentation to support your data validation needs.

Michael Chow gave feedback on this User Guide in preparation for his upcoming talk at SciPy 2025.

We’d love to hear your feedback on the new User Guide! Feel free to open an issue on our GitHub repository with suggestions, corrections, or requests for additional topics you’d like to see covered. You can also join our community discussions in the dedicated #Documentation channel on our Discord server, where you can share ideas, ask questions, and get help directly from the Pointblank team and other users.

]]> https://posit-dev.github.io/pointblank/blog/overhauled-user-guide/ Tue, 20 May 2025 00:00:00 GMT Level Up Your Data Validation with Actions and FinalActions Rich Iannone https://posit-dev.github.io/pointblank/blog/all-about-actions/ Data validation is only useful if you can respond appropriately when problems arise. That’s why Pointblank’s recent v0.8.0 and v0.8.1 releases have significantly enhanced our action framework, allowing you to create sophisticated, automated responses to validation failures.

In this post, we’ll explore how to use:

  1. Actions to respond to individual validation failures
  2. FinalActions to execute code after your entire validation plan completes
  3. New customization features that make your validation workflows more expressive

Let’s dive into how these features can transform your data validation process from passive reporting to active response.

From Passive Validation to Active Response

Traditional data validation simply reports problems: “Column X has invalid values.” But what if you want to:

  • send a Slack message when critical errors occur?
  • log detailed diagnostics about failing data?
  • trigger automatic data cleaning processes?
  • generate custom reports for stakeholders?

This is where Pointblank’s action system can help. By pairing thresholds with actions, you can create automated responses that trigger exactly when needed.

Getting Started with Actions

Actions are executed when validation steps fail to meet certain thresholds. Let’s start with a simple example:

import pointblank as pb

validation_1 = (
    pb.Validate(data=pb.load_dataset(dataset="small_table"))
    .col_vals_gt(
        columns="d",
        value=1000,
        thresholds=pb.Thresholds(warning=1, error=5),
        actions=pb.Actions(
            warning="⚠️ WARNING: Some values in column 'd' are below the minimum threshold!"
        )
    )
    .interrogate()
)

validation_1
⚠️ WARNING: Some values in column 'd' are below the minimum threshold!
Pointblank Validation
2026-07-22|23:16:17
Polars
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#EBBC14 1
col_vals_gt
col_vals_gt()
 d 1000 ✓ 13 7
0.54		 6
0.46		 ● ● —

In this example:

  1. we’re validating that values in column “d” are greater than 1000
  2. we set a warning threshold of 1 (triggers if any values fail)
  3. we define an action that prints a warning message when the threshold is exceeded

Since several values in column d are below 1000, our ‘warning’ action is triggered and the message appears above the validation report.

The Anatomy of Actions

The Actions class is a very important piece of Pointblank’s response system. Actions can be defined in several ways:

  1. String messages: simple text output to the console
  2. Callable functions: custom Python functions that execute when triggered
  3. Lists of strings/callables: multiple actions that execute in sequence

Actions can be paired with different severity levels:

  • ‘warning’: for minor issues that need attention
  • ‘error’: for more significant problems
  • ‘critical’: for severe issues that require immediate action

The v0.8.0 release added two (very) useful new parameters:

  • default=: apply the same action to all threshold levels
  • highest_only=: only trigger the action for the highest threshold level reached (True by default)

Let’s see how these work in practice:

def log_problem():
    # Simple action that runs when thresholds are exceeded
    print("A validation threshold has been exceeded!")

validation_2 = (
    pb.Validate(
        data=pb.load_dataset(dataset="game_revenue"),
        thresholds=pb.Thresholds(warning=0.05, error=0.10, critical=0.15),
        actions=pb.Actions(default=log_problem)  # Apply this action to all threshold levels
    )
    .col_vals_regex(
        columns="player_id",
        pattern=r"[A-Z]{12}\d{3}"
    )
    .col_vals_gt(
        columns="item_revenue",
        value=0.10
    )
    .interrogate()
)

validation_2
A validation threshold has been exceeded!
Pointblank Validation
2026-07-22|23:16:17
PolarsWARNING0.05ERROR0.1CRITICAL0.15
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#4CA64C 1
col_vals_regex
col_vals_regex()
 player_id [A-Z]{12}\d{3} ✓ 2000 2000
1.00		 0
0.00		 ○ ○ ○ —
#FF3300 2
col_vals_gt
col_vals_gt()
 item_revenue 0.1 ✓ 2000 1440
0.72		 560
0.28		 ● ● ●

In this example, we’re using a simple function that prints a generic message whenever any threshold is exceeded. By using the Actions(default=) parameter, this same function gets applied to all threshold levels (‘warning’, ‘error’, and ‘critical’). This saves you from having to define separate actions for each level when you want the same behavior for all of them. The highest_only= parameter (True by default, so not shown here) is complementary and it ensures that only the action for the highest threshold level reached will be triggered, preventing multiple notifications for the same validation failure.

Dynamic Messages with Templating

Actions don’t have to be static messages. With Pointblank’s templating system, you can create context-aware notifications that include details about the specific validation failure.

Available placeholders include:

  • {type}: the validation step type (e.g., "col_vals_gt")
  • {level}: the threshold level (‘warning’, ‘error’, ‘critical’)
  • {step} or {i}: the step number in the validation workflow
  • {col} or {column}: the column name being validated
  • {val} or {value}: the comparison value used in the validation
  • {time}: when the action was executed

You can also capitalize placeholders (like {LEVEL}) to get uppercase text.

action_template = "[{LEVEL}] Step {step}: Values in '{column}' failed validation against {value}."

validation_3 = (
    pb.Validate(
        data=pb.load_dataset(dataset="small_table"),
        thresholds=pb.Thresholds(warning=1, error=4, critical=10),
        actions=pb.Actions(default=action_template)
    )
    .col_vals_lt(
        columns="d",
        value=3000
    )
    .interrogate()
)

validation_3
[ERROR] Step 1: Values in 'd' failed validation against 3000.
Pointblank Validation
2026-07-22|23:16:17
PolarsWARNING1ERROR4CRITICAL10
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#EBBC14 1
col_vals_lt
col_vals_lt()
 d 3000 ✓ 13 9
0.69		 4
0.31		 ● ● ○

This templating approach is a great way to create context-aware notifications that adapt to the specific validation failures occurring. As the example shows, when values in column d fail validation against the limit of 3000, the template automatically generates a meaningful error message showing exactly which step, column, and threshold value was involved.

Accessing Metadata in Custom Action Functions

For more sophisticated actions, you often need access to details about the validation failure. The get_action_metadata() function provides this context when called inside an action function:

def send_detailed_alert():
    # Get metadata about the validation failure
    metadata = pb.get_action_metadata()

    # Create a customized alert message
    print(f"""
    VALIDATION FAILURE DETAILS
    -------------------------
    Step: {metadata['step']}
    Column: {metadata['column']}
    Validation type: {metadata['type']}
    Severity: {metadata['level']} (level {metadata['level_num']})
    Time: {metadata['time']}

    Explanation: {metadata['failure_text']}
    """)

validation_4 = (
    pb.Validate(
        data=pb.load_dataset(dataset="small_table"),
        thresholds=pb.Thresholds(critical=1),
        actions=pb.Actions(critical=send_detailed_alert)
    )
    .col_vals_gt(
        columns="d",
        value=5000
    )
    .interrogate()
)

validation_4

    VALIDATION FAILURE DETAILS
    -------------------------
    Step: 1
    Column: d
    Validation type: col_vals_gt
    Severity: critical (level 50)
    Time: 2026-07-22 23:16:17.724732+00:00

    Explanation: Exceedance of failed test units where values in `d` should have been > `5000`.
Pointblank Validation
2026-07-22|23:16:17
PolarsWARNING—ERROR—CRITICAL1
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#FF3300 1
col_vals_gt
col_vals_gt()
 d 5000 ✓ 13 1
0.08		 12
0.92		 — — ●

The metadata dictionary contains essential fields for a given validation step, including the step number, column name, validation type, severity level, and failure explanation. This gives you complete flexibility to create highly customized responses based on the specific nature of the validation failure.

Final Actions with FinalActions

While regular Actions are great for responding to individual validation steps, sometimes you need to take action based on the overall validation results. This is where the new FinalActions feature from v0.8.1 comes in.

Unlike regular Actions that trigger during validation, FinalActions execute after all validation steps are complete. FinalActions accepts any number of actions (strings or callables) and executes them in sequence. Each argument can be a string message to display in the console, a callable function, or a list of strings/callables for multiple actions to execute in sequence.

The real power of FinalActions comes from the ability to access comprehensive information about your validation results using get_validation_summary(). When called inside a function passed to FinalActions, this function provides a dictionary containing counts of passing/failing steps and test units, threshold levels exceeded, and much more:

def generate_summary():
    # Access comprehensive validation results
    summary = pb.get_validation_summary()

    print("\n=== VALIDATION SUMMARY ===")
    print(f"Total steps: {summary['n_steps']}")
    print(f"Passing steps: {summary['n_passing_steps']}")
    print(f"Failing steps: {summary['n_failing_steps']}")

    if summary['highest_severity'] == "critical":
        print("\n⚠️ CRITICAL FAILURES DETECTED - immediate action required!")
    elif summary['highest_severity'] == "error":
        print("\n⚠️ ERRORS DETECTED - review needed")
    elif summary['highest_severity'] == "warning":
        print("\n⚠️ WARNINGS DETECTED - please investigate")
    else:
        print("\n✅ All validations passed!")

validation_5 = (
    pb.Validate(
        data=pb.load_dataset(dataset="small_table"),
        tbl_name="small_table",
        thresholds=pb.Thresholds(warning=1, error=5, critical=10),
        final_actions=pb.FinalActions(
            "Validation process complete.",  # A simple string message
            generate_summary               # Our function using get_validation_summary()
        )
    )
    .col_vals_gt(columns="a", value=1)
    .col_vals_lt(columns="d", value=10000)
    .interrogate()
)

validation_5
Validation process complete.

=== VALIDATION SUMMARY ===
Total steps: 2
Passing steps: 1
Failing steps: 1

⚠️ WARNINGS DETECTED - please investigate
Pointblank Validation
2026-07-22|23:16:17
Polarssmall_tableWARNING1ERROR5CRITICAL10
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#AAAAAA 1
col_vals_gt
col_vals_gt()
 a 1 ✓ 13 12
0.92		 1
0.08		 ● ○ ○
#4CA64C 2
col_vals_lt
col_vals_lt()
 d 10000 ✓ 13 13
1.00		 0
0.00		 ○ ○ ○ —

The get_validation_summary() function is only available within functions passed to FinalActions. It gives you access to these key dictionary fields:

  • tbl_name: name of the validated table
  • n_steps: total number of validation steps
  • n_passing_steps, n_failing_steps: count of passing/failing steps
  • n, n_passed, n_failed: total test units and their pass/fail counts
  • highest_severity: the most severe threshold level reached (‘warning’, ‘error’, ‘critical’)
  • and many more detailed statistics

This information allows you to create detailed and specific final actions that can respond appropriately to the overall validation results.

Combining Regular and Final Actions

You can use both Actions and FinalActions together for comprehensive control over your validation workflow:

def step_alert():
    metadata = pb.get_action_metadata()
    print(f"Step {metadata['step']} failed with {metadata['level']} severity")


def final_summary():
    summary = pb.get_validation_summary()

    # Get counts by checking each step's status in the dictionaries
    steps = range(1, summary['n_steps'] + 1)
    n_critical = sum(1 for step in steps if summary['dict_critical'].get(step, False))
    n_error = sum(1 for step in steps if summary['dict_error'].get(step, False))
    n_warning = sum(1 for step in steps if summary['dict_warning'].get(step, False))

    print(f"\nValidation complete with:")
    print(f"- {n_critical} critical issues")
    print(f"- {n_error} errors")
    print(f"- {n_warning} warnings")


validation_6 = (
    pb.Validate(
        data=pb.load_dataset(dataset="small_table"),
        thresholds=pb.Thresholds(warning=1, error=5, critical=10),
        actions=pb.Actions(default=step_alert),
        final_actions=pb.FinalActions(final_summary),
    )
    .col_vals_gt(columns="a", value=5)
    .col_vals_lt(columns="d", value=1000)
    .interrogate()
)

validation_6
Step 1 failed with critical severity
Step 2 failed with error severity

Validation complete with:
- 1 critical issues
- 2 errors
- 2 warnings
Pointblank Validation
2026-07-22|23:16:17
PolarsWARNING1ERROR5CRITICAL10
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#FF3300 1
col_vals_gt
col_vals_gt()
 a 5 ✓ 13 3
0.23		 10
0.77		 ● ● ●
#EBBC14 2
col_vals_lt
col_vals_lt()
 d 1000 ✓ 13 6
0.46		 7
0.54		 ● ● ○

This approach allows you to log individual step failures during the validation process using Actions and generate a comprehensive report after all validation steps are complete using FinalActions. Using both action types gives you fine-grained control over when and how notifications and other actions are triggered in your validation workflow.

Real-World Example: Building an Automated Validation Pipeline

Let’s put everything together in a more realistic example. Imagine you’re validating a gaming revenue dataset and want to:

  1. log detailed information about each failure
  2. send a Slack notification if critical failures occur
  3. generate a comprehensive report after validation completes
def log_step_failure():
    metadata = pb.get_action_metadata()
    print(f"[{metadata['level'].upper()}] Step {metadata['step']}: {metadata['failure_text']}")

def analyze_results():
    summary = pb.get_validation_summary()

    # Calculate overall pass rate
    pass_rate = (summary['n_passing_steps'] / summary['n_steps']) * 100

    print(f"\n==== VALIDATION RESULTS ====")
    print(f"Table: {summary['tbl_name']}")
    print(f"Pass rate: {pass_rate:.2f}%")
    print(f"Failing steps: {summary['n_failing_steps']} of {summary['n_steps']}")

    # In a real scenario, here you might:
    # 1. Save results to a database
    # 2. Generate and email an HTML report
    # 3. Trigger data cleansing workflows

    # Simulate a Slack notification
    if summary['highest_severity'] == "critical":
        print("\n🚨 [SLACK NOTIFICATION] Critical data quality issues detected!")
        print("@data-team Please investigate immediately.")

# Create our validation workflow with actions
validation_7 = (
    pb.Validate(
        data=pb.load_dataset(dataset="game_revenue"),
        tbl_name="game_revenue",
        thresholds=pb.Thresholds(warning=0.05, error=0.10, critical=0.15),
        actions=pb.Actions(default=log_step_failure, highest_only=True),
        final_actions=pb.FinalActions(analyze_results),
        brief=True  # Add automatically-generated briefs
    )
    .col_vals_regex(
        columns="player_id",
        pattern=r"[A-Z]{12}\d{3}",
        brief="Player IDs must follow standard format"  # Custom brief text
    )
    .col_vals_gt(
        columns="item_revenue",
        value=0.10
    )
    .col_vals_gt(
        columns="session_duration",
        value=15
    )
    .interrogate()
)

validation_7
[CRITICAL] Step 2: Exceedance of failed test units where values in `item_revenue` should have been > `0.1`.
[CRITICAL] Step 3: Exceedance of failed test units where values in `session_duration` should have been > `15`.

==== VALIDATION RESULTS ====
Table: game_revenue
Pass rate: 33.33%
Failing steps: 2 of 3

🚨 [SLACK NOTIFICATION] Critical data quality issues detected!
@data-team Please investigate immediately.
Pointblank Validation
2026-07-22|23:16:17
Polarsgame_revenueWARNING0.05ERROR0.1CRITICAL0.15
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#4CA64C 1
col_vals_regex
col_vals_regex()

Player IDs must follow standard format

 player_id [A-Z]{12}\d{3} ✓ 2000 2000
1.00		 0
0.00		 ○ ○ ○ —
#FF3300 2
col_vals_gt
col_vals_gt()

Expect that values in item_revenue should be > 0.1.

 item_revenue 0.1 ✓ 2000 1440
0.72		 560
0.28		 ● ● ●
#FF3300 3
col_vals_gt
col_vals_gt()

Expect that values in session_duration should be > 15.

 session_duration 15 ✓ 2000 1675
0.84		 325
0.16		 ● ● ●

Wrapping Up: from Passive Validation to Active Data Quality Management

With Actions and FinalActions, Pointblank is now more of a complete data quality management system. Instead of just detecting problems, you can now:

  1. respond immediately to validation failures
  2. customize responses based on severity level
  3. generate comprehensive reports after validation completes
  4. integrate with other systems through custom action functions
  5. automate workflows based on validation results

These capabilities transform data validation from a passive reporting activity into an active component of your data pipeline, helping ensure that data quality issues are detected, reported, and addressed efficiently.

As we continue to enhance Pointblank, we’d love to hear how you’re using Actions and FinalActions in your workflows. Share your experiences or suggestions with us on Discord or file an issue on GitHub.

Learn More

Explore our documentation to learn more about Pointblank’s action capabilities:

]]> https://posit-dev.github.io/pointblank/blog/all-about-actions/ Fri, 02 May 2025 00:00:00 GMT Introducing Pointblank Rich Iannone https://posit-dev.github.io/pointblank/blog/intro-pointblank/ If you have tabular data (and who doesn’t?) this is the package for you! I’ve long been interested in data quality and so I’ve spent a lot of time building tooling that makes it possible to perform data quality checks. And there’s so many reasons to care about data quality. If I were to put down just one good reason for why data quality is worth your time it is because having good data quality strongly determines the quality of decisions.

Having the ability to distinguish bad data from good data is the first step in solving DQ issues, and the sustained practice of doing data validation will guard against intrusions of poor-quality data. Pointblank has been designed to really help here. Though it’s a fairly new package it is currently quite capable. And it’s available in PyPI, so you can install it by using:

pip install pointblank
Note

To run the examples in this post, you’ll need to have a DataFrame library installed. Pointblank works seamlessly with both Polars and Pandas but you’ll need to install at least one of them on your own. We also have a DuckDB example that’s running via Ibis (so, you’ll have to install Ibis with the DuckDB backend for that to work).

How Pointblank Transforms Your Data Validation Workflow

What sets Pointblank apart is its intuitive, expressive approach to data validation. Rather than writing dozens of ad-hoc checks scattered throughout your codebase, Pointblank lets you define a comprehensive validation plan with just a few lines of code. The fluent API makes your validation intentions crystal clear, whether you’re ensuring numeric values fall within expected ranges, text fields match specific patterns, or relationships between columns remain consistent.

But say you find problems. What are you gonna do about it? Well, Pointblank wants to help at not just finding problems but helping you understand them. When validation failures occur, the detailed reporting capabilities (in the form of beautiful, sharable tables) show you exactly where issues are. Right down to the specific rows and columns. This transforms data validation from a binary pass/fail exercise into a super-insightful diagnostic tool.

Here’s the the best part: Pointblank is designed to work with your existing data stack. Whether you’re using Polars, Pandas, DuckDB, or other database systems, Pointblank tries hard to integrate without forcing you to change your workflow. We also have international spoken language support for reporting, meaning that validation reports can be localized to your team’s preferred language. This making data quality accessible to everyone in your organization (like a team sport!).

Alright! Let’s look at a few demonstrations of Pointblank’s capabilities for data validation.

The Data Validation Workflow

Let’s get right to performing a basic check of a Polars DataFrame. We’ll make use of the included small_table dataset.

import pointblank as pb

small_table = pb.load_dataset(dataset="small_table", tbl_type="polars")

validation_1 = (
    pb.Validate(
        data=small_table,
        tbl_name="small_table",
        label="Example Validation"
    )
    .col_vals_lt(columns="a", value=10)
    .col_vals_between(columns="d", left=0, right=5000)
    .col_vals_in_set(columns="f", set=["low", "mid", "high"])
    .col_vals_regex(columns="b", pattern=r"^[0-9]-[a-z]{3}-[0-9]{3}$")
    .interrogate()
)

validation_1
Pointblank Validation
Example Validation
Polarssmall_table
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#4CA64C 1
col_vals_lt
col_vals_lt()
 a 10 ✓ 13 13
1.00		 0
0.00		 — — — —
#4CA64C66 2
col_vals_between
col_vals_between()
 d [0, 5000] ✓ 13 12
0.92		 1
0.08		 — — —
#4CA64C 3
col_vals_in_set
col_vals_in_set()
 f low, mid, high ✓ 13 13
1.00		 0
0.00		 — — — —
#4CA64C 4
col_vals_regex
col_vals_regex()
 b ^[0-9]-[a-z]{3}-[0-9]{3}$ ✓ 13 13
1.00		 0
0.00		 — — — —
2026-07-22 23:16:23 UTC< 1 s2026-07-22 23:16:23 UTC

There’s a lot to take in here so let’s break down the code first! Note these three key pieces:

  • the Validate(data=...) argument takes a DataFrame (or database table) that you want to validate
  • the methods starting with col_* specify validation steps that run on specific columns
  • the interrogate() method executes the validation plan on the table (it’s the finishing step)

This common pattern is used in a validation workflow, where Validate and interrogate() bookend a validation plan generated through calling validation methods.

Now, onto the result: it’s a table! Naturally, we’re using the awesome Great Tables package here in Pointblank to really give you the goods on how the validation went down. Each row in this reporting table represents a single validation step (one for each invocation of a col_vals_*() validation method). Generally speaking, the left side of the validation report tables outlines the key validation rules, and the right side provides the results of each validation step.

We tried to keep it simple in principle, but a lot of useful information can be packed into this validation table. Here’s a diagram that describes a few of the important parts of the validation report table:

All of those numbers under the UNITS, PASS, and FAIL columns have to do with test units, a measure of central importance in Pointblank. Each validation step will execute a type of validation test on the target table. For example, a col_vals_lt() validation step can test that each value in a column is less than a specified number. The key finding that’s reported as a result of this test is the number of test units that pass or fail. This little diagram explains what those numbers mean:

Failing test units can be tied to threshold levels, which can provide a better indication of whether failures should raise some basic awareness or spur you into action. Here’s a validation workflow that sets three failure threshold levels that signal the severity of data quality problems:

import pointblank as pb
import polars as pl

validation_2 = (
    pb.Validate(
        data=pb.load_dataset(dataset="game_revenue", tbl_type="polars"),
        tbl_name="game_revenue",
        label="Data validation with threshold levels set.",
        thresholds=pb.Thresholds(warning=1, error=20, critical=0.10),
    )
    .col_vals_regex(columns="player_id", pattern=r"^[A-Z]{12}[0-9]{3}$")        # STEP 1
    .col_vals_gt(columns="session_duration", value=5)                           # STEP 2
    .col_vals_ge(columns="item_revenue", value=0.02)                            # STEP 3
    .col_vals_in_set(columns="item_type", set=["iap", "ad"])                    # STEP 4
    .col_vals_in_set(                                                           # STEP 5
        columns="acquisition",
        set=["google", "facebook", "organic", "crosspromo", "other_campaign"]
    )
    .col_vals_not_in_set(columns="country", set=["Mongolia", "Germany"])        # STEP 6
    .col_vals_between(                                                          # STEP 7
        columns="session_duration",
        left=10, right=50,
        pre = lambda df: df.select(pl.median("session_duration"))
    )
    .rows_distinct(columns_subset=["player_id", "session_id", "time"])          # STEP 8
    .row_count_match(count=2000)                                                # STEP 9
    .col_exists(columns="start_day")                                            # STEP 10
    .interrogate()
)

validation_2
Pointblank Validation
Data validation with threshold levels set.
Polarsgame_revenueWARNING1ERROR20CRITICAL0.1
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#4CA64C 1
col_vals_regex
col_vals_regex()
 player_id ^[A-Z]{12}[0-9]{3}$ ✓ 2000 2000
1.00		 0
0.00		 ○ ○ ○ —
#AAAAAA 2
col_vals_gt
col_vals_gt()
 session_duration 5 ✓ 2000 1982
0.99		 18
0.01		 ● ○ ○
#EBBC14 3
col_vals_ge
col_vals_ge()
 item_revenue 0.02 ✓ 2000 1941
0.97		 59
0.03		 ● ● ○
#4CA64C 4
col_vals_in_set
col_vals_in_set()
 item_type iap, ad ✓ 2000 2000
1.00		 0
0.00		 ○ ○ ○ —
#EBBC14 5
col_vals_in_set
col_vals_in_set()
 acquisition google, facebook, organic, crosspromo, other_campaign ✓ 2000 1975
0.99		 25
0.01		 ● ● ○
#FF3300 6
col_vals_not_in_set
col_vals_not_in_set()
 country Mongolia, Germany ✓ 2000 1775
0.89		 225
0.11		 ● ● ●
#4CA64C 7
col_vals_between
col_vals_between()
 session_duration [10, 50] ✓ 1 1
1.00		 0
0.00		 ○ ○ ○ —
#EBBC14 8
rows_distinct
rows_distinct()
 player_id, session_id, time — ✓ 2000 1978
0.99		 22
0.01		 ● ● ○
#4CA64C 9
row_count_match
row_count_match()
 — 2000 ✓ 1 1
1.00		 0
0.00		 ○ ○ ○ —
#4CA64C 10
col_exists
col_exists()
 start_day — ✓ 1 1
1.00		 0
0.00		 ○ ○ ○ —
2026-07-22 23:16:23 UTC< 1 s2026-07-22 23:16:23 UTC
Notes

Step 7 (pre_applied) Precondition applied: table dimensions [2,000 rows, 11 columns] → [1 row, 1 column].

This data validation makes use of the many validation methods available in the library. Because thresholds have been set at the Validate(thresholds=) parameter, we can now see where certain validation steps have greater amounts of failures. Any validation steps with green indicators passed with flying colors, whereas: (1) gray indicates the ‘warning’ condition was met (at least one test unit failing), (2) yellow is for the ‘error’ condition (20 or more test units failing), and (3) red means ‘critical’ and that’s tripped when 10% of all test units are failing ones.

Reporting tables are essential to the package and they help communicate what went wrong (or well) in a validation workflow. Now let’s look at some additional reporting that Pointblank can give you to better understand where things might’ve gone wrong.

Reporting for Individual Validation Steps

The second validation step of the previous data validation showed 18 failing test units. That translates to 18 spots in a 2,000 row DataFrame where a data quality assertion failed. We often would like to know exactly what that failing data is; it’s usually the next step toward addressing data quality issues.

Pointblank offers a method that gives you a tabular report on a specific step: get_step_report(). The previous tables you’ve seen (the validation report table) dealt with providing a summary of all validation steps. In contrast, a focused report on a single step can help to get to the heart of a data quality issue. Here’s how that looks for Step 2:

validation_2.get_step_report(i=2)
Report for Validation Step 2
ASSERTION session_duration > 5
18 / 2000 TEST UNIT FAILURES IN COLUMN 8
EXTRACT OF FIRST 10 ROWS (WITH TEST UNIT FAILURES IN RED):
player_id
String
session_id
String
session_start
Datetime
time
Datetime
item_type
String
item_name
String
item_revenue
Float64
session_duration
Float64
start_day
Date
acquisition
String
country
String
549 QNLVRDEOXFYJ892 QNLVRDEOXFYJ892-lz5fmr6k 2015-01-10 16:44:17+00:00 2015-01-10 16:45:29+00:00 iap gold3 3.49 3.7 2015-01-09 crosspromo Australia
620 RMOSWHJGELCI675 RMOSWHJGELCI675-t4y8bjcu 2015-01-11 07:24:24+00:00 2015-01-11 07:25:18+00:00 iap offer4 17.991 5.0 2015-01-10 other_campaign France
621 RMOSWHJGELCI675 RMOSWHJGELCI675-t4y8bjcu 2015-01-11 07:24:24+00:00 2015-01-11 07:26:24+00:00 iap offer5 26.09 5.0 2015-01-10 other_campaign France
622 RMOSWHJGELCI675 RMOSWHJGELCI675-t4y8bjcu 2015-01-11 07:24:24+00:00 2015-01-11 07:28:36+00:00 ad ad_15sec 0.53 5.0 2015-01-10 other_campaign France
663 GFLYJHAPMZWD631 GFLYJHAPMZWD631-i2v1bl7a 2015-01-11 16:13:24+00:00 2015-01-11 16:14:54+00:00 iap gems2 3.99 3.6 2015-01-09 organic India
772 BFNLURISJXTH647 BFNLURISJXTH647-6o5hx27z 2015-01-12 17:37:39+00:00 2015-01-12 17:39:27+00:00 iap offer5 11.59 4.1 2015-01-10 organic India
773 BFNLURISJXTH647 BFNLURISJXTH647-6o5hx27z 2015-01-12 17:37:39+00:00 2015-01-12 17:41:45+00:00 iap gems3 9.99 4.1 2015-01-10 organic India
908 KILWZYHRSJEG316 KILWZYHRSJEG316-uke7dhqj 2015-01-13 22:16:29+00:00 2015-01-13 22:17:35+00:00 iap offer2 10.99 3.2 2015-01-04 organic Denmark
1037 JUBDVFHCNQWT198 JUBDVFHCNQWT198-9h4xs2pb 2015-01-14 16:08:25+00:00 2015-01-14 16:08:43+00:00 iap offer5 8.69 3.3 2015-01-14 organic Philippines
1038 JUBDVFHCNQWT198 JUBDVFHCNQWT198-9h4xs2pb 2015-01-14 16:08:25+00:00 2015-01-14 16:11:01+00:00 iap offer4 5.99 3.3 2015-01-14 organic Philippines

This report provides the 18 rows where the failure occurred. If you scroll the table to the right you’ll see the column that underwent testing (session_duration) is highlighted in red. All of these values are 5.0 or less, which is in violation of the assertion (in the header) that session_duration > 5.

These types of bespoke reports are useful for finding a needle in a haystack. Another good use for a step report is when validating a table schema. Using the col_schema_match() validation method with a table schema prepared with the Schema class allows us to verify our understanding of the table structure. Here is a validation that performs a schema validation with the small_table dataset prepared as a DuckDB table:

import pointblank as pb

# Create a schema for the target table (`small_table` as a DuckDB table)
schema = pb.Schema(
    columns=[
        ("date_time", "timestamp(6)"),
        ("dates", "date"),
        ("a", "int64"),
        ("b",),
        ("c",),
        ("d", "float64"),
        ("e", ["bool", "boolean"]),
        ("f", "str"),
    ]
)

# Use the `col_schema_match()` validation method to perform a schema check
validation_3 = (
    pb.Validate(
        data=pb.load_dataset(dataset="small_table", tbl_type="duckdb"),
        tbl_name="small_table",
        label="Schema check"
    )
    .col_schema_match(schema=schema)
    .interrogate()
)

validation_3
Pointblank Validation
Schema check
DuckDBsmall_table
STEP COLUMNS VALUES TBL EVAL UNITS PASS FAIL W E C EXT
#4CA64C66 1
col_schema_match
col_schema_match()
 — SCHEMA ✓ 1 0
0.00		 1
1.00		 — — — —
2026-07-22 23:16:23 UTC< 1 s2026-07-22 23:16:23 UTC
Notes

Step 1 (schema_check) ✗ Schema validation failed: 1 unmatched column(s), 1 dtype mismatch(es).

Schema Comparison
TARGET EXPECTED
COLUMN DATA TYPE COLUMN DATA TYPE
1 date_time timestamp(6) 1 date_time ✓ timestamp(6) ✓
2 date date 2 dates ✗ date —
3 a int64 3 a ✓ int64 ✓
4 b string 4 b ✓ —
5 c int64 5 c ✓ —
6 d float64 6 d ✓ float64 ✓
7 e boolean 7 e ✓ bool | boolean ✓
8 f string 8 f ✓ str ✗
Supplied Column Schema:
[('date_time', 'timestamp(6)'), ('dates', 'date'), ('a', 'int64'), ('b',), ('c',), ('d', 'float64'), ('e', ['bool', 'boolean']), ('f', 'str')]
Schema Match Settings
COMPLETE
IN ORDER
COLUMN ≠ column
DTYPE ≠ dtype
float ≠ float64

This step fails, but the validation report table doesn’t tell us how (or where). Using get_step_report() will show us what the underlying issues are:

validation_3.get_step_report(i=1)
Report for Validation Step 1 ✗
COLUMN SCHEMA MATCH
COMPLETE
IN ORDER
COLUMN ≠ column
DTYPE ≠ dtype
float ≠ float64
TARGET EXPECTED
COLUMN DATA TYPE COLUMN DATA TYPE
1 date_time timestamp(6) 1 date_time ✓ timestamp(6) ✓
2 date date 2 dates ✗ date —
3 a int64 3 a ✓ int64 ✓
4 b string 4 b ✓ —
5 c int64 5 c ✓ —
6 d float64 6 d ✓ float64 ✓
7 e boolean 7 e ✓ bool | boolean ✓
8 f string 8 f ✓ str ✗
Supplied Column Schema:
[('date_time', 'timestamp(6)'), ('dates', 'date'), ('a', 'int64'), ('b',), ('c',), ('d', 'float64'), ('e', ['bool', 'boolean']), ('f', 'str')]

The step report here shows the target table’s schema on the left side and the expectation of the schema on the right side. There appears to be two problems with our supplied schema:

  1. the second column is actually date instead of dates
  2. the dtype of the f column is "string" and not "str"

The convenience of this step report means we only have to look at one display of information, rather than having to collect up the individual pieces and make careful comparisons.

Much More in Store

Pointblank tries really hard to make it easy for you to test your data. All sorts of input tables are supported since we integrate with the brilliant Narwhals and Ibis libraries. And even through the project has only started four months ago, we already have an extensive catalog of well-tested validation methods.

We care a great deal about documentation so much recent effort has been placed on getting the User Guide written. We hope it provides for gentle introduction to the major features of the library. If you want some quick examples to get your imagination going, check out our gallery of examples.

We really care about what you want in a validation package, so talk to us :) We just started a Discord so feel free to hop on and ask us anything. Alternatively, we always like to get issues so don’t be shy in letting us know how we could improve!

]]> https://posit-dev.github.io/pointblank/blog/intro-pointblank/ Fri, 04 Apr 2025 00:00:00 GMT