Building trust in automated operations
A practical ladder from recommendations to confirmable actions—so teams can adopt ops assistants without gambling the fleet.
The trust ladder
| Stage | What the system does | Human role |
|---|---|---|
| 1. Explain | Summarize state in plain language | Verify against known truth |
| 2. Recommend | Suggest next checks or playbooks | Decide whether to follow |
| 3. Draft | Prepare a change (ticket, policy, report) | Edit and approve |
| 4. Act with confirm | Execute only after explicit confirmation | Own the click |
| 5. Bounded autonomy | Act inside narrow, audited envelopes | Review exceptions |
Skip stages and you get either unused tools or scary incidents.
Guardrails that earn the next stage
- Same numbers as the dashboard — assistants must call the same sources of truth as the UI, not improvise meters
- Scope by tenancy and role — never “helpful” across customer boundaries
- Confirm cards for writes — state changes stay explicit
- Audit trails — who asked, what tool ran, what returned
- Honest failure — “provider busy / tool rejected” beats a invented answer
How Vigil fits the ladder
Vigil is built for stages 1–4 in production use: grounded tools, scoped permissions, and confirmations for writes. Autonomy without envelopes is a product decision you should make deliberately—not a default.
A readiness check
Ask quarterly:
- Do operators trust summaries enough to stop double-checking every number?
- Are recommendations accepted more often than ignored?
- Do draft actions get edited—or rubber-stamped blindly?
- Have confirm flows been used under stress (night, incident)?
If (3) is rubber-stamping, you are not ready for (4). If (1) fails, fix grounding before adding tools.