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.