Glossary

An alteration to the structure of a database table — adding or removing a column, changing a data type, modifying whether a column allows null values, or altering an index or constraint.

Comparing the structure or content of a database table between two points in time — typically between a staging environment and production, or between before and after a release.

The degree to which a planned software release has been evaluated for potential risks to production stability, data integrity, and customer experience — beyond what automated tests cover.

The likelihood that a software release will cause a production incident, degraded user experience, or data integrity problem.

A score (0–100) reflecting how often a specific table or schema change type has been associated with incidents, failed diffs, or failed expectations within a configurable lookback window (typically 30–90 days).

Rows that exist in one dataset (e.

Well Tested's internal graph of schema changes, table observations, and incident reports — linked together over time to form a memory of how systems fail.

A collection of data validation rules — defined in YAML or JSON — that specify what 'good' looks like for a given dataset.

The state of having enough evidence — from table diffs, schema change analysis, CI signals, expectation results, and recurrence history — to make a justified decision about whether a release is safe to ship.

The practice of checking that data — in databases, APIs, or pipelines — meets expectations for correctness, completeness, and consistency before or after it is used.

A record of a production incident — what happened, when it occurred, how severe it was, and what the root cause turned out to be.