What only the UI can see

Here is the complete backend record of a HouseWarm review session. An extraction request. An extraction response with eleven fields and their confidences. A submission with eleven values and an approval. Three rows.

From those three rows you can compute correction rate, because the submitted values can be compared to the proposed ones. You can compute acceptance rate, from the same comparison. That is the end of the list. Whether the reviewer looked at the source crop, how long they sat with the low-confidence field before approving, whether they typed a correction and thought better of it, whether the previous document was opened and abandoned — none of it happened, as far as the server is concerned. The reviewer is a function that returns eleven strings.

Every signal that separates the two readings of a trust metric lives on the client, and none of it reaches a backend unless the interface decides to send it. That is not a limitation of HouseWarm’s architecture. It is a property of review gates: the thing you want to measure is a human deciding, and deciding happens in a browser.

The four signals, and what each one settles

Take them in the order the interpretation lesson left them, each paired with the ambiguity it is there to break.

Hesitation before an approve

The time between the reviewer’s last interaction with a field and the approve, measured while the tab is actually in front of them. It separates read it and agreed from clicked through. A genuinely better agent does not make a reviewer decide faster than they can read; a disengaged reviewer does exactly that. This is the signal that a falling correction rate cannot produce on its own, and it is cheap.

Emit it as a bucketed duration, not a timestamp pair, and gate it on page visibility with an idle threshold you write into the schema. Two seconds and two hundred seconds should land in different buckets; two hundred seconds and a lunch break should not land in the same one.

A field edited, then reverted

The reviewer disagreed with the agent, changed the value, and put it back. By the definitions the metric-set module settled on, that document is accepted unchanged — correction rate compares submitted values to proposed ones, so the revert vanishes. That is the right call for the metric and a bad outcome for the record, because a revert is one of the few moments where a reviewer’s reasoning becomes visible.

It is ambiguous on its own, which is why it is useful. A revert can mean the reviewer checked the evidence and the agent was right after all — a caught near-miss, and the gate working. It can also mean the field is confusing enough that a competent person entered a value and could not defend it. Those are opposite findings, and they are distinguished by whether the crop was opened in between, which is why this event and the next one are worth nothing separately.

Evidence never reached

HouseWarm shows a source-image crop and the raw OCR text one disclosure away. Whether either was opened before the approve is a fact the interface can observe and the server cannot. It is the most direct test available of the disengagement reading: an agent that got more accurate does not reduce how often a reviewer inspects the evidence, and a reviewer who stopped reading does.

Decide precisely what counts, because “opened” hides a choice. Clicking the disclosure is one thing, the crop entering the viewport is another, and the crop being visible for long enough to have been looked at is a third. Any of the three is defensible. Only one of them is what your event means, and the schema row has to say which.

A review abandoned with the tab still open

Opened, interacted with, never decided. This one is not merely client-only, it is invisible: to a backend that hears about approvals, an abandoned review is not a zero, it is an absence, and it reads as if the session never happened. Abandonment is the metric most likely to be reported as excellent by a gate that has no way to detect it.

The browser gives you no dependable “the user left” moment, so do not design around one. Abandonment is inferred from the absence of a terminal decision within a stated window after the last interaction, which means the window is part of the definition and belongs in the metric row rather than in the implementation. A heartbeat while the tab is visible is what makes the inference possible at all.

What each one costs the component

None of these is an analytics change. Each is a requirement on a component, which is why the schema lesson insisted on naming the emitter in the row:

• Dwell needs a clock reading at the last field interaction and at submit, plus the page-visibility state in between, plus a bucketing function so the emitted value is a range rather than a duration.
• Revert needs the field to hold the agent’s proposed value alongside the current one for the life of the session — a change to the field’s state, not to its markup.
• Evidence opened needs the crop and the OCR disclosures to be observable, and needs the definition of “opened” the schema chose to be the one implemented, not whichever was easiest.
• Abandonment needs a session identity that survives a reload, a heartbeat, and an agreed window. It is the only one of the four that changes the shape of the session rather than a single component.

Cost them honestly when you take the spec to engineering. Three of the four are small. The fourth is not, and pretending otherwise is how abandonment ends up as the row that quietly never ships and then reads as zero forever.

The ceiling on all of this

Instrumenting these four tells you when a reviewer disengaged. It does not repair the disengagement, and the same study is blunt about the limits of the interventions that try to. Participants given no AI assistance at all outperformed every AI condition, cognitive forcing functions included, on the cases where the model was wrong. On the sub-decision the authors analysed most closely, overreliance on incorrect predictions fell from 0.64 to 0.48 — a real reduction, and still short of removing the problem. The title says cognitive forcing functions can reduce overreliance, and the hedge is the honest part of the sentence.

There is a second constraint worth carrying into any intervention you propose off the back of these events. The forcing functions helped participants high in need for cognition considerably more than those low in it, and the authors raise this explicitly as a question of intervention-generated inequality. A change that works on the reviewers who were already engaged is not a fix for the reviewers the metric was worried about. So when your dwell distribution shows a bimodal split and somebody proposes adding friction, the events you built will also tell you whether the friction landed on the right half.

What this does not cover

These four rows now carry properties, and some of the obvious properties are the content of a mortgage document. The most informative version of the revert event would record the value the reviewer typed and the value they went back to, which would be genuinely useful and would move a borrower’s name out of the review gate and into an analytics warehouse.

The never-logged lesson is that constraint: what must not leave a review surface, the regulator’s principle behind the exclusion, and the derived shape that gets emitted in its place. After that, the routing lesson decides which of these events goes to product analytics, which goes to the trace, and which goes to both with two different payloads.