Skip to main content

Data Reliability Index

Data Reliability Index icon

CI PyPI Python Versions License GitHub Release Typed

Data Reliability Index core features infographic

Data Reliability Index is a typed Python SDK for classifying the reliability of measured, collected, derived, or user-submitted data before it is used for analysis, databases, APIs, machine learning, or scientific conclusions.

The project starts from a practical problem: many datasets contain values that are treated as facts even though their source, calibration, provenance, verification history, uncertainty, or integrity is unknown. In real workflows, measured data is often copied into databases, dashboards, research notebooks, and models without every data point being classified by reliability. That makes later analysis fragile, because high-quality measurements, partially verified records, historical observations, and weakly sourced submissions can all be mixed together as if they had the same evidential value.

Data Reliability Index is built around a simple rule: every data point should carry the evidence needed to decide whether it is safe to use. Each record should be scored, assigned a trust tier, linked to provenance and audit metadata, and filtered by explicit policy before it influences decisions. Without this kind of reliability classification, analysis can become difficult to reproduce, hard to defend, and scientifically weak because the trust level of the underlying data was never verified.

Supported Python versions: 3.9 through 3.14.

Release Status

Latest release: v0.7.0

The v0.7.0 release adds mandatory reference-check policies and stricter validation of quality evidence. Wheels and source distributions are published on PyPI with artifact provenance attestations by the release workflow.

Features

  • Pydantic models for reliability metadata and policies.
  • Scanning engine for computing reliability scores from validation evidence.
  • Tiered trust classification with scores from 0 to 100.
  • Automatic trust-tier assignment from score and verification signals.
  • Trace hash computation and verification support.
  • HMAC-SHA256 signature verification for authenticated payload integrity.
  • Policy-based acceptance checks for individual records.
  • Structured accept/reject decisions for audits and ingestion logs.
  • Evidence templates for common source types.
  • Driver-neutral database helpers for SQL, analytical, and document stores.
  • Batch and streaming row scanning for small files and large datasets.
  • Optional Pandas helpers for filtering DataFrames by reliability metadata.
  • FastAPI example for rejecting low-reliability input at ingestion time.
  • CLI for scanning JSON and JSONL records.
  • MkDocs documentation for concepts and API usage.

Installation

Install from PyPI:

pip install data-reliability-index

Optional integrations:

pip install "data-reliability-index[pandas]"
pip install "data-reliability-index[api]"
pip install "data-reliability-index[postgres]"
pip install "data-reliability-index[mysql]"
pip install "data-reliability-index[duckdb]"
pip install "data-reliability-index[mongo]"
pip install "data-reliability-index[polars]"
pip install "data-reliability-index[arrow]"

To pin the release version:

pip install data-reliability-index==0.7.0

For local development from this repository:

pip install -e ".[test]"

Quick Start

from data_reliability import (
    DataTier, ReliabilityPolicy, ReliabilityScanner, ValidationEvidence,
    compare_to_reference, evidence_from_reference_comparison,
)

scanner = ReliabilityScanner()
value = {"temperature": 21.4, "unit": "celsius"}
# Define the reference and tolerance before inspecting the observation.
comparison = compare_to_reference(
    value, reference=21.5, tolerance=0.2, field="temperature",
    reference_id="lab-baseline-v1", unit="celsius",
)
evidence = evidence_from_reference_comparison(
    comparison,
    # These illustrative inputs must come from your actual validation checks.
    base=ValidationEvidence(provenance=1.0, calibration=1.0),
)

data = scanner.scan(
    value,
    source_id="sensor-a",
    evidence=evidence,
)

policy = ReliabilityPolicy(
    minimum_score=70,
    maximum_tier=DataTier.TIER_2,
    require_reference_checks=True,
)

assert policy.resolve(data) == {"temperature": 21.4, "unit": "celsius"}
assert policy.assess(data.reliability).accepted is True

require_reference_checks=True rejects failed or missing reference evidence even when the overall score meets the threshold. Keep each comparison tied to the same observation supplied to scan(). See Reference Comparisons for aggregation and audit details.

How the Data Reliability Index Works

The Data Reliability Index models the complete lifecycle of a data point as it moves from raw input into a trusted dataset. Rather than treating all data equally, the system evaluates, scores, and classifies every record before it becomes eligible for trusted use.

Raw data can enter from APIs, IoT devices, calibrated sensors, databases, files, and user submissions. Because these sources differ in quality and provenance, every incoming record starts as untrusted until it has been analyzed.

The scanning engine combines supplied validation evidence for completeness, consistency, provenance, cryptographic verification, calibration, schema compliance, anomaly detection, duplicate detection, and metadata quality. Reference helpers perform numeric comparisons; the scanner also supports required-field and integrity checks. Other evidence must come from your validators. Default evidence values and templates are assumptions, not proof that checks ran.

Each scan produces:

  • A numeric reliability score from 0 to 100, summarizing evidence under the selected profile.
  • A project-defined trust tier from TIER_1 to TIER_3, based on that profile's thresholds.
  • A trace hash that can be used to verify whether the data changed.
  • The scoring profile name and version used for reproducibility.
  • A ReliableData wrapper containing the original value and its reliability metadata.

Together, the numeric score and trust tier provide more information than either metric alone. The score enables precise filtering and ranking, while the tier gives an immediately understandable description of the data's verification level.

Evidence Templates

Templates provide conservative starting points so users do not need to manually set every evidence value for common source types:

  • verified-sensor
  • trusted-api
  • cleaned-dataset
  • user-submission
  • historical-record
  • climate-station

Use templates as defaults and override only values you can justify:

from data_reliability import evidence_from_template

evidence = evidence_from_template(
    "trusted-api",
    cryptographic_verification=1.0,
    notes=["Provider payload signature verified at ingestion."],
)

Trust Tiers

The system classifies data into three profile-defined trust levels. These are not externally certified quality grades:

Tier Trust level Typical sources Intended use
TIER_1 Highest profile tier Data meeting the profile's strongest evidence thresholds Workflows with separately validated domain requirements
TIER_2 High trust Cleaned secondary datasets, indirect measurements, partially validated or derived information Analytics, forecasting, and most production workloads
TIER_3 Moderate trust User-generated content, self-reported information, weakly verified external sources Exploratory analysis and workflows requiring additional validation

Intelligent Decision Pipeline

Based on the analysis results, data follows one of two paths:

  • Rejected data: records failing minimum reliability requirements are isolated and excluded from trusted datasets.
  • Accepted data: records meeting validation thresholds can be stored in trusted repositories while remaining fully traceable.

Every accepted record retains its reliability score, trust tier, provenance metadata, validation evidence, cryptographic integrity information, and audit context. Trust is not only calculated once; it remains transparent and reproducible throughout the data lifecycle.

Transparent Scoring

The scanner creates a numeric score by applying profile weights to the evidence dimensions. Each evidence value is normalized from 0.0 to 1.0, multiplied by the active profile's weight, and converted to a 0 to 100 score. Missing timestamps apply an additional penalty when timestamp verification is required.

Trust tiers are then assigned by explicit profile criteria:

  • TIER_1: the record must pass the Tier 1 minimum score and all required evidence thresholds.
  • TIER_2: the record must pass the Tier 2 minimum score and all required evidence thresholds.
  • TIER_3: fallback for records that do not satisfy Tier 1 or Tier 2.

The package includes three profiles:

Profile Purpose Tier behavior
default_profile() General application, API, and analytics data Tier 1 requires high score, provenance, cryptographic verification, schema compliance, and verified timestamp
scientific_profile() Research data across scientific fields Increases weight and thresholds for provenance, calibration, consistency, anomaly checks, and reproducibility signals
climate_record_profile() Weather and climate record data Emphasizes calibrated instruments, station metadata, consistency with comparison stations, anomaly checks, and provenance

Scores are comparable only when the evidence definitions, weights, profile version, and validation methods are compatible. A profile name alone does not establish comparability.

Choose thresholds using representative reference data and assess false acceptance and false rejection on held-out records. A score of 95 does not mean a 95% probability that the observation is correct. The legacy evidence_confidence and uncertainty fields are the mean evidence value and its complement, not statistical confidence or measurement uncertainty. See Scientific Use for interpretation and validation requirements.

You can inspect why a record received its tier:

from data_reliability import ReliabilityScanner, ValidationEvidence, climate_record_profile

scanner = ReliabilityScanner(profile=climate_record_profile())
evidence = ValidationEvidence(
    completeness=0.98,
    consistency=0.96,
    provenance=0.96,
    calibration=0.96,
    schema_compliance=0.92,
    anomaly_detection=0.96,
    metadata_quality=0.60,
)

print(scanner.tier_evaluation(evidence))

For climate records, this makes methodological uncertainty visible. A temperature record with strong provenance and calibration can still fail Tier 1 if station metadata, anomaly checks, timestamp verification, or comparison-station consistency are insufficient.

Authenticated Payloads

For trusted ingestion paths, the SDK can verify an upstream HMAC-SHA256 signature before raising cryptographic evidence:

from data_reliability import ReliabilityScanner, compute_hmac_signature

value = {"temperature": 21.4, "unit": "celsius"}
signature = compute_hmac_signature(value, "sensor-a", "shared-secret")

reliable = ReliabilityScanner().scan(
    value,
    source_id="sensor-a",
    expected_signature=signature,
    signing_secret="shared-secret",
)

Use HMAC secrets only for authenticated systems you control. For public third-party signatures, use the provider's signature scheme before passing the result into DRI evidence.

For payload integrity checks, see Integrity Checks. For value-quality checks against predefined ground truth or reference values, see Reference Comparisons. For research workflows, see Scientific Use.

Ground Truth and Reference Checks

For scientific or quality-controlled workflows, define reference values before the data is scored. The index can then show how well observed values match the predefined ground truth, tolerance, source, and method.

from data_reliability import (
    ReferenceValue,
    ReliabilityScanner,
    ValidationEvidence,
    compare_to_references,
    evidence_from_reference_comparison,
    scientific_profile,
)

record = {"temperature": 21.4, "humidity": 48.0, "unit": "metric"}

comparison = compare_to_references(
    record,
    [
        ReferenceValue(
            field="temperature",
            value=21.5,
            tolerance=0.2,
            reference_id="lab-temp-gt",
            source="validated lab baseline",
            unit="celsius",
        ),
        ReferenceValue(
            field="humidity",
            value=50.0,
            tolerance=3.0,
            reference_id="lab-humidity-gt",
            source="validated lab baseline",
            unit="percent",
        ),
    ],
)

evidence = evidence_from_reference_comparison(
    comparison,
    base=ValidationEvidence(
        provenance=1.0,
        calibration=1.0,
        schema_compliance=1.0,
        metadata_quality=1.0,
    ),
)

reliable = ReliabilityScanner(profile=scientific_profile()).scan(
    record,
    source_id="lab-sensor-a",
    evidence=evidence,
)

print(comparison.passed)
print(comparison.quality_score)
print(reliable.reliability.score)

This is different from hash verification. Hashes show whether a payload changed. Reference checks show whether values are close enough to predefined quality targets.

Database Usage

The SDK does not require a database driver. It emits plain dictionaries so the same reliability metadata can be stored in small local databases such as SQLite and DuckDB, production SQL databases such as PostgreSQL and MySQL, analytical warehouses, or document stores.

from data_reliability import ValidationEvidence, scan_row

row = {"temperature": 21.4, "unit": "celsius"}
scored_row = scan_row(
    row,
    source_id="sensor-a",
    evidence=ValidationEvidence(cryptographic_verification=1.0, calibration=1.0),
    required_fields=["temperature", "unit"],
)

assert scored_row["dri_score"] >= 90
assert scored_row["dri_tier"] == 1

For large datasets, stream rows instead of materializing everything:

from data_reliability import iter_scan_rows

for scored_row in iter_scan_rows(rows, source_id_field="id", required_fields=["temperature", "unit"]):
    write_to_database(scored_row)

Generate reliability column definitions for common SQL engines:

from data_reliability import reliability_columns_ddl

print(reliability_columns_ddl(dialect="postgres"))

For SQL tables, store the generated dri_* columns beside the source data. For document databases, store metadata_to_document(reliable.reliability) as a nested reliability object.

For rejected records, store decision_to_document(policy.assess(reliable.reliability)) in quarantine or ingestion logs so policy reasons remain auditable.

CLI Usage

dri scan records.jsonl --jsonl --source-id-field id --required-field temperature --required-field unit

The CLI emits one JSON result per scanned record with the original value, reliability metadata, and policy decision.

SDK and Security Notes

This project is intended to be used as an SDK. The core package keeps dependencies small, exposes typed Pydantic models, avoids dynamic code execution, and uses deterministic SHA-256 trace hashes to detect changed payloads. Hashes are integrity signals, not proof of source identity by themselves; use authenticated ingestion, HMAC or provider signature verification, database permissions, and private vulnerability reporting for production systems.

Pandas Filtering

import pandas as pd
from data_reliability import DataTier, ReliabilityMetadata, ReliabilityPolicy, filter_reliable_df

df = pd.DataFrame([
    {
        "value": 10,
        "reliability": ReliabilityMetadata(
            score=95,
            tier=DataTier.TIER_1,
            source_id="sensor-a",
            trace_hash="abc123",
        ),
    },
])

policy = ReliabilityPolicy(minimum_score=90, maximum_tier=DataTier.TIER_2)
trusted = filter_reliable_df(df, policy)

Documentation

The project documentation lives in docs/ and can be served locally with MkDocs:

pip install -e ".[docs]"
mkdocs serve

Start with:

The longer project rationale is available in data-reliability.md.

Development

Run the test suite:

pip install -e ".[test]"
pytest

Build package artifacts:

pip install -e ".[build]"
python -m build
python -m twine check dist/*

Run the FastAPI example:

pip install -e ".[api]"
uvicorn examples.fastapi_app:app --reload

Contributing

Contributions are welcome. See CONTRIBUTING.md for the local workflow and pull request expectations.

Security

Please report security issues privately. See SECURITY.md.

License

Licensed under the Apache License 2.0.

Release files for data-reliability-index 0.7.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for data-reliability-index 0.7.0
File Size Uploaded
data_reliability_index-0.7.0.tar.gz 37.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for data-reliability-index 0.7.0
File Interpreter ABI Platform
data_reliability_index-0.7.0-py3-none-any.whl Python 3 none any Details

Total release size: 66.4 kB

Release files / data_reliability_index-0.7.0.tar.gz

Download URL data_reliability_index-0.7.0.tar.gz
Size 37.8 kB
Tags Source
SHA-256 checksum
How to use checksums
b91f0703752f9e6fafcb31dfcc7cc8dfe6bb09156aa1d45463de96f32eb7cc17
BLAKE2b-256 checksum
How to use checksums
3818adc921d72dfc36a75237d7593e5b2450d3241865fba6cc348ec5bba0fe73
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 25, 2026.

Transparency log

Release files / data_reliability_index-0.7.0-py3-none-any.whl

Download URL data_reliability_index-0.7.0-py3-none-any.whl
Size 28.5 kB
Tags Python 3
SHA-256 checksum
How to use checksums
601377a4f10d9b7bb2293a921b86a357d913ba45a92b83802032da4bd3870e5f
BLAKE2b-256 checksum
How to use checksums
82fe92719fb8b48ffca044aab6966485a5230f71f2aefdfef59a1c6554bcd13c
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 25, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.7.0 This release

2 release files

0.6.1

2 release files

0.6.0

2 release files

0.5.0

2 release files

0.4.0

2 release files

0.3.0

2 release files

0.2.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page