When we talk about human-in-the-loop AI, it is tempting to simply focus on whether a person is involved or not. What that person can actually do deserves just as much attention. A quick glance and an “okay” gives a reviewer a very different role from a thorough assessment by someone who has the information and authority to challenge a recommendation.
That difference was our starting point.
At Kubrick, we wanted to look more closely at the choices behind human oversight and understand which arrangements managers said they would trust. Our research, accepted for presentation at the 7th International Conference on Data Analytics for Business and Industry in Bahrain on 28-29 October, 2026, explores which features of human oversight influence their stated trust.
In this article, we use those findings to propose a Databricks design that connects reviewable evidence, escalation and controlled execution. For teams designing these systems, knowing where to focus and how it might look like in practice are useful first steps.
Exploring which design features matter
Managers completed twelve tasks, choosing between two described oversight arrangements or selecting neither. Across those choices, we varied five features: auditability, escalation route, review depth, override capacity and a reviewer attribute comparing a senior manager with a junior team member.
Auditability was the standout feature in our sample, accounting for 36.8% of relative importance. Escalation route and review depth followed, at 22.9% and 20.8%. The preferred arrangements included logged and reviewable decisions, a route to a senior reviewer and full review of the recommendation.
The findings provide a useful place to start thinking about design. They are preliminary evidence from hypothetical choices, rather than proof that a particular implementation will improve trust.
Bringing the findings into Databricks
We wanted to take that discussion a step further and consider what these preferences might mean for a team building a human-in-the-loop workflow. Databricks provides several relevant building blocks, including governed data, model records, application hosting and workflow orchestration. The work is in connecting them to the decisions people need to make.
The diagram below sets out our approach, it shows how the research can inform a design on Databricks and which Databricks function facilitates each step.
Consider a campaign-planning system that recommends moving budget between channels. A manager may agree with the forecast but know about a contractual commitment missing from the model’s inputs. The oversight process needs to give that manager enough context to recognize the problem and a way to act on it.
An audit trail reviewers can use
Auditability gives us a practical starting point.
If we return to a decision a month later, we should be able to see what was recommended, what evidence the reviewer saw and why they agreed or disagreed. That history becomes particularly useful when the proposal changes during review.
In the campaign example, a manager might amend a proposed $10,000 budget transfer to $5,000. We would retain both versions, link the approval to the revised amount and record what was eventually executed. A recommendation identifier and revision number would connect the evidence, human decision and outcome.
On Databricks, Unity Catalog lineage can help trace the underlying data, while MLflow tracking provides references to model-development records. We would retain the recommendation and its evidence in governed Delta tables and add the business decision history through the application. That history needs the reviewer’s reasons as well as technical references. Its retention must also be planned, because table history alone is not a permanent archive.
A clear route for disagreement
Escalation matters when the first reviewer cannot resolve a concern. In our example, the manager could record the missing commitment and refer the proposal to an authorized senior reviewer. The case should remain pending until that concern has been resolved.
- The Databricks Apps would host the review interface, with the application assigning cases and recording decisions.
- Lakebase would hold the current revision, review state and case owner.
- The backend checks who is authorized to resolve the case, rather than treating access to the app as permission to approve every recommendation.
The outcome also needs to affect the workflow.
- A separate Lakeflow execution job would check the current approval before acting.
- An unresolved escalation, rejection or outdated approval should leave the recommendation unable to execute.
- An amendment would create a new revision requiring fresh approval.
These are business rules we would implement around the platform services.
Giving reviewers enough to work with
Review depth concerns what happens before someone makes that decision.
A reviewer needs access to the information that could change their view of the recommendation. For a budget allocation, that might include the current and proposed spend, expected outcome, data freshness, assumptions and constraints.
We would bring that information together in the review application, alongside links to the supporting evidence. The reviewer could then approve, reject, ask for more information, amend or escalate the proposal. If the missing commitment changes the recommendation, the original would remain in the history and the amended version would return for review.
This is where the interface deserves careful attention. Showing a long list of model outputs is not enough to establish that someone can assess them. In a prototype, we would want to see whether a reviewer could find the relevant evidence, understand the assumptions and explain their decision. That would tell us more about the review experience than the presence of an approval button.
Finding a balance
Our findings suggest that auditability, escalation route and review depth are useful starting points for thinking about oversight.
Override capacity and the reviewer attribute had lower relative importance in our sample, but we would be cautious about designing them out of an oversight process. Managers still preferred arrangements that allowed override and involved a senior reviewer. Override’s estimated importance also varied substantially when individual managers were excluded.
The reviewer comparison combined seniority and assumed expertise, so the study cannot tell us how much expertise alone mattered. Teams still need reviewers with appropriate knowledge and authority, and a meaningful way to refuse or amend a recommendation. The findings help us identify priorities; they do not replace judgment about the decision being made or the consequences of getting it wrong.
For teams exploring a similar design, we would start with one familiar decision and work through what a reviewer needs to see, what they can challenge and how their decision changes the outcome. That gives the research a practical role in shaping the workflow, while leaving room to learn from the people who will use it.
