The review step is part of the product

An AI demo can move very quickly. A document goes in. A structured answer comes out. Someone says, ‘And then the user reviews it.’ That last sentence can conceal half the product.

What exactly are they reviewing? Where do they look when a value seems wrong? What happens to their correction? If the answer is to open the original document and start hunting, the system has handed them a second job along with the result.

My work on document extraction and review at Coralis Bio has made me pay much closer attention to that handoff. Generating a plausible record is one part of the workflow. Giving a scientist the means to check, correct, and approve it is where the product has to earn its place.

Start with the decision someone has to make

Take a familiar example: a system extracts a duration from a procedure. Showing the number is straightforward. A reviewer also needs to know which operation it belongs to, which document version supplied it, and whether the passage actually supports the interpretation. A perfectly formatted value can still be attached to the wrong thing.

That changes the design brief. The screen needs to help someone decide whether this particular value belongs in this particular record. Evidence, context, and the available actions have to meet at that point.

I would sketch that decision before polishing the generation experience. Put a questionable result in front of the team and follow the work required to resolve it. The awkward parts of that exercise are useful product requirements.

Bring the evidence to the question

A citation is useful when it gets someone to the relevant evidence. Linking to a long document leaves a substantial search task behind. A source passage, its surrounding context, and the document revision give the person something more concrete to examine.

The interface also needs to describe its own limits accurately. A link to a likely section and an exact supporting quotation carry different weight. Labeling both as verified would ask the typography to settle a question the system has not answered.

In the Coralis project note, I describe the connection between extracted fields and source passages. The broader design principle is to put the path back to the evidence where the person is deciding what to do. Making document extraction reviewable.

Give correction a proper workflow

Review needs more than an approve button. Someone may need to change a value, reject a suggestion, leave a question unresolved, or return when better evidence exists. Those are ordinary working states. Design them with the same care as the successful path.

After a correction, show what changed and what remains pending. If a new extraction runs, decide how it interacts with work someone has already checked. A person should not have to keep a private list of corrections just to defend them from the next refresh.

This concern predates today’s generative tools. The 2019 Guidelines for Human-AI Interaction include helping people correct a system and understand its behavior. I find that a useful reminder to bring established interaction-design questions into AI work early. Guidelines for Human-AI Interaction.

Measure the work left for the person

It is reasonable to want fewer interruptions. A low-consequence suggestion that is easy to undo may need very little ceremony. A change someone must later explain deserves more context. The useful design choice depends on the consequence of being wrong and the effort needed to recover.

When evaluating the workflow, I would track how long people spend finding evidence, correcting errors, and reaching a decision. Count the cases they cannot resolve. Compare that work with the process the feature is meant to improve. Generation speed alone cannot tell you whether the whole task became easier.

Put the difficult case in the next product review. Ask someone to resolve it using only what the interface provides. Watch where they hesitate. That is where the next design decision belongs.