The operator console for Northlake Health's Denials Investigator (dev, org 900000109 / app 900000102). A revenue-cycle manager asks why claim denials rose; Ava — an AI employee — investigates the hospital's Databricks lakehouse and comes back with a cause, a dollar figure and a recommendation. He approves, and she re-checks on her own two minutes later. THE POINT OF THE SCREEN is that her work is checkable. Anyone can be told an agent analysed their denials; AvaLive shows the actual SQL she sent to Databricks, in order, with what came back and how long each query took — and it does NOT hide a query she got wrong and corrected, because that is the most convincing thing on the page. Two decisions worth knowing about: * Her trace does not come from the AI-employee monitor API. That endpoint needs an org-scoped studio token and answers "no organization scope on this account" for every user of this console. It comes instead from two views (northlake_app.ava_trace / ava_decisions) exposed as ordinary rdbms record views, behind a login role that cannot read the aiemployee schema at all. Seeded by sm2/custom-apps/denials-investigator/07_console_views.sql. * Ava's own activities — Record Findings, Confirm Recovery, Flag Still Elevated, Escalate — are deliberately absent from STAGE_ACTIONS. Putting them on screen would only let a person sign in as the agent and press its button, which is a person impersonating an agent rather than an agent working. Violet is the AI and nothing else is violet; amber is the one queue a human owns. No API URL is compiled in — config.js carries it at placement time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| src | ||
| .env.example | ||
| .gitignore | ||
| index.html | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| tsconfig.app.json | ||
| tsconfig.json | ||
| tsconfig.node.json | ||
| vite.config.ts | ||
Northlake Health — Denials Desk
The operator console for the Denials Investigator app (dev, org 900000109
/ app 900000102). A revenue-cycle manager asks why claim denials rose; an AI
employee — Ava — investigates the hospital's Databricks lakehouse and comes
back with a cause, a dollar figure and a recommendation. The manager approves.
This repo is outside sm2 on purpose: it is a frontgen artifact. A push to
main triggers a build, and the artifact is placed at
https://preview-dev.getzino.in/northlake-health/.
What is where
| Path | What it is |
|---|---|
src/api/config.ts |
Every id: app, workflow, activities, record views, stages, per-stage actions |
src/api/client.ts |
The gateway client. App-scoped routes plus the two rdbms views that carry Ava's trace |
src/screens/QueueScreen.tsx |
A queue — the record view filtered on current_state_name |
src/screens/CaseScreen.tsx |
One investigation: findings, recommendations, Ava's live work, the actions |
src/screens/NewInvestigationScreen.tsx |
Ask a question — the INIT activity's form, read live from view-service |
src/components/AvaLive.tsx |
The demo. Every query Ava runs, as she runs it |
Running locally
npm install
npm run dev # http://localhost:5174 — talks to dev.getzino.in via .env
Sign in as dan.reyes@northlake.example. The org is fixed in config.ts.
Two things that will bite
- No API URL is compiled in.
config.js, written by the server when it places the build, carriesVITE_ZINO_API_URL. A production build with noconfig.jsfails loudly rather than calling whichever backend built it. - Ava's trace does not come from the monitor API. That endpoint needs an
org-scoped studio token; an app sign-in gets "no organization scope on this
account". It comes from two views (
northlake_app.ava_trace,ava_decisions) exposed as ordinary rdbms record views. Seeded bysm2/custom-apps/denials-investigator/07_console_views.sql.