Agent authority · ADR-0033

The agent can read the cell always, and write to it only when you turn a key.

A customer deciding whether an AI system may touch their line is not evaluating our architecture; they are evaluating their exposure. An architecture diagram answers “we thought about this.” It does not answer “it cannot happen.” So the last layer of enforcement is not software: it is a conductor, and you can be shown the one that is missing.

PROPOSED. Extends the manifest-authority split with a physical enforcement layer. Nothing here is a safety function, and nothing here changes the certification boundary.

The architecture

One key, one relay, and a cable with the return wires left out.

Hardwire decoupling diagram: the AI agent read path is a one-way RS-422 link from the cell state publisher through a data diode to the OCM API, with the RX conductors absent from the cable. The write path is de-energized in AUTO and MANUAL by a TwinSAFE chain: a safe mode selector, safe input, TwinSAFE logic, and safe output driving the coil of a forcibly-guided relay K1 that switches the 24 V feed to the engineering media converter. The OCM API, the PLC, and the open conductor each independently refuse the write.
Fig. 4 — read path is always live; write path is a permissive in copper

Three layers, each sufficient alone

  1. layer 1

    The API refuses the verb

    The refusal engine holds the manifest-authority axis. A request to change what the machine is, while the cell is running, is refused with a named reason — not a timeout.

  2. layer 2

    The PLC rejects the write

    Independently of the API, the controller does not accept a write that would change declared behaviour outside PROGRAM. It does not rely on anything above it having already said no.

  3. layer 3

    The conductor is open

    The physical link carrying the engineering protocol is powered through an interrupting contact. In AUTO and in MANUAL the link is down at layer 1 — not filtered, not authenticated-and-denied. Down.

None of the three may be implemented in a way that depends on another.

How it is wired, and why

A permissive, never an inhibit

The link is energize-to-allow. Lose the wire and writes stay blocked. There is no failure mode in which a broken circuit grants authority.

The gate cannot be reached through the gate

The mode selector lands on a safe input, safety logic derives the permissive, and a safe output drives the relay. That project carries its own checksum and its own login, separate from the standard runtime — so the layer gating the engineering port is not modifiable through the engineering port.

Borrowed properties, not borrowed scope

We use safety-rated hardware for fail-safe behaviour, dark-test diagnostics and a logged, inspectable state. It is documented as a non-safety load on that output. It performs no risk reduction and enters no risk assessment.

Read access never stops

Diagnosis and explanation must keep working while the cell runs. The controller publishes a fixed state frame at a fixed rate out a serial terminal; the return conductors are absent from the cable. The read path is publish-only — no request, no query surface, no acknowledgement.

Why serial and not fibre

A single-strand fibre pair generally will not establish link, because most converters need receive before they transmit. RS-422 has no negotiation to defeat, costs less, and the missing conductor is visible to a person standing at the panel.

Three independent barriers stand between the AI and your running cell

Any one of them alone is enough. We build all three anyway.

The cell declares the link

An unaudited route makes the relay decorative, so the manifest states the path.

The enforcement path is declared, the live route count is published on the read channel, and a mismatch refuses at load. A bench cell that legitimately allows writes in MANUAL says so, rather than quietly differing from the shipped configuration.

mode_selector:
  channels: 2
  positions: [program, manual, auto]
  safe_input: EL1904

engineering_link:
  permissive_from: EL2904.1     # safe output driving the interrupting relay
  interrupt_device: K1          # forcibly-guided; contact in the 24 V feed
  closed_in: [program]          # the only positions in which writes are possible
  ads_routes_expected: 1        # audited; live count arrives on the read path
  observation:
    transport: rs422
    terminal: EL6021
    conductors: [tx_p, tx_n]    # rx absent from the cable — this is the diode
    frame_rate_hz: 10

What this does not cover

Process-network writes are out of scope

Setpoints, recipe selection and HMI tags change cell behaviour without touching the program. They stay governed in software by the command-authority axis. This mechanism does not cover them, and we do not claim it does.

The friction is the mechanism

Every program download now requires a physical mode change with a key. That cost is not incidental. Any software bypass added for convenience deletes the guarantee.

Bandwidth is a real ceiling

115.2 kbaud at 10 Hz is roughly a one-kilobyte frame — ample for the declared tag set, and finite. When it binds, raise the baud rate or lower the frame rate. Do not add a second channel.

Status: proposed

This is a decision record, not shipped hardware. No panel has been built. The runtime handshake is still simulated I/O, and we will say so until it isn't true.

Next step

If this is the question your safety and IT teams will ask, bring them.

We would rather be argued with early. The decision record is public, and so is the reasoning behind it.