From 1ce0bab98cf008bca6276c0849bd0201d9624a00 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 27 Aug 2026 14:48:29 +1000 Subject: [PATCH] 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 --- REQUESTS.md | 180 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 REQUESTS.md diff --git a/REQUESTS.md b/REQUESTS.md new file mode 100644 index 0000000..3f94537 --- /dev/null +++ b/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.