a627fa5ac7
OI-02: the second of the three lines this system does not cross - no recommended setpoints or operating parameters - is expected to come up as a feature request. An Advisory answer gives evidence, ranges, outcomes and documented limits, then defers to a competent person, and never returns a number as the answer. There is a foreseeable case for allowing it, and the conversation should start from what is built rather than from scratch. The entry records where the rule actually lives, because it is a code path and not a prompt instruction, so relaxing it is a change in four places at once: AdvisoryAnswer's recommendation_given: Literal[False] and required deferral in api/contracts.py, the classifier routing anything partly-advisory to the class that refuses to advise, 14 Advisory cases in the eval set, and 15 tests. It also records what has to be decided before any of that is touched - who is accountable for the number, what evidence is sufficient when the historian shows what happened rather than what the plant can safely do now, and how a recommendation is told apart from a documented limit on screen. It is blocked by the OT/safety review of section 2 of the build spec, which is still outstanding. That review will have the strongest opinion on this rule of anything in the document, so the rule should not be relaxed before it happens. The register's header said it held work we "intend to do", and its boundary table admitted only defects. OI-02 is neither: the rule works as designed. Rather than let the register's rules and its contents disagree - which is the failure this register exists to prevent - the header now covers decisions we expect to revisit, and the table has a row for them requiring the entry to be marked "not a defect". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5.9 KiB
Open issues — WRPS Plant Assistant
Work we own, and decisions we expect to revisit. One entry per issue, newest first. Nothing here is assigned yet; owners are set at handover.
What belongs here, and what does not
This repository has three other registers. Putting an item in the wrong one is how a repository ends up saying two different things about the same fact.
| If it is... | It goes in | Not here |
|---|---|---|
| Waiting on somebody outside this project | REQUESTS.md |
✗ |
| A shortcut we consciously accepted | BUILD-AI-CONTAINERS.md §14 |
✗ |
| Something already running, and its state | current-state.html |
✗ |
| A defect or gap we own and have not fixed | here | ✓ |
| A design decision we expect to revisit | here, marked not a defect | ✓ |
Three rules:
- Anything in §14 is closed by decision. It was weighed and accepted. Do not
re-open it here —
caddy/ai-routes.caddycarries one such decision explicitly marked "do not re-raise this as a task". - If an issue is a defect in something that already passed a phase gate, fixing
it means re-running that gate.
CLAUDE.mdrequires it; say so in the issue. - Closed issues move to the bottom, they are not deleted. The register is part of the as-built record, and an issue with no trace of how it closed is worth less than one that was never raised.
Open
OI-02 · The no-setpoint rule may need to become optional
Raised 2026-09-01 · Owner unassigned · Affects the product, not the build · Not a defect — the rule works as designed. Logged because it is a design decision that is expected to be revisited.
The second of the three lines this system does not cross is no recommended setpoints or operating parameters. An Advisory answer gives evidence, ranges, outcomes and documented limits, then defers explicitly to a competent person. It never returns a number as the answer.
There is a foreseeable case for allowing it — a recommendation is the thing an operator actually wants, and withholding it has a cost. This entry exists so that conversation starts from what is built rather than from scratch.
Where the rule lives. It is not a prompt instruction, so relaxing it is a code change in several places at once:
| Enforcement point | What it does |
|---|---|
api/contracts.py → AdvisoryAnswer |
recommendation_given: Literal[False] — the contract cannot express a recommendation. A deferral string is required, and a scope banner is attached to every Advisory answer |
api/classifier.py |
Advisory beats Historical; partly-advisory is advisory. Anything that could be read as advice is routed to the class that refuses to advise |
eval/testset.jsonl |
14 Advisory cases assert the refusal |
api/tests/ |
15 tests across contracts and classifier rules |
What would have to be decided before it changes — none of this is a coding question:
- Who is accountable for a number the assistant produces, once it stops deferring. Today the deferral is what keeps that answer unambiguous.
- What evidence is sufficient. The rule exists because "best" depends on equipment condition and concurrent operations this system cannot see — the historian shows what happened, not what the plant can safely do now.
- How a recommendation is distinguished on screen from evidence, so it cannot be misread as a documented limit.
- Whether it applies to all parameters or a named subset, and who approves that list.
- §2 of the build spec is still awaiting an OT/safety review. This rule is the largest single thing that review will have an opinion on. Do not relax it beforehand.
Blocked by the OT/safety review of spec/BUILD-AI-CONTAINERS.md §2, which is outstanding.
Blocking nothing.
OI-01 · OpenPLC Editor is not installed
Raised 2026-09-01 · Owner unassigned · Affects the demo plant, not the assistant
The OpenPLC Editor — a desktop tool published by the OpenPLC project, installed on a
workstation — is the application used to author and compile the IEC 61131-3 program that
openplc-runtime executes. It is not installed anywhere. It talks to the running container
over its REST API on port 8443, bound to 10.0.0.17.
Why it matters. openplc-runtime is live control for this demo: CLAUDE.md and
BUILD-AI-CONTAINERS.md §4 both forbid reconfiguring it
as a side effect of other work. Without the Editor there is no way to author, review or
compile the control logic — and no reviewable source for it in or beside this repository.
The program exists only inside the container. If the container is lost, so is the logic.
What port 8443 is — probed read-only on the host 2026-09-01, because two earlier statements in the build spec called it a web UI and were wrong:
Server: Werkzeug/3.1.8 Python/3.11.2
/ /login /index.html /programs /status /runtime -> 404
/api/v1 -> 401 Unauthorized
An authenticated REST API. No browser interface. Both build-spec statements were corrected in the commit that raised this issue.
Open questions to settle when this is picked up.
- Which workstation. Not
lin001— the Editor is a desktop application. Notcicore1—CLAUDE.mdforbids installing anything on it. That leaves an engineering workstation with VPN or LAN reach to10.0.0.17:8443. - Credentials for
/api/v1, which currently answers401. Not held by this project. - Whether the PLC program goes under version control, and where. This is the part that closes the "logic exists only in the container" gap, and it is the reason this issue is worth more than "install a tool".
Blocked by nothing. Blocking nothing today — the demo runs.
Closed
None yet. Closed issues move here with the commit that closed them.