northlake-health/README.md
Yashas 1c1c120202 feat: the denials desk, and Ava working where you can watch her
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>
2026-09-15 23:47:19 +05:30

42 lines
2.0 KiB
Markdown

# 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
```bash
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
1. **No API URL is compiled in.** `config.js`, written by the server when it
places the build, carries `VITE_ZINO_API_URL`. A production build with no
`config.js` fails loudly rather than calling whichever backend built it.
2. **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 by
`sm2/custom-apps/denials-investigator/07_console_views.sql`.