OSPREY — Safety Guidelines

OSPREY connects an AI agent to live control systems. Every action the agent proposes can affect real hardware. Read these guidelines before you begin — and revisit them often.

[01] Never auto-approve commands

OSPREY requires human approval before any hardware write is executed. This gate exists for a reason. Do not configure workflows that bypass approval, and do not rubber-stamp requests without reading them.

Read every proposed command in full before approving.
Verify the target channels, values, and units are correct.
If a command looks unfamiliar or unexpected, reject it and investigate.
Batch approvals are especially dangerous — review each item individually.

Warning

Automatic approval defeats the entire safety model. A single unreviewed write can damage equipment or create unsafe conditions.

[02] Monitor the agent at all times

The agent works autonomously between approval gates. You must actively watch what it is doing — not just wait for the next approval prompt.

Keep the terminal visible while the agent is running.
Watch for unexpected read patterns or channel access.
If the agent appears confused or is looping, stop the session.
Review the agent's reasoning, not just its final action.

The agent can read values, query databases, and build execution plans — all without approval. Reads are not harmless if they lead the agent to wrong conclusions that it then acts on.

[03] Reject out-of-scope requests

Every OSPREY deployment has a defined operational boundary — a set of systems, channels, and actions it is configured to handle. Requests that fall outside this boundary are the highest-risk category.

Know your deployment's scope: which subsystems, which channels, which value ranges.
If a request touches systems outside the configured scope, reject it immediately.
Do not let the agent "try to help" with unfamiliar equipment.
Vague or open-ended prompts ("fix everything", "optimize the beam") are dangerous.

Critical

When the agent encounters something outside its scope, it may attempt corrective actions based on incomplete knowledge. An agent that doesn't know a system's constraints can push values into unsafe ranges while "trying to help." This is the most dangerous failure mode.

>> Remember

You are the operator. The agent is a tool. You are responsible for every action it takes. If something goes wrong, the first question will be: did the operator review and approve?

When in doubt, stop the session and consult your control system team.