# FAQ — the questions that usually come up

### What is this, and what's it being hosted for?

IRIS Chat is an app that lets field doctors file product-usage reports by typing
plain language instead of memorizing codes, while keeping patient and other real
names off the network (see [ORIENTATION.md](ORIENTATION.md)). You're hosting a
**temporary internal test version** so the project team can install it on a handful
of their **own** phones and confirm it works end-to-end before it's ever submitted
to an app store. It's a rehearsal, not a launch.

### What happens after I stand it up?

You send back two links — the server address and the admin console link (see
[HOSTING.md](HOSTING.md)). The project team uses those to install the app on their
own test phones and run through real scenarios. If they find issues, they fix them
in the code and send you an updated copy to re-host. Once it's solid, there's a
separate, later phase for proper production hosting and app-store submission — with
its own instructions — which is **not** part of this task.

### Do I need Claude Code, an AI account, or any AI tooling to host this?

**No.** The app was *built* with the help of an AI assistant, but hosting the
result is completely ordinary work: run a small Python program, set some
environment variables, serve one web page. None of the build tooling is needed to
run it. The only external service the running app talks to is Anthropic's AI API,
and that's just an outbound HTTPS call using the key you provide — nothing to
install.

### Who owns changes to the app?

The **project team owns all changes to the app** (the person who sent you this
package is the point of contact). You **host and re-host**; you don't modify the
app. This split is deliberate: improvements flow from the project's repository
outward to whatever you're hosting, so there's a single source of truth and the
hosted copy never drifts. If you spot a bug or want a change, raise it with the
project owner — please don't patch the hosted copy directly.

### What data does the database hold, and how sensitive is it?

Three kinds of thing:

1. **Filed reports — codes only.** Which coded product, coded hospital, coded
   doctor, and a patient *code* (initials + age, e.g. `MS 52`). **No patient
   names.** On their own these are close to meaningless without the roster.
2. **The roster — the sensitive part.** The master table mapping each code back to
   the real product, hospital, and doctor. This is the key that could turn the
   codes back into names. It's why the database must sit inside company controls
   (HOSTING.md, requirement 6).
3. **A small, sanctioned set of real names.** When a doctor types a name the system
   doesn't recognize (a new doctor or hospital), that typed name is sent to a
   back-office "review" list so a human can add it to the roster. This is the one
   place a real name is *meant* to appear, it's limited to a fixed set of fields,
   and it's only visible to admin-role users. **Patient names never enter this** —
   patients are always reduced to initials + age on the phone.

What is **never** in the database or on the network: a patient's real name, or the
free text of a doctor's report in un-coded form.

### What's demo data versus real data?

Everything currently in the repository and seeded on first run is **demo data** —
fictional doctors, sample products, and placeholder logins — so the system can be
tried safely. Specifically:

- **Fictional:** the doctor names in the roster, the demo doctor sign-in cards, and
  the `admin`/`viewer` demo console logins.
- **Real-but-public:** the sample data does use some **real hospital names** (they
  are well-known public institutions) and some real product brand names, purely as
  realistic stand-ins. None of it reflects real doctors, real patients, or real
  reporting activity.

The real roster and real logins are introduced later, at hosting/production time,
through secrets and configuration — never committed to the repository.

### When the project team makes a change, how does the hosted version get updated?

They commit the change to the repository. You re-deploy from the repository — for a
server change, pull the latest and restart the server; for the admin page, re-upload
the new file. Your secrets (the API key, the admin logins) stay set across updates;
you don't re-enter them. Full details are in
[TEST_HOSTING.md](TEST_HOSTING.md#keeping-the-hosted-copy-up-to-date-the-update-loop).
You never edit the hosted files by hand.

Likewise, the doctor **phone app** is generated from a single source file
(`app/iris_chat_app.html`) by a small build step (`node mobile/build-www.mjs`) — the
packaged `mobile/www/index.html` that gets wrapped into the iOS/Android app is never
hand-edited, so the phone build can't quietly drift from the web app. (Running
`node mobile/build-www.mjs --check` reports whether the two are in sync.)

### Who do I ask about what?

- **What the app does, why a decision was made, or a change to the app** → the
  **project owner** (whoever handed you this package / sent the endorsement note).
  The reasoning behind most decisions is also written down in `DECISIONS.md`.
- **How to host it, the requirements, what to send back** → this package:
  [HOSTING.md](HOSTING.md) and [TEST_HOSTING.md](TEST_HOSTING.md).
- **Where the project currently stands overall** → `PROJECT_STATUS.md`.
- **Your own hosting infrastructure, network, secrets, and access controls** →
  your internal IT/security process, as normal.

### Is there anything I could accidentally do that would be a problem?

Three things to avoid, all covered in HOSTING.md: turning on request-body logging
(it would capture the coded report content), leaving the demo admin logins active
on a reachable console, and putting the database on infrastructure outside company
control. Avoid those and you're on safe ground.