Close request 2: the DNS records are in place

All three A records resolve to 20.211.144.151 and the DC carries the pinpoint
record ai.yokogawa.tech -> 10.0.0.17, verified from lin001. Kept in the file
as a record of what was asked for and what arrived, with the two things that
came out of it: api and cube have no pinpoint record and do not resolve inside
the VNet, and the names resolving is not the same as the services answering -
the Caddyfile blocks and Authelia rules are still to be applied.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

REQUESTS.md

@@ -0,0 +1,180 @@
+# 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 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 |
+
+---
+
+## 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` still have to be applied on the host —
+  see the deployment note. Until they are, all three names return nothing.
+
+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.
+
+---
+
+## 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.