Guardrails and journaling

The funnels, validation and locks every agent write shares, and the trail each action leaves behind.

An agent is not a second way into the station. Every call lands in the same code the pages call, under the same locks, and leaves the same trail an operator's action would.

Guardrails every write shares

• Same funnels as the UI. Configuration writes go through the same provisioning and use-case services as the pages, live writes ride the single Logic write funnel, and run control rides the Process lifecycle. There is no parallel path an agent could use to bypass validation, locks or journaling.
• Editor-grade validation. Upserts merge the supplied parameters over the existing declaration and validate the merged draft with the same rules the editors apply. A refused upsert leaves nothing half-applied.
• The engineering lock applies. While a Process unit is running, configuration changes are refused with a structured "Configuration is locked while a Unit is running" result naming what to finish first, exactly as the pages refuse them.
• A stopped runtime is read-only. When the station runtime is stopped, only inspection, status, listing, the help (help_search, help_read), report export, the backup snapshot and UI orientation (ui_state, ui_navigate, ui_screenshot, ui_scroll) keep working; every mutating call answers Runtime stopped even if its area toggle is on. Tools added in the future fail closed until deliberately classified as read-only.
• Destructive tools are flagged. Tools that command equipment or destroy data (tag_write, action_run, process_recipe_apply, process_start, process_resume, deletes, server_stop, …) carry the MCP destructive flag, so clients that auto-approve safe tools still ask before these.

How agent actions journal

Everything an agent does leaves the same trail an operator's actions do, in the places you already look:

• The endpoint's lifecycle, every agent-side configuration change and every refused browser probe journal under the Agent area of the Events Console (logs_read filters on it directly).
• Live operations in the Logic runtime (variable writes, tag writes, action runs, alarm acknowledges) journal with origin MCP, beside the same operations done from the UI; the alarm history and an action's "Fired by" line say Agent.
• Runs an agent starts, stops, aborts or comments record Agent as the actor in the run file and in Histories, so a person's name is never put on something they did not do.
• The persistent event history is append-only for agents: event_history_read cannot clear or delete anything.
• Every UI gesture of an agent that changes something (ui_click, ui_set_text, ui_select, ui_set_theme) leaves one line under the Agent area, naming the tool, what it acted on and the page, never the text written. These lines go to the program's log file (the logs folder, see Install and first launch) and to a detailed capture, not to the Console's list, so a long automation does not push warnings and errors out of it. What a gesture causes is journaled on the Console as usual.