yau-plant-assistant/REQUESTS.md
Claude b4c20324f5 Withdraw the auth.yokogawa.tech request - it blocks nothing yet
Raised as an item for Dan, which was premature. It blocks exactly one thing: a
demo from a control-room PC. Development and the Phase 8 eval both run from
outside the VNet, where auth.yokogawa.tech resolves normally, and the demo it
would block cannot happen until the Azure OpenAI account lands anyway.

The finding stays in verify.sh as information rather than a failure, so it is
in front of whoever prepares that demo instead of failing every run until then.

Also worth recording: this was inferred from lin001 resolving against 10.0.0.5,
not tested on cicore1. Same DC and same zone, so very likely identical, but it
has not been confirmed on the machine it concerns.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 15:16:48 +10:00

8.6 KiB

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 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.tech10.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: lin001imh 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.


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.