Overrides: Recording Rationale and Why the Audit Ledger Cares

An override is a human decision that goes against the screening recommendation: accepting a company the engine flagged, almost-accepted or rejected, rejecting one the engine accepted, or reverting an override already made. Alongside it sits a second, narrower record - a documented correction against a specific AI decision. Overrides are not a defect in the workflow; they are where professional judgment enters the record. What makes them defensible is not that they happened, but how they are recorded.

What counts as an override

Two kinds of human intervention are recorded, and they are recorded differently:

Type	What it covers	What the entry holds
Reviewer override	Accepting or rejecting against the engine’s verdict on a comparable, from the grid	Field reviewer_override, previous value (the prior override, or the engine’s verdict where there was none), new value (ACCEPT / REJECT, or REVERTED when cleared), actor, role, timestamp, and the reason
AI correction	A documented disagreement with a specific AI decision, linked to the reason id being corrected	The comparable, the linked AI reason, the corrected outcome, actor and timestamp - and a written justification that the API requires

Both also append an event to the comparable’s own evidence timeline: a write-once row recording the transition as PREVIOUS -> NEW with the actor, so the verdict history of a single company reads in order regardless of what happens to the row afterwards.

There is no anonymous override path and no override without a before/after: “who, what changed, from what, to what, why, when” is the complete entry. What there is also no path for is editing the engine’s own fields - the description text, the scores, the financials - at review. The record of what the machine computed stays as computed, and the human contribution is the disposition beside it.

The rationale: one standard, enforced on both paths

Both intervention types are held to the same level of enforcement, and neither leaves a door open for a TPO to find for you.

• Grid overrides - blocked without a reason. Every accept or reject opens a reason dialog, and the dialog will not confirm on an empty box. A verdict that reaches the API without a reason - or without the row version you loaded - is rejected outright rather than stored with a placeholder, so an unexplained override cannot exist in the ledger.
• AI corrections - blocked without a reason. A documented correction against a specific AI decision carries the reason id being corrected and a justification field that the API validates as mandatory. Submitted without it, the request is rejected as inadmissible rather than accepted with a warning.

The rationale is the load-bearing part of the entry either way. “Not comparable” is a conclusion; “rejects - also operates a captive retail division, which the tested party does not, per the company’s own filing (source cited)” is a reason. The first cannot be defended; the second can, because it points at evidence.

The per-study override micro-ledger

Each study keeps its own granular ledger of overrides, viewable in the study’s audit trail and exportable with the rest of the chronology. It is a micro-ledger in the accounting sense: small, complete, ordered, and specific - one row per intervention, with the full before/after and the actor. Alongside it, the comparable’s own evidence timeline records the AI recommendation that was corrected, so an auditor can read the sequence: engine verdict with rationale, then human correction with rationale, then the final disposition.

Two properties of that timeline are worth stating precisely:

• It is append-only. Evidence events have no update path. Changing your mind does not rewrite an entry; it adds one, and the chronology shows both.
• Integrity is carried by hashing, not by secrecy. The events themselves are ordinary rows; what is hashed is the evidence snapshot content and the exported evidence packet, so a regulator can verify that the packaged dossier they received is byte-for-byte the one the platform produced.

And one consequence: overrides are re-applied when a report is built, from the recorded verdicts rather than from whatever the grid was showing when you stepped away. The document that leaves the platform matches the grid you settled.

The study-scoped view feeds the broader override ledger, which aggregates overrides across the firm’s studies for the audit view - who overrides most, which categories recur, which studies carry corrected records.

Aggregation to the ground-truth registry

This is where a single study’s override stops being just that study’s business. Every standardized AI reason text carries a deterministic reason id derived from the text itself, and when an override corrects an AI decision, the override links to the reason id being corrected. Across studies, those links aggregate into the ground-truth registry: a cross-study record of which AI reasons exist, how often they surface, and - crucially - how often reviewers overturn each of them, with recency and hit statistics.

The practical read: if the registry shows reviewers routinely overturning a particular AI reason, that is a signal about the screening configuration or the tested-party profile, not about individual reviewers. The registry turns scattered corrections into a firm-level view of where the machine and the professionals disagree.

Why the TPO attacks undocumented overrides first

A transfer pricing officer reviewing the accept-reject matrix has one question per company: why this one? For engine decisions the reason is stored and specific. For the companies a human moved, the question is sharper still - humans are the part of the process a TPO does not assume is objective, so an override without a recorded rationale reads as selection bias: the comparable set was bent toward the desired range.

The documented override defuses that read in three ways:

1. Attribution. A named actor with a role and a timestamp makes the decision accountable - it was a judgment by someone, deliberately, not a silent data manipulation.
2. Substance. The stored reason says what was wrong with the engine’s call, pointing at the evidence the reviewer relied on.
3. Pattern. The cross-study registry shows the override was a reasoned exception, not a campaign - and when a reason is overturned often enough, the firm can fix the upstream configuration instead of overriding it study after study.

An undocumented override is the first thing a TPO attacks because it is the one piece of the record that cannot be explained after the fact. The accept-reject defense stands or falls on the matrix being fully explainable - and fully explainable means every row, including the ones a human moved.

FAQ

Can an override change the range? Yes - that is its purpose. Accepting a company moves it into the pool; rejecting one moves it out. The statistics recompute on the settled grid, and the ledger shows exactly which interventions changed the pool.

Do overrides survive a re-screen? No - a re-run retires the previous comparable rows and their overrides with them, and the audit trail records the re-run. The rationale history remains auditable; it just no longer attaches to the new run’s rows.

Is the justification free text or controlled? Free text, with the standard being that it names the specific difference and, where possible, the evidence. The controlled part is the structure around it: category, field, previous, new, actor, timestamp, and - for AI corrections - the linked reason id.