A Fail-Closed Protocol for Reversible Repetitive-Task Automation

Build a process inventory from observed work

Start with the process as it is performed, including the inconvenient paths. Name the business owner, operators, customers of the output, upstream systems, downstream effects, entry trigger, accepted completion state, and manual fallback. Observe real cases and retain a representative set of normal, unusual, failed, and escalated examples under approved privacy controls.

Describe one unit of work at a time. A unit might be an invoice intake, access request, support ticket, document classification, or report assembly. For each unit, record:

• Inputs and authority: required fields, source of truth, data classification, consent or other authority, and freshness requirements.
• Decision path: rules applied, judgment required, handoffs, approvals, retries, and exception reasons.
• Outputs and effects: records read or written, messages created, external commitments, financial or legal consequences, and downstream dependencies.
• Completion evidence: how an operator knows the work is accepted rather than merely attempted.
• Recovery path: how to pause, resume, reverse, compensate for, or manually repair each effect.

Do not infer the process only from a procedure document. Compare the documented path with event records and operator walkthroughs. If cases cannot be reconciled to a stable entry, outcome, and exception taxonomy, improve the process before automating it.

Choose among three execution modes

“Automation” is not one risk class. Select the least powerful mode that can perform the qualified task.

Use a deterministic rule when explicit logic is sufficient. Use AI assistance when interpretation adds value but a person must retain decision authority. Consider bounded autonomy only when each permitted effect is authorized and recoverable. Open-ended goals, broad credentials, uncontrolled browsing, unbounded tool use, or irreversible high-consequence actions are not pilot candidates.

Apply an eligibility gate before design

A task enters design only if every required condition is supported by evidence. “Unknown” is a failed gate, not a reason to proceed optimistically.

NIST’s AI Risk Management Framework organizes risk work around Govern, Map, Measure, and Manage and emphasizes context, accountable roles, human oversight, documentation, and ongoing risk management. Use that framework to structure local evidence; it does not certify a particular workflow or provide a generic pass threshold.

Establish the baseline and exception rate

Measure the current process before introducing the candidate. Keep the same unit, eligibility rule, completion definition, observation window, and data source for baseline and pilot. At minimum, preserve intake time, accepted completion time, manual touches, approval outcome, rework, reopenings, exception class, downstream correction, and abandonment. Separate waiting time from active work and distinguish an attempted output from an accepted outcome.

Define the exception rate before looking at pilot results:

exception rate = eligible units requiring a path outside the approved normal flow / all eligible units attempted

Publish the numerator, denominator, time window, and reason-code distribution together. Track policy denial, missing or conflicting input, low-confidence or unsupported AI output, tool failure, permission denial, duplicate risk, human rejection, rollback, and manual completion separately. Do not remove difficult cases from the denominator after they fail. A local owner must set decision thresholds from service and risk requirements; this protocol supplies no universal benchmark.

For related implementation context, Meditel’s AI automation hub and AI tools hub can help teams frame architecture questions. Tool availability does not make a task eligible.

Design human approval, identity, and permissions together

Human review is a control only when the reviewer has authority, time, source evidence, and a usable reject or escalate path. Define what the reviewer must inspect, which changes require a second approver, and which actions are prohibited regardless of approval. Avoid approval interfaces that show only a polished AI output while hiding source records, uncertainty, tool calls, or proposed effects.

• Before-effect approval: require it for external communications, record changes, payments, access changes, deletions, contractual statements, or other locally consequential effects unless a formal risk decision defines a narrower exception.
• Separation of duties: do not let the workflow author approve its own expanded permissions or waive its own stop condition.
• Dedicated identities: separate human, service, test, and production identities. Never inherit a developer’s broad session or personal credentials.
• Least privilege: grant only the actions, resources, fields, destinations, and duration required for the approved task. Default-deny everything else.
• Runtime authorization: re-check permission and policy at the point of action; do not treat an earlier model decision as authorization.

NIST SP 800-53 Rev. 5 provides an official control catalog that includes access control, audit and accountability, configuration management, contingency planning, identification and authentication, and incident response. NIST SP 800-207 describes zero trust as protecting resources through explicit authentication and authorization rather than implicit trust based on network location. Map applicable controls with security and compliance owners instead of treating either publication as a turnkey implementation.

Make every attempted effect observable

Assign a case identifier that connects the trigger, input references, eligibility result, policy decision, workflow version, rule or model version, prompt or instruction version where relevant, identity, permissions requested, tool calls, human review, effects, exceptions, and final accepted state. Record timestamps and outcome codes. Protect sensitive content through minimization, access controls, and an approved retention policy.

For every proposed or executed action, log the target, action type, authorization result, before-state reference when permitted, idempotency key, execution result, after-state reference, and recovery status. Alerts must route to an owner who can pause the workflow. Reconcile source and destination systems independently; a successful API response alone does not prove the intended business state.

OpenTelemetry’s trace specification defines traces as causal paths composed of spans. That model can correlate stages across a workflow, but instrumentation alone does not establish correctness. Teams still need business outcome checks, policy records, independent reconciliation, and human-review evidence.

Engineer rollback and compensation before live use

Reversibility must be action-specific. Some changes can be restored from a validated prior state; others require a compensating action, notification, or manual repair. Document this distinction rather than promising a universal “undo.”

1. Prevent duplicates: use idempotency keys, uniqueness checks, bounded retries, and explicit replay rules.
2. Capture recoverable state: retain the minimum approved before-state reference, version, or transaction identifier needed to restore or reconcile.
3. Order effects safely: validate first; stage changes when possible; commit only after required approval; avoid combining unrelated effects in one action.
4. Define recovery by effect: specify restore, cancel, compensate, notify, or manually repair; name the owner and deadline from local policy.
5. Test failure paths: exercise timeouts, partial completion, stale data, permission loss, duplicate delivery, dependency outage, stop, restart, and reconciliation with synthetic or approved test cases.
6. Preserve evidence: do not erase the audit trail when rolling back. Link the original action, failure, recovery action, verification, and authorization.

If recovery depends on an untested backup, undocumented administrator access, or a third party with no confirmed response path, the workflow is not reversible enough for autonomous operation.

Run a bounded pilot with explicit stop conditions

Freeze a pilot contract before live cases: approved mode, task and exclusions, identities, permissions, versions, case cap or other local exposure limit, baseline window, measures, decision rules, reviewers, escalation, stop owner, recovery plan, and end date. Start with test cases, then an approved limited population. Do not silently widen inputs, destinations, tools, data classes, or permissions.

Pause intake immediately when any predeclared condition occurs:

• a prohibited action, unauthorized access, sensitive-data exposure, or policy bypass;
• required approval is skipped, unavailable, or accumulating beyond approved review capacity;
• the local quality, exception, rework, service, or downstream-consequence guardrail is breached;
• events cannot be correlated, versions cannot be identified, or denominators cannot be reconciled;
• the process, source system, permission set, model, rule, or dependency changes outside pilot change control;
• rollback, compensation, manual fallback, or independent reconciliation fails.

A stop should disable new intake, contain in-flight actions, preserve evidence, notify owners, identify affected units, reconcile state, and require documented restart authorization. Exercise this sequence before the first live unit. Meditel’s AI Guides and AI for Business provide adjacent AI-only reading; the pilot contract remains the controlling local record.

Record a pilot decision, not a success story

The final record should state what was observed, what remains uncertain, which population and versions were evaluated, and why the selected mode is the least powerful adequate option. Expansion is a new risk decision: repeat eligibility, permission, capacity, observability, and recovery checks for the new scope. Do not convert pilot activity into an ROI, savings, productivity, or quality claim unless separate, credible outcome evidence supports that claim.

Official sources

Access checked August 7, 2026 at 19:41 UTC. These publications support the protocol’s risk-management, control, identity, permission, and observability structure. They do not certify a workflow or establish universal performance thresholds.

• NIST AI 100-1 — Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-207 — Zero Trust Architecture
• OpenTelemetry — Trace specification