Trust Scores for AI Deliverables

The Problem: No Memory

Run an AI validation pipeline today and it tells you whether the output passed or failed. Run it again tomorrow and you get another binary verdict. Neither run knows the other exists. There is no accumulation, no trajectory, no distinction between a system with fifty consecutive clean runs and one that failed catastrophically last week.

This is the state of most AI quality assurance. Each evaluation is an isolated event. A passing score on Tuesday carries no weight on Wednesday. A critical failure on Monday is forgotten by Friday. The system cannot answer the most basic question a decision-maker would ask: is this getting better or worse?

For AI systems that produce client-facing deliverables, this gap has real consequences. A deployment pipeline that treats every run identically cannot distinguish between a high-confidence deploy and a lucky pass on a volatile system. It cannot slow down when things are trending poorly. It cannot grant autonomy to systems that have earned it. Without history, there is no basis for graduated trust.

How Existing Systems Build Trust

The problem of quantifying trustworthiness from behavioral history has been solved repeatedly outside of AI. Each solution shares a common structure: observe behavior over time, weight recent evidence more heavily, penalize severe failures disproportionately, and tie the resulting score to real consequences.

The pattern is consistent. FICO does not treat a bankruptcy the same as a late payment. PageRank does not let a single inbound link determine authority. Stack Overflow does not give moderation privileges to new accounts regardless of one good answer. In each case, trust is earned through sustained performance and lost quickly through severe failure. The score has consequences, which is what makes it meaningful rather than decorative.

Exponential Decay for AI Validation

The right mathematical tool for this is the Exponentially Weighted Moving Average. EWMA gives recent observations exponentially more influence than older ones without discarding history entirely. Each new validation run contributes a fixed percentage of the score update. The remaining weight comes from the accumulated past.

With a smoothing factor of 0.15, each new run contributes 15% of the update. A run from twenty cycles ago contributes roughly 4%. A run from fifty cycles ago contributes less than 0.05%. The score naturally forgets old performance without requiring explicit expiration rules or fixed window sizes.

But time decay alone is not enough. Critical failures need event penalties on top of the EWMA update. A catastrophic validation failure should drop the score by a fixed amount that can only be recovered through subsequent clean runs. This mirrors FICO's treatment of severe delinquencies: a bankruptcy damages a credit score far more than a late payment, and recovery requires sustained good behavior, not one good month.

The asymmetry is deliberate. Dropping fifteen points takes one bad run. Recovering fifteen points takes eight to twelve clean runs. This is what separates a trust score from a vanity metric. A vanity metric goes up and never comes down. A trust score has teeth.

Detecting Regressions, Not Just Failures

Static thresholds catch absolute failures. A score below 60 is bad regardless of context. But static thresholds miss contextual regressions. A system that consistently scores 88-92 dropping to 72 should trigger investigation even though 72 clears any static floor. The regression itself is the signal, not the absolute number.

The EWMA baseline enables this. By tracking each system's own historical mean and standard deviation, deviations become relative to that system's established behavior. A z-score measures how many standard deviations a new result falls from the system's own baseline. Two standard deviations below the mean flags an anomaly. The same absolute score might be normal for one system and alarming for another.

This is how industrial quality control has worked for decades. Shewhart control charts, introduced in the 1920s at Bell Labs, established the principle that variation within a process should be measured against that process's own behavior, not against a universal standard. EWMA control charts refined this by weighting recent observations more heavily, making them sensitive to small, sustained shifts that fixed-window methods miss. The same statistical machinery applies directly to AI validation scores.

What Trust Scores Should Gate

A trust score that does not gate anything is a dashboard widget nobody checks. The score becomes meaningful only when it has operational consequences.

The minimum viable integration: a system with a trust score below a threshold requires manual approval before deployment, even if its most recent run passed. A passing run on a low-trust system is not the same as a passing run on a high-trust system. The trust score encodes the difference.

Staleness matters as much as the number itself. A score of 85 with a last-validated timestamp of three days ago means something different than 85 validated forty-seven days ago. Trust without fresh evidence should decay. Two points per week of inactivity is a reasonable starting position. This prevents a system that ran clean six months ago from carrying a healthy score when nobody has validated it since.

Bootstrapping Trust: The Cold Start Problem

A new system has no validation history. The trust score must handle this without giving unearned confidence or penalizing the system for being new.

The solution mirrors how credit scoring handles thin files. New systems start at a neutral score, neither high nor alarming. The score is marked provisional until a minimum number of validation runs exist. During the provisional period, each run carries double the normal EWMA weight, so the score converges to reality faster. After sufficient runs accumulate, the score switches to standard weighting and the provisional label drops.

The provisional label is not cosmetic. It communicates uncertainty that a bare number does not. “Trust: 72 (provisional, 4 runs)” tells a fundamentally different story than “Trust: 72 (stable, 47 runs).” Both are 72. Only one has earned it.

This is the architectural choice that separates a meaningful system from a reporting artifact. Every design decision follows from whether the score has consequences: whether it can go down, whether recovery is harder than damage, whether staleness is visible, and whether the number gates something real. A trust score without teeth is a number on a dashboard. A trust score with teeth is a governance mechanism.