Can You Disconnect It in Five Minutes?

Exit usually appears near the end of a supplier agreement.

It should appear near the beginning of the architecture review.

An organization that cannot stop an AI system cleanly does not fully control it. An organization that can stop it only by destroying state may create a second problem while solving the first. The operating requirement is more precise: stop the relevant activity, preserve the evidence and work state, revoke or isolate access, and leave a documented path to recovery or transition.

We use a simple question to expose the design:

Can your operator disconnect it in five minutes?

This is a proposed acceptance drill, not a claim that every BAMS deployment has already passed a timed end-to-end test. The point is to make control observable.

BAMS circuit breaker controls. All displayed data is simulated.

Disconnect Does Not Mean Delete

The word can describe several actions:

• disable an external model provider
• pause one agent
• stop an entire class of agent work
• disable an integration
• revoke supplier access
• isolate the deployment from an external network
• stop new requests while preserving work in progress
• end the commercial relationship and export the required assets

These actions have different scopes and consequences.

A useful drill names the scenario. For example:

"Disable the hosted model provider used by the contract-review workflow. Prevent new calls, preserve queued work and evidence, show the affected routes, and confirm which tasks fail closed."

That can be tested.

"Avoid vendor lock-in" cannot.

The Five-Minute Drill

The time limit is not a guarantee of universal recovery. It is a forcing function for operator readiness.

A prepared operator should be able to complete five steps.

Minute 1: Identify the scope

Open the control plane and identify the affected provider, agents, routes, integrations, and workflows.

The operator should not need to ask the implementation engineer where the dependency lives.

Minute 2: Stop new exposure

Disable the provider, pause the agent, trip the relevant circuit breaker, or block the integration according to the scenario.

The control should have a named owner and authorization rule.

Minute 3: Verify containment

Confirm that no new requests or actions cross the boundary. Identify queued and in-flight work. Show which workflows have a permitted fallback and which fail closed.

A silent fallback to a less appropriate route is not containment.

Minute 4: Preserve state and evidence

Record the action, actor, time, reason, affected work, and current state. Preserve the material required to investigate, recover, or transition.

Stopping the system should not erase the explanation.

Minute 5: Hand off the next action

Assign the recovery or transition task to a named owner. The runbook should state whether to restore, reroute, export, or keep the workflow paused.

The operator should know what happens after the timer stops.

What BAMS Can Show Today

The BAMS reference implementation includes several controls relevant to this drill.

Operators can manage model-provider state, inspect route bindings, pause and resume agent activity, use agent lifecycle operations, activate circuit breakers, review governance activity, and preserve audit records.

The governance surface also represents control state and recent events. The interface gives the operator a common place to see that a control is active and what it affects.

These are product receipts. They establish that stop and state controls are part of the architecture.

They do not yet establish that the complete five-minute procedure has been timed across a packaged client deployment, every connector, every data export, and every contract condition. That full test remains an acceptance requirement for the commercial beta deployment.

The distinction matters. A circuit-breaker button is not an exit strategy. It is one instrument inside it.

Five Disconnect Layers

A complete exit and control design covers five layers.

Provider

Can the organization disable an external model route? Does the workflow fail closed or use an approved fallback? What happens to requests already sent?

Agent

Can an operator pause or decommission a single identity? Are its credentials and tool permissions revoked? What happens to work it owns?

Integration

Can the organization stop an adapter or revoke a credential without stopping unrelated workflows? Is the connector inventory current?

Platform

Can the organization stop and recover the BAMS deployment under its infrastructure procedures? Are backup and state dependencies documented?

Supplier

Can the client revoke BlackUnicorn access, retain required software and configuration rights, export its context and evidence, and operate the agreed workflow from the handover packet?

The final layer turns a technical stop procedure into a no-strings-attached commercial relationship.

Evidence Must Survive the Stop

Emergency controls can create blind spots if they are designed only to halt execution.

After a stop, the operator may need to answer:

• What triggered the action?
• Who authorized it?
• Which requests were in flight?
• Which external calls had already occurred?
• Which work remains incomplete?
• Which data or credentials may have been exposed?
• Which route or connector can be restored safely?
• Which client owner accepted the recovery decision?

BAMS connects governance and audit activity to its control plane. The client deployment must define which records are required for each disconnect scenario and verify that the stop procedure preserves them.

Evidence is not an optional report generated after the incident. It is part of the recovery state.

Failure Should Be Designed

AI workflows often define the successful route in detail and leave failure to generic error handling.

The disconnect drill reverses that habit.

For each dependency, decide:

1. Which failure is detected.
2. Which new activity is blocked.
3. Which fallback is permitted.
4. Which work remains queued.
5. Which operator is notified.
6. Which approval is required to restore service.
7. Which evidence is retained.

This exercise regularly finds hidden dependencies. A hosted model may be disabled while an integration still calls it through a separate service. An agent may be paused while a scheduled job keeps creating tasks. A data export may contain records but omit the access metadata needed to use them.

The drill turns these assumptions into test cases.

The FDE Must Make the Drill Transferable

The Forward Deployed Engineer helps design and run the initial disconnect scenarios. The FDE should not remain the only person who can perform them.

Before handover, a client operator should run the drill from the agreed procedure while the FDE observes.

The acceptance packet should include:

• dependency and route inventory
• circuit-breaker scope
• provider disable and restore procedure
• agent pause and decommission procedure
• connector revoke procedure
• state and evidence preservation checks
• client and supplier access revocation
• export inventory
• recovery owners and approval rules
• measured drill results and open limitations

If a procedure does not pass, record the actual result. Do not turn an unfinished test into a marketing number.

Current Product Boundary

BAMS has relevant controls in a working internal reference implementation. We are productizing the system as a commercial beta appliance for client-controlled deployment.

The complete timed disconnect drill has not yet been verified end to end across a client appliance and engagement handover. Connector coverage is also deployment-specific.

Our public claim is therefore exact: a five-minute disconnect drill is a buyer test we believe a governed AI deployment should be designed to pass. BAMS provides core controls for that test. The commercial beta engagement must measure and record the result.

Ask Before You Depend

Exit planning is sometimes treated as a lack of confidence in the project.

It is the opposite.

A system that can be stopped, inspected, recovered, and transferred is easier to place into real work. Operators know the boundary. Risk owners can approve against evidence. The supplier has a clear delivery obligation.

Ask the question before dependency grows:

Can your operator disconnect the provider, agent, integration, platform, and supplier relationship without losing the state required to continue?

Put five minutes on the first control action. Record everything else honestly.

No strings attached begins with a stop control that the client can actually use.

Write the Drill Before the Incident

A useful drill card fits on one page and removes interpretation from the first response.

It should name:

• the scenario and trigger
• the provider, agent, connector, or platform scope
• the operator authorized to act
• the exact stop control
• the expected workflow state
• permitted fallback or required fail-closed behaviour
• evidence to preserve
• people to notify
• restore authority
• the export or transition step if service does not resume

The drill card should also say what the operator must not do. A provider incident should not prompt an improvised route to an unapproved model. A connector failure should not lead to credentials being copied into a temporary service. A pause should not erase queued work.

Clear prohibited actions protect the organization while operators are working under pressure.

Measure More Than the Timer

The first control action is timed because speed matters when new exposure must stop. The complete review needs additional measures.

Detection

How did the operator learn that the control was required? Was the state visible in BAMS, reported by a provider, or raised by a person?

Scope accuracy

Did the operator identify every affected workflow and avoid stopping unrelated work?

Containment

Did new requests and actions stop at the intended boundary? Did any hidden fallback continue exposure?

State preservation

Could the team identify queued and in-flight work after the stop?

Evidence quality

Did the record contain enough information to explain the action and support recovery?

Recovery

Could an authorized operator restore, reroute, or transition the workflow from the procedure?

Independence

Could the client perform the drill without BlackUnicorn taking control?

These results belong in the acceptance evidence. A fast stop with poor scope or missing evidence is not a clean result.

Run More Than One Scenario

One successful provider-disable test does not establish complete control.

The lighthouse workflow should exercise several scenarios over time:

1. External model provider unavailable.
2. Agent identity suspected of operating outside scope.
3. Connector credential revoked or compromised.
4. Organizational source returns restricted or corrupted context.
5. BAMS service requires a controlled stop and recovery.
6. Supplier access is removed for exit.

The scope can be appropriate to the deployment. The important point is that each material dependency has a known containment and recovery path.

After each drill, update the dependency inventory, runbook, ownership map, and acceptance record. The drill is not theatre. It is a way to improve the operating system before the control is needed for real.

What a Failed Drill Tells You

A failed drill is useful when the result remains visible.

If the operator cannot identify the affected routes, the dependency inventory is incomplete. If disabling the provider sends work to an unapproved fallback, the routing policy is unsafe. If pausing the agent loses queued state, recovery design is incomplete. If only the FDE can interpret the result, handover has not passed.

Each failure points to a specific class of work:

• product control missing or unclear
• deployment configuration incomplete
• workflow state undefined
• ownership unassigned
• runbook inaccurate
• evidence insufficient
• client operator not yet trained

The team can correct the right layer and run the drill again.

This is why the measured result belongs in the acceptance record. A supplier that hides a failed test loses the chance to improve the system. A client that treats every failure as a reason to stop testing will enter production with assumptions intact.

The commercial beta stage is an appropriate place to expose these gaps. The product already contains core stop controls. The engagement turns them into a client-operated procedure and identifies what still prevents a clean result.

The honest failure is evidence. The untested promise is not.

<!-- Editorial evidence: E07 in series/bams-no-strings-attached/EVIDENCE-LEDGER.md -->