writing / rca-enforcement-model 8 public repos
← writing ↑ part of Trust, safety & governance
trust-safetygovernance

Enforcement RCA — a root-cause program for a live ML model

Decision quality on a moving target

A model that makes live decisions is wrong in ways that drift.

And the wrongness compounds silently unless something measures it on a cadence. That is the class: any production system whose adjudicable outputs degrade as inputs, policy, and the world shift.

What it is

A root-cause-analysis program for a production machine-learning system that makes enforcement decisions. It measures where the model's decisions are wrong, groups those errors by cause, traces each cause back through the decision path, feeds a correction into the enforcement logic, and re-runs the same measurement on a cadence so the loop stays closed.

What's honest about the scope. Run in production trust & safety at platform scale, and described here as methodology only — no platform name, no platform-internal data, policy, tooling, or case content, and no accuracy figures. The body is kept employer-agnostic by design.

Where it generalizes

This is the model-quality / risk-ops layer — the MLOps and QA loop that begins the moment a model makes live decisions. Described method-only — no platform name, no platform-internal data, no accuracy figures — which is what keeps it portable: to any live system whose decisions can be adjudicated against a ground truth.

The method

Measure. Group by cause. Trace. Correct. Repeat.

Five steps, run in order, then repeated. Each step has one job and hands a defined output to the next.

01

Measure against ground truth

Take a sample of the model's production decisions and adjudicate each one against the correct outcome — what the decision should have been, decided independently of what the model did. The disagreements are the errors, and recording them this way gives a baseline that is a fact about the model's behavior, not an impression of it. Everything downstream is measured against this same baseline.

02

A taxonomy by cause, not symptom

Sort the errors into classes chosen by what is going wrong underneath, not by what the wrong decision looked like. Two decisions that look unrelated can share a single origin; two that look identical can come from different places. Grouping by cause is what lets one fix close a whole class instead of one case at a time — and keeps the work from chasing symptoms that keep reappearing.

03

Trace to root cause

For each class, follow a representative error backward through the decision path to where it actually originates — the point where the input, a feature, a threshold, or a rule first sends the decision the wrong way. The trace ends at a cause specific enough to act on, not at a restatement of the symptom.

04

Feed the correction back

Translate each root cause into a concrete change in the enforcement logic, then re-measure with the same instrument. The change is confirmed only when the targeted class shrinks and no new class opens in its place — a fix that closes one class while creating another is not an improvement, and measuring both sides the same way is what makes that visible.

05

Hold the loop

Re-run the measurement on a cadence rather than treating it as a one-time audit. The model, its inputs, and the world it decides over all drift; a fix that held last quarter can erode, and a class that was closed can reopen. Standing measurement catches a regression while it is small instead of after it has compounded.

Why these choices

Three decisions carry the program.

Each is a deliberate trade: causes over symptoms, a fixed instrument over a moving one, a standing loop over a one-shot audit.

Taxonomy

Cause-first, because symptoms scale wrong

Grouping by what the error looked like scales with the number of cases, not the number of problems. A cause-first taxonomy turns a long list of individual misfires into a short list of fixable origins — the difference between patching cases and closing classes.

Instrument

Held fixed across a fix

The same sampling and the same adjudication run before and after a change, so an improvement is comparable rather than anecdotal — a moved number reflects a change in the model, not a change in how it was measured. It also makes a regression legible: the same instrument reporting a class growing again is a signal, not noise.

Cadence

Standing, not one-shot

An enforcement model lives in a moving target. A single audit describes the model on the day it ran; a cadence describes the trend. The cost is the recurring work of re-measuring, accepted as the price of catching drift early.

What the cadence catches

Holding the loop surfaces three things a one-time pass cannot. Because each pass uses the same instrument as the baseline, they show up as movement against a known reference rather than as a fresh investigation each time.

Regressions

A previously closed class reopening as inputs shift.

New classes

Error patterns that did not exist at the last measurement — because the model, the policy it encodes, or the distribution it sees has changed.

Fixes that did not hold

Corrections that moved the number once and then eroded.

The honest limits

A method's limits are part of the method.

What the loop can and cannot claim, stated plainly.

Sample

It improves what it measures

An error pattern that never enters the sample is not addressed by the loop, so the quality of the sample bounds the quality of the result.

Adjudication

Ground truth is load-bearing

The adjudication against ground truth carries every number above it. If “the correct outcome” is decided poorly, every downstream number inherits the error.

Reach

Not a substitute for model work

The loop reduces recurring, cause-shared errors efficiently. It is not a substitute for the model work that changes what the system can decide in the first place.