yau-plant-assistant/REQUESTS.md

# Outstanding requests — WRPS Plant Assistant

Two things are still needed from other people, of the three originally raised. Nothing else
is blocking: as at **21 August 2026** the assistant runs end to end on `lin001` — the question box, name
resolution, the data translator, document search, all four answer lanes, the rulebook, the
working panel and the logbook are all live and were exercised by hand on the host.

**Item 4 was found on 27 August 2026 while verifying item 2 and is the smallest of the
four — one DNS record — but it blocks the operator demo completely.**

**Item 2 was delivered on 27 August 2026 and is closed** — it is kept below as a record of
what was asked for and what arrived. What is still missing is the AI model itself and real
plant data. Both depend on someone outside this project and neither can be hurried at the
end: the model account is the longest pole and also gates the OT/safety review, and the
historian is the one furthest outside our control.

Contact for item 1: **Daniel Watson** (daniel.watson@yokogawa.com).
Item 3 needs the owner of the `imh` historian, who is not yet identified.

| # | Request | Needed for | Blocks |
|---|---|---|---|
| 1 | Azure OpenAI account, 3 deployments | The two AI steps — classifying the question, wording the answer | Phases 6, 8; the safety review |
| 2 | ~~Three public DNS records + DC pinpoint records~~ | Reaching the assistant by name from a control-room PC | **Delivered 27 Aug 2026 — closed** |
| 3 | Read-only login to the `imh` historian | Real plant figures instead of stand-ins | Phases 4, 5; every data answer |
| 4 | One more DC pinpoint record: `auth.yokogawa.tech` | Signing in from a control-room PC at all | Phase 7; any operator demo |

---

## 1. Azure OpenAI account

### Action

Create an Azure OpenAI resource in the existing subscription and deploy three models on it:

| Deployment | Model |
|---|---|
| Small chat | GPT-5-mini class or equivalent |
| Flagship chat | GPT-5 class or equivalent |
| Embeddings | `text-embedding-3-small` |

Hand over, via a secure channel: the **endpoint URL**, an **API key**, and the **API
version**. Confirm outbound HTTPS from `lin001` to the endpoint is permitted.

Pay-as-you-go. **No fine-tuning and no provisioned throughput** — both bill a fixed hourly
amount whether used or not, and neither is needed.

### Cost

Consumption-based, billed on usage only. No licence, no commitment, no minimum term,
cancellable at any time. Estimated on three model calls per question at published list
rates:

| Usage | Questions / month | Estimated |
|---|---|---|
| Occasional demos | 500 | ≈ US$6 |
| **Expected — build, testing and demos** | **3,000** | **≈ US$35** |
| Heavy daily use | 10,000 | ≈ US$120 |

One-off cost to index the document set: under US$1.

**Requested: a US$50 per month budget, approximately US$250 for the demo period**, with an
Azure budget alert set at that figure.

Rates are published list prices and should be confirmed at approval. This is a
demonstration figure; an operational plant deployment would be sized and costed separately.

### What it is for

The assistant runs end to end today except for the two steps that need a model: classifying
each question, and wording the answer. Without the account those two cannot be built,
tested or reviewed, and the 67-question acceptance test cannot be run at all.

---

## 2. Three public DNS records, plus pinpoint records on the DC — DELIVERED

**Closed 27 August 2026.** All three A records resolve to `20.211.144.151`, and the DC
carries the pinpoint record `ai.yokogawa.tech → 10.0.0.17`. Nothing further is needed from
Dan for this item. Two things are worth recording:

- **`api.yokogawa.tech` and `cube.yokogawa.tech` have no pinpoint record**, so they do not
  resolve from inside the VNet at all. That would have broken the operator demo, because
  the browser called the API by that hostname. Rather than ask for a fourth record, Caddy
  now routes `/ask` under `ai.yokogawa.tech` to `ai-api` and the page is same-origin. No
  further DNS is needed for the demo. `cube.yokogawa.tech` is for engineers on the public
  side only; `ai-api` reaches Cube container-to-container and never by hostname.
- **The names resolving is not the same as the services answering.** The Caddyfile blocks
  and the Authelia rules for `ai`, `api` and `cube` were applied on the host the same day;
  all four AI hostnames now return 302 to the auth portal. What is still unproven is the
  part no check here can reach: an operator on `cicore1`, signed in with Duo, getting an
  answer end to end.

The original request follows, unchanged.

### What is needed

Three A records under `yokogawa.tech`, each → **20.211.144.151**, the same treatment
`lf.yokogawa.tech` already has:

| Name | Points at | For |
|---|---|---|
| `ai.yokogawa.tech` | 20.211.144.151 | The operator's screen |
| `api.yokogawa.tech` | 20.211.144.151 | The assistant behind it |
| `cube.yokogawa.tech` | 20.211.144.151 | The data translator |

**And — separately, on the domain controller — a pinpoint record for `ai.yokogawa.tech`
→ `10.0.0.17`.** Azure hairpin means LAN hosts cannot reach the VM's public IP from inside
the VNet, so without this an operator sitting at `cicore1` cannot resolve the assistant at
all. `influx.yokogawa.tech` already has exactly this treatment.

### What it is for

All three services are running right now and none of them can be reached by name. Today
they are opened down an engineer's SSH tunnel, which is fine for development and useless
for a demonstration. No control-room PC can open the assistant until these records exist.

Caddy already holds the site blocks, each with `import authelia`, so sign-in and TLS are
handled the moment the names resolve; certificates are issued automatically on first
request. Access is governed by the existing `HTTPS_UserAccess` group — no new AD group is
needed for this item.

### Why raise it now

This is the item most likely to be forgotten, because **nothing fails until the day
somebody tries.** Every container is healthy, every check passes, and the gap only appears
when a person outside this project opens a browser. It also depends on two different people
— public DNS and the DC are not the same change.

---

## 4. One more pinpoint record on the DC: `auth.yokogawa.tech`

### What is needed

**`auth.yokogawa.tech` → `10.0.0.17`** on the domain controller, the same treatment
`ai.yokogawa.tech` and `influx.yokogawa.tech` already have. Contact: **Daniel Watson**.

Nothing else. No public record — `auth.yokogawa.tech` already resolves publicly and works.

### What it is for

Signing in. The DC is authoritative for a `yokogawa.tech` zone that contains pinpoint
records only, so from inside the VNet every name **not** in that zone is NXDOMAIN — not
forwarded to public DNS. `ai` and `influx` are in it. `auth` is not.

An operator at `cicore1` therefore gets: `ai.yokogawa.tech` resolves to `10.0.0.17`, Caddy
answers, Authelia redirects the browser to `https://auth.yokogawa.tech/?rd=...`, and the
browser cannot resolve it. The assistant is reachable and cannot be logged into.

### Why it was not caught earlier

Every other service behind Authelia is reached from the internet, where `auth` resolves
normally. `influx.yokogawa.tech` is the one exception with a pinpoint record, and LAN
traffic to it uses the **bypassed** API paths — `^/api/v2/write`, `^/api/v2/query`,
`^/health` — which never touch the portal. `ai.yokogawa.tech` is the first thing on this
host that a LAN client must interactively sign in to.

Duo is unaffected: Authelia calls the Duo API server-side from `lin001`, so the browser
never needs to reach `duosecurity.com`.

### How to confirm it is fixed

On the SCADA machine, before opening a browser:

```
nslookup ai.yokogawa.tech      → 10.0.0.17
nslookup auth.yokogawa.tech    → 10.0.0.17   (NXDOMAIN today; this is the request)
```

---

## 3. A read-only login to the `imh` historian

### What is needed

1. **The server.** `yau-sls-poc-imh:1433` is configured and waiting; the host is still
   being built.
2. **`svc_agent_ro`** created with `SELECT` on the agreed tables only — no DDL, no write
   access, no `xp_` procedures. Password over a secure channel.
3. **The database name**, and the agreed **table names and key columns**.
4. **NSG rule:** `lin001` → `imh` on 1433 only.
5. **Timestamp semantics confirmed:** UTC or local, and DST behaviour. This one is not a
   formality — see below.
6. Permission to set an application name on the connection, so DBAs can see who is
   connecting.

### What it is for

Every figure the assistant produces today is a stand-in. Cube — the data translator — is
running and answering questions against fixture tables (145 alarm records, 309 pump
operations, about 130,000 level readings), and every answer built on one carries a warning
label all the way to the operator's screen. The definitions Cube uses are the real ones and
will not change when the historian arrives; only the source will.

### Why the schema conversation cannot be deferred

Two defects found while hand-verifying Cube's measures were **deliberately left unfixed**,
because fixing either against fixture data would mean guessing at what `imh` actually
contains:

- **The wet well level tag does not join.** History is keyed `PS_STN_WET_WELL_LEVEL`, but
  the tag seed carries that only as an alias of `LIT-101`. A tag-level lookup therefore
  returns zero rows for a third of the history — and reports it as **"no records found"**,
  which an operator cannot distinguish from a genuine absence of data. Equipment-level
  lookup works, so whether a question fails depends on which path it takes. The likely fix
  is known, but must not be applied until `imh` says what CI Server actually historises the
  point as.
- **First/last alarm times return UTC, not site time.** Inside a row labelled in Sydney
  time, the measure returns an instant labelled ten hours and a calendar day wrong. Which
  of the two available fixes is correct depends on what `imh` returns.

Both fail eval cases (`H26`, `H27`) until settled.

### What it unblocks

Phase 4 and the remainder of Phase 5. Note that an engineer must independently confirm
Cube's first real numbers by hand before anybody trusts one — that is a person's time, not
just a login.

---

## Related, but not a request

**Phase 9 — operator document management** will need a second AD group,
`AI_DocPublishers`, with **direct** membership (Authelia resolves direct membership only; a
user nested inside a group is silently denied). That is deliberately held until Phase 8
passes and is **not** being asked for now — noted here only so it is not a surprise later.