Why approval gates belong in legal AI interfaces
A product-design argument for visible diffs, source citations, permission cues, and deliberate approval before AI changes legal work.
The most important moment in a legal AI interface is not when the answer appears. It is the moment a person decides whether that answer should change the work.
If the interface makes that decision feel automatic, the product has hidden the very responsibility it needs to support. Legal teams need to see what the system used, what it proposes, and what will happen next before a draft, note, or redline becomes part of the matter.
This is the design case for approval gates in Ardela: not an extra confirmation screen, but a clear boundary between AI assistance and accountable legal work.
Put the decision next to the proposed change
A reviewer should not have to compare two distant versions or reconstruct what a chat response altered. The proposal, the affected content, and the available decision belong together.
In Clara, a rewrite or redline is presented as a proposal. The person reviewing it can inspect the change, accept it, or reject it. Rejection preserves the original. Acceptance is a deliberate action with a visible consequence.
That arrangement makes the interaction legible: Clara can prepare a change, but it cannot quietly decide that the change belongs in the file.
Show the difference, not only the improved sentence
AI-generated wording often looks plausible in isolation. The reviewer needs the before-and-after relationship:
- which words would be removed;
- which words would be added;
- whether the proposal changes meaning or only presentation;
- which section or clause is affected;
- whether another accepted change already altered the same passage.
A polished replacement without its diff encourages approval by fluency. A visible diff lets the reviewer assess effect.
The same principle applies beyond redlines. If Clara tightens an attendance note, the card should identify the note and section. If it reformats a draft, the interface should distinguish structural changes from substantive ones.
Keep the evidence within reach
Approval is only meaningful when the reviewer can inspect the basis for the proposal. For document questions, that means citations that open the relevant source passage. For transcript-led work, it means retaining the editable record that generated the note.
Pillars keeps extracted fields and answers connected to uploaded source documents. The interface should make verification shorter than starting another search through the pack. A citation that cannot be opened or does not support the answer is a failure state, not decoration.
Evidence also needs hierarchy. The interface should separate a quoted source, an extracted fact, and an AI interpretation rather than blending them into one confident paragraph.
Make scope and authority visible
Legal work changes meaning with the matter, the user, and the permission boundary. An assistant that can search one set of documents should not imply that it searched everything.
Useful scope cues answer practical questions:
- Which workspace and matter am I in?
- Which recordings or documents informed this answer?
- Am I allowed to open the cited source?
- Is this a draft, an accepted change, or filed work product?
- Who is responsible for the next decision?
These cues should live in the working interface, not only in a security document. Ardela’s workspace roles, sharing grants, and approval state are product behaviour; the design needs to expose enough of that behaviour for a user to understand the boundary they are operating inside.
Design refusal and uncertainty as real outcomes
An AI interface should not reward completion at any cost. Sometimes the source is missing, the instruction is ambiguous, the user lacks access, or a proposed edit cannot be anchored safely.
Those outcomes need calm, specific states:
- the source could not support an answer;
- a required document is missing;
- the requested change overlaps another revision;
- the user cannot access the material;
- the proposal failed and the original remains unchanged.
Hiding these cases behind a generic spinner or silently returning a weaker answer teaches users that the system is more certain than it is. A trustworthy product makes “not enough evidence” and “no change applied” ordinary, recoverable results.
Prevent approval from becoming a reflex
Approval gates fail when every card looks identical and the primary action always asks to be clicked. Visual weight should reflect the decision, not the product’s desire to appear fast.
The interface can help by showing the affected content before the buttons, keeping accept and reject language explicit, and avoiding motion or urgency that pushes a reviewer through a queue. For higher-impact changes, the source and proposed effect deserve more space, not a brighter button.
The goal is not to add friction everywhere. It is to place enough friction at the point where a suggestion becomes work product.
What we evaluate in the product
For an approval interaction, we care about more than whether the button works. We ask:
- Can the reviewer identify the source and destination of the change?
- Is the original preserved until acceptance?
- Does rejection leave the work unchanged?
- Can a failed or stale proposal be mistaken for an applied edit?
- Is the decision understandable without reading a separate policy?
- Does the interaction remain clear for keyboard and reduced-motion users?
These questions turn “human in the loop” from a marketing phrase into observable behaviour.
The product promise
Ardela uses approval gates because the responsible person should remain visible at the point of change. Voice preserves the record behind a generated note. Pillars keeps answers connected to source. Clara presents edits as proposals and waits.
That does not make every output correct. It makes the path from source to decision inspectable, and it gives the reviewer a real opportunity to stop, correct, or reject the change before it becomes part of the work.
See Security for the wider data and access model, or talk to the team about evaluating an approval-led workflow with representative material.