From scattered signals to a decision someone can defend
Meridian is an AI-assisted ops platform for multi-location hospitality. It catches problems early, explains what they'll cost in terms you can check yourself, and helps regional teams approve a response. The system does the prep. A person still makes the call.
There's no shortage of data. The hard part is knowing what it means.
A regional director might run ten venues, or fifty. The job is working out which changes matter, which locations need help, what it costs if nobody acts, and getting a response moving before service starts.
The signals that answer those questions already exist. They're just spread across eight systems that don't talk to each other, and none of them knows what the others saw.
Most tools show you a metric or fire an alert, then leave you to piece the situation together yourself. Usually while guests are already feeling it.
What I learned on a product I can't show you
Meridian is my own build, so none of this was learned by shipping Meridian. It came from an enterprise AI product I worked on with a team, in a different industry, under an agreement that means I can't show it. Three things from that work decided how Meridian is shaped.
How can I trust this? Where are these numbers from? This is great in theory, but what can I actually do with it?
The three questions that come up in almost every client meeting- 01The demo was built to sell, and I was redesigning it to use
The prototype clients first saw was built by our sales team to gauge interest, and it did that job. It showed everything the product could do at once: every input, every step of the reasoning, every caveat. That is the right instinct in a pitch and the wrong one for someone opening the tool on a Tuesday. My work was the redesign, which meant deciding what a person needs at a glance and what they only need on demand.
In Meridian: the band at the top of an incident carries four figures and nothing else. The reasoning behind them sits behind a Why this reading control.
- 02We understood human-in-the-loop as a checkpoint before we understood it as trust
The first pass reasoned about approval from the system's side: where does the pipeline need a person to sign off before it continues. That is a technical question and it produces a technical answer, which is one gate at the end. What clients kept telling us is that they will not act on a number they can't source, and they will not approve a plan wholesale when they are accountable for each piece of it. Approval is how someone builds a case they can defend to their own boss.
In Meridian: approval is per action rather than per plan, so the recommended response reads 4 actions, 2 need your approval. Every impact figure carries its own math, and the block naming what weakens a reading sits on the same screen as the evidence supporting it.
- 03We built past the brief
The action view originally animated the steps of a plan so you could watch the sequence unfold. It was the most sophisticated thing in the build, and users told us it was confusing. The client had been clear from the start that they wanted something clean and simple enough for anyone in the company to navigate, and we had built something that needed explaining. It came out.
That trade costs something. The plain list shows four actions with no visible order or dependency between them, so the sequence lives in the wording rather than in the structure. We took it anyway. A feature that fights the brief is impressive and still wrong.
In Meridian: Recommendation Review is a flat list of four actions.
Operators need enough to make a real decision. Show them every signal and you get noise, slower responses, and a system nobody trusts.
Surfacing
How do you surface the right issue without burying it in everything else the system noticed?
Reasoning
How does AI explain itself without a wall of text nobody reads mid-service?
Consequence
How do you make cost concrete without faking precision you don't have?
Accountability
How does approval stay fast enough to use and slow enough to mean something?
One lifecycle running under every screen
Meridian is built around one chain that runs under all of it. Each screen is a stop, and the fourth stop is a person.
Everything before Decision is prep. Everything after is follow-through.Meridian never crosses that line by itself.
One disruption, start to finish
The whole thing follows a single Saturday. Every number here shows up again on every screen, and each one is worked out somewhere you can see it.
- Region
- Trigger
- Exposure
- Modeled
Every figure below traces back to these four. Nothing gets invented downstream.
What needs attention, and what it costs
This screen answers one question: where does the next hour go. The band up top states the situation in a sentence before any metric shows up. The numbers under it are consequences. Covers at risk, revenue at risk.
Four figures share one container with divided cells, so the row reads as a single statement.
Status sits on a 4px rail, so you read severity before you read words. That matters when someone's scanning mid-service.
Pending approvals are on the same screen as detection, so you can see the whole loop without navigating away.
Explain before you ask
This screen leads with plain language, then evidence, then a proposal. Nothing asks you to act until the situation's been explained in words you could repeat to your own boss.
Every impact number shows its math. $14k–$22k is 270–420 covers × $52 average check. You can redo that yourself.
Evidence is rated separately from severity. A critical incident can rest on weak evidence, and the screen says so.
There's a block for what weakens the read. Confidence you can't argue with isn't confidence.
Approval that actually does something
This screen makes oversight mean something. It shows what you're authorizing, what it costs, what you can undo, and how long you have to decide.
Actions that need your sign-off are outlined in violet, so you can see your own exposure at a glance.
The alternatives Meridian ruled out are listed with reasons. If you can't argue with a recommendation, you can't really approve it either.
Reject and Escalate sit level with Approve. Saying yes isn't the default.
Closing the loop, including where the model was wrong
The last screen measures what happened against what was predicted, keeps your reasoning attached to the record, and lets the system suggest its own fixes. You still have to accept them.
| Measure | Predicted | Actual | Result |
|---|---|---|---|
| Covers at risk after plan | 40 – 90 | 62 | In range |
| Revenue impact | $2k – $4.7k | $3.2k | In range |
| Median service time | ≤ 12 min | 14 min | Missed |
| Guest rating change | no change | −0.1 | Within tolerance |
| Plan cost | $660 + $1.6k opp. | $0 + $1.4k opp. | Under |
Predicted vs actual, stated plainly, including the one thing the model got wrong. Hiding that would make every other number worth less.
The record shows that holding overtime until the 14:00 re-check saved $660. A person beat the plan, and it's logged that way.
Playbook and calibration changes get proposed for confirmation. Nothing gets applied quietly.
What it does when it has nothing useful to say
The happy path is the easy part. These three states are where an ops tool earns or loses trust: nothing's wrong, the model isn't sure, or a person says no.
All clear
Silence has to mean somebody checked. The zero state names the threshold that wasn't crossed, shows the eight systems still reporting and when each last checked, and offers to adjust the threshold so you're not left wondering whether it's broken.
Not sure enough to advise
Three weak signals at a venue with four weeks of history. Meridian holds back the impact number, lists the three things that would change its mind, and offers to hand it to a person.
Rejected
A rejection isn't a dead end. Your reasoning gets recorded word for word, the withdrawn action is marked, and the new constraint carries into whatever gets proposed next. No overtime without a second re-check.
Three components doing the real work
Most of the thinking here isn't in the layout. It's in three small pieces that decide whether you can defend a call you made on Meridian's advice. All three are running in this page.
The range covers uncertainty in how many covers get lost. The check average is fixed. This is a model output.
DerivationEvery impact number carries the math behind it, and a range where a single figure would overstate what the model knows. A number you can't rebuild is a number you can't defend to your boss.
CorroborationEvidence strength describes the evidence itself. A serious incident can still rest on thin support, and it reads that way.
4 corroborating signals · no contradicting data
Calibrated confidenceConfidence uses violet, which keeps it out of the status palette. A low-confidence read never looks like a healthy one, and it always ships with the reason behind it.
Built so the second theme was basically free
Two collections. Raw primitives, aliased by semantic tokens that resolve per mode. No component holds a hex value. Building the whole dark theme meant switching one frame's mode, then auditing what broke.
- Primitives
- Semantic tokens
- Text styles
- Library components
The whole loop, closed
You can see what needs attention, understand why it matters, dig into the reasoning behind it, approve something you're personally accountable for, and afterward find out whether it worked. Including the places the model got it wrong.
What I want to test next
- How long it takes to find the highest-risk incident cold.
- Whether people can restate where a revenue number came from.
- Whether the confidence meter changes what gets approved, or just gets ignored.
Known limitations
- The scenario data is constructed. No model has been trained behind it yet.
- Only the approver's path is designed so far. The GM's mobile view is still open.
- Contrast is verified across every screen. Keyboard and screen reader flows still need a pass.