Override Micro-Ledger and the AI Ground-Truth Registry

The override micro-ledger is the granular record of every human correction to a recorded decision — one row per action, with the field, the before-and-after, the identity, the timestamp and the rationale. Alongside it, the AI ground-truth registry aggregates the firm’s standardized AI decision reasons across its studies: how often each reason was used, and the identifier the ledger links corrections back to.

The override micro-ledger

Two immutable sources are merged into one ledger, newest first and paginated:

• The study audit log — reviewer-override rows and study-update rows.
• The evidence ledger — manager overrides, analyst verifications and data captures. The automatic AI_RECOMMENDATION rows are not pulled in; the registry covers those reasons instead.

Every row is classified into one of four categories:

Category	Severity	What it is
Reviewer Override	warning	An override of a recorded disposition: a review-grid override row, a ledger manager-override event, or an override recorded through the form below
Manual Inclusion	success	The comparable-level paper trail in the evidence ledger: analyst verifications and data captures
Financial Data Edit	info	A study update touching parameters, analysis data, financial year or entity name
Narrative Text Edit	info	A study update to any other field

The per-row fields:

Field	What it records
Study and comparable	Where the action landed (comparable where applicable)
Category	One of the four above — the category filter binds to these exact labels
Field	The field that changed — study audit-log rows only
Previous to new value	The before and after, rendered old struck through, new emphasised — study audit-log rows only; evidence-ledger rows carry the event without a value pair
Actor	Name and role
Timestamp	The UTC time of the action
Justification	The written rationale; on an automatic override row it can be the generated default note rather than typed prose
ai_reason_id	Study audit-log rows: the id persisted when the override was recorded. Evidence rows: derived on read from that company’s standardized AI rationale, so it names the reason the screen gave

The rationale is required, not advisory. A manager override recorded through the evidence dialog is rejected without justification notes (422), and the Record-AI-Override form will not submit on an empty or whitespace-only note. Where the override is committed on the review grid and the reason box is left blank, the platform writes a generated default note naming the comparable, so the row is never silent — but a generated note is exactly that, and a file full of them is the pattern to look for.

Recording an AI override

The Record AI Override button on the overrides tab opens the form: study, field, previous value, new value, the ai_reason_id of the AI reason being corrected (optional, typed in — copy it from the registry tab), and the justification (required). Submitting writes a reviewer-override row on that study with the reason id persisted, so the correction is linked to a standardized reason rather than to a free-text guess. Note the boundary: this route is not role-restricted the way the views are — anyone in your firm who can reach the study can log a row, and the mandatory justification is what keeps it accountable.

The AI ground-truth registry

The registry is the cross-study aggregation the ledger makes possible:

• Stable reason identity. Each standardized AI reason is identified by a deterministic ai_reason_id — the first 16 hex characters of a SHA-256 over your firm’s scope key and the reason text. The same reason therefore maps to the same identifier across every study, which is what makes aggregation meaningful. The reason itself is derived locally by mapping the stored rationale onto the standardized taxonomy; no model is called to build the registry.
• Per-reason counts. For each reason, the registry reports how many companies the screen classified under it across the firm’s studies, when the reason was first and last seen, sorted by volume. The page leads with four cards — comparables counted, distinct reasons, the size of the in-process reason cache, and how the ids are built.
• What it does not say. The registry does not publish an overturn rate. Rows are linked to reasons on both sides, so you can see which overrides carry a given ai_reason_id — but you read that by cross-checking the AI Reason ID column against the registry, not from a score the product computes. The search box matches actors, studies, values and justifications, not reason ids.

The registry view sits next to the override ledger because it is read the same way: a table, sorted by volume, that you then cross-reference against the rows. Beneath the table is the recently-accessed list — the reason ids touched most recently with their hit counts. It is an in-process cache of up to 256 ids per firm, so it reflects the current server’s traffic, not a permanent history. The concept is defined in the ground-truth registry glossary entry.

Why this matters for the file

• The defensibility grade is stronger when overrides are rare and explained; the ledger is where that is proven.
• The override rationale workflow on the grid is the entry point; the ledger is the record it feeds.

FAQ

Why two sources instead of one? Study-level actions (overrides, edits) live in the study audit log; comparable-level actions (manager overrides, verifications, captures) live in the per-comparable evidence ledger. The micro-ledger is their union.

Can a row be corrected? No — like all ledger rows, it is append-only. A correction is a new row.

When does the AI-reason column show a dash? Study-update rows carry no reason id unless an override was logged through the form with one. On an evidence row a dash means the company has no stored AI rationale to map, so there is no standardized reason to link.