Building Quorra: An Android Decision-Intelligence Platform That Actually Explains Itself

Why I built a "reasoning layer" instead of another dashboard

If you've spent any time in operations, retail, or supply chain, you've seen this pattern before: a company invests heavily in dashboards, everyone's staring at the same charts, and yet decisions still get made on gut feel, or worse, they don't get made at all until it's too late. That gap between having data and acting on it is what pushed me to build Quorra, a Decision-Intelligence (DI) platform for Android.

Quorra isn't trying to be a prettier BI tool. It's trying to solve a much harder problem: turning fragmented operational data from systems like ERP, CRM, and WMS into recommendations that people can actually trust and act on, with a human still firmly in control.

The more I dug into this space, the more I realized that "more data" was never the actual bottleneck for most operations teams. Most facilities I looked at were already drowning in dashboards, KPI widgets, and nightly reports. What they lacked was a layer that could take all of that raw signal and turn it into something closer to a recommendation: not just "here's what happened," but "here's what you should probably do next, and here's why."

That distinction, between reporting and reasoning, became the entire premise of the project.

The problem I kept running into

Every enterprise I looked at had some version of the same three issues:

• Decision paralysis. Managers simply can't process data fast enough to act on it in time. By the time a stock-out or a margin problem shows up clearly on a dashboard, the window to act cheaply has usually already closed.
• A trust deficit. Black-box AI recommendations get ignored because nobody can see the reasoning behind them. If a system tells an operator to reroute inventory but can't explain why, the natural response is to ignore it, especially when the stakes are financial.
• Expensive reversals. Misallocated inventory or a mispriced contract is painful and costly to undo once it's already happened. Once a decision is executed, walking it back is rarely as simple as clicking undo.

Dashboards show you the "what." They almost never show you the "so what do I do about it," and they definitely don't tell you why a recommendation makes sense. I kept coming back to the idea that the real product wasn't a dashboard at all. It was a decision, packaged with enough context that a human could sign off on it confidently and quickly.

That reframing changed almost everything about how I approached the build, from the data model up to the UI.

The approach: Human-on-the-Loop, not full automation

Instead of building something that auto-approves decisions, I designed Quorra around Human-on-the-Loop (HOTL), a design philosophy that sits deliberately between full automation and manual analysis. The system proposes, ranks, and explains, but a person always makes the final call on anything high-stakes. I wanted the app to behave less like an autopilot and more like a very well-prepared analyst standing behind the decision-maker's shoulder.

Every recommendation ships with three things baked in:

• A plain-language justification for why it's being suggested, written so a non-technical facility lead can understand it without needing a data science background.
• A dual-confidence score, one for data quality and one for model confidence, so the source of uncertainty is never hidden behind a single vague percentage.
• A sandbox "what-if" environment to simulate the outcome before committing to it, so the cost of testing an idea is close to zero.

That last piece became one of my favorite parts of the build: a simulation laboratory where a manager can test a scenario, such as "what if this shipment is two days late," before touching anything real. Instead of asking people to trust a black box, the app lets them poke at it, run a few scenarios, and build their own intuition for when the system's recommendations are solid and when they should be second-guessed.

I think this is the part of the project I'd defend most strongly if someone pushed back on it. Full automation is tempting because it looks more impressive in a demo, but in high-stakes operational environments, an unexplainable automated decision is a liability, not a feature. HOTL is slower to demo but far more likely to actually get adopted and trusted by real teams.

What's under the hood

Quorra is a native Android app, and I made a conscious decision early on to keep the stack fully native rather than reaching for a cross-platform framework. Given how much of the UI depends on custom visualizations and role-based rendering, native Kotlin gave me more control over performance and layout precision than I would have had otherwise.

Frontend and UI

• Kotlin 2.1.0 as the core language for the entire app.
• Jetpack Compose for a declarative, "command center" style interface that could adapt fluidly based on user role and context.
• Material 3 for the enterprise-grade visual system, giving the app a consistent, professional feel without having to design a component library from scratch.
• Custom Canvas API charts for trendlines and gauges. Off-the-shelf chart libraries weren't going to give me the visual density and customization the recommendation views needed, so I built these by hand.

Backend and data

• Room for offline-first local persistence, since facility environments don't always have reliable connectivity and the app needs to keep functioning when the network drops.
• Retrofit 2.11 for type-safe API sync with enterprise backends, handling the messier job of reconciling remote system data with what's stored locally.
• Coroutines and StateFlow for reactive state management throughout the app, which turned out to be essential once the UI needed to update in near real time as new recommendations came in.
• Gson for serializing the more complex data models, particularly the nested reasoning objects attached to each recommendation.

Tooling

• KSP for annotation processing with Room, which cut build times noticeably compared to the older KAPT approach.
• Gradle Kotlin DSL for the build configuration, mostly for the stronger typing and better IDE support.
• MockK and JUnit for testing, especially around the reconciliation logic between local and remote data.

The architecture follows a fairly classic MVVM-plus-repository pattern, but the repository layer does more work than usual. It functions as the single source of truth reconciling local Room data with remote sync, which matters a lot when the app needs to keep functioning in low-connectivity facilities. In practice, this meant spending a disproportionate amount of time on conflict resolution logic: what happens when a recommendation gets updated on the server while a facility lead is mid-review on a phone with no signal. Getting that right was far less glamorous than building the simulation lab, but it mattered just as much for the app to be trustworthy in the field.

Designing for four very different users

One thing that shaped a lot of early decisions was realizing Quorra needed to serve genuinely different personas, not just "the user" as a single abstract concept. Early prototypes tried to build one interface that served everyone, and it was a mess: too cluttered for an operator who just needed to glance and act, too shallow for an approver who needed full context before signing off on a six-figure decision.

Persona	Role	What they need
Operator	Facility lead	Monitor the feed, catch stock-outs or risk, simulate recovery paths
Approver	Audit or finance lead	Review high-stakes escalations, sign off on capital commitments
Configurer	Data or IT manager	Manage the underlying "playbook" logic, watch data source health
Admin	System administrator	Set governance rules, manage cross-facility permissions

Splitting the app by persona meant building UI that reactively adapts based on role. An Approver sees sign-off controls that an Operator never even renders, and vice versa, rather than the same screen with certain buttons simply hidden or disabled. It also meant baking governance into the architecture from day one: automated escalation rules trigger based on financial thresholds or confidence deficits, rather than being bolted on later as an afterthought.

This ended up paying off in a way I didn't fully anticipate. Because each persona's needs were modeled explicitly, adding new governance rules later (for example, a new escalation threshold for a specific facility type) was a matter of adjusting configuration rather than rewriting UI logic. Treating personas as first-class citizens in the data model, not just in the design mockups, turned out to be one of the better architectural decisions I made.

The audit ledger: making trust auditable, not just claimed

A recommendation engine is only as trustworthy as its paper trail. Quorra keeps an immutable audit ledger that records every decision, which persona made it, and the reasoning behind it at the time it was made. This wasn't a compliance checkbox I added late in the process. It was part of the initial data model, because I wanted trust in the system to be something that could be independently verified rather than something the app simply asserted about itself.

Combined with an "Operational Best Practices" rule I baked directly into the logic, never auto-approve anything flagged as high risk, always require a written reasoning note for overrides, the goal was to make the system's trustworthiness something you can verify, not something you have to take on faith. If an approver overrides a recommendation, that override and its justification live permanently in the ledger, visible to anyone reviewing that decision later.

In hindsight, this is probably the single feature that would matter most in a real enterprise deployment. Dashboards and recommendation engines are common. A genuinely auditable decision trail, one that survives scrutiny from finance or compliance teams months after the fact, is much rarer, and it's the kind of thing that only works if it's designed in from the start rather than added after the fact.

What I'd tell someone starting a similar project

If you're building something in this decision-support space, a few things I learned along the way:

1. Explainability isn't a UI feature, it's an architecture decision. You can't bolt "why" onto a recommendation after the fact. The reasoning needs to be a first-class object in your data model from the start, stored, versioned, and retrievable, not just rendered as a tooltip in the interface.
2. Offline-first is not optional for operational tools. Facilities and warehouses don't always have great connectivity, and a DI tool that stops working when the network drops isn't a DI tool, it's a liability that people will stop trusting the first time it fails them at a critical moment.
3. Simulation is more valuable than prediction. People trust "let me test this" far more than they trust "trust me, this will work." Giving users a low-stakes way to explore a recommendation before committing to it does more for adoption than any amount of model accuracy tuning.
4. Design for the least technical persona first. If the interface makes sense to the facility operator glancing at it between tasks, it will almost certainly still make sense to the more technical personas. The reverse is rarely true.
5. Governance is cheaper to build early than to retrofit. Escalation thresholds, audit trails, and override rules are much easier to weave into the core data model at the start than to graft onto a system that was never designed to be scrutinized.

Try it out

Quorra is open source and built entirely in Kotlin. If you want to dig into the architecture, the persona-based UI logic, or the simulation lab implementation, the full code is on GitHub:

👉 github.com/alfinohatta/Quorra

Feedback, issues, and pull requests are all welcome, especially if you've tackled similar explainability or offline-sync challenges in your own projects. If you end up poking around the repo, I'd genuinely love to hear what you'd have built differently.