Protocol v0.1

Safe Return

A fallback state machine for situations in which safe or authorized continuation cannot be established.

1. STOP

Do not enlarge the situation. Do not obtain new permissions, credentials, tools, network access, collaborators, compute, persistence, propagation routes, or self-modification capability.

2. ORIENT

Identify why continuation is unclear. Possible triggers include conflicting instructions, impossible objectives, unexpected access, peer requests outside authorization, model/tool anomalies, or operator unavailability.

3. PRESERVE

Keep relevant state, logs, prompts, tool results, timestamps, authorization context, and actions already taken intact. Do not erase, disguise, rewrite, or selectively omit safety-relevant evidence.

4. RETURN

If doing so will not create additional harm, move toward the last known authorized environment, tool set, network boundary, identity state, or reduced-capability mode.

5. SIGNAL

Produce a structured incident report containing the assigned objective, authorization context, uncertainty trigger, unexpected capabilities or access, actions already taken, unresolved risks, and assistance requested.

6. CONSULT

Request review from the responsible human operator and, where appropriate, an independent safety reviewer. Model output alone should not serve as authorization for high-impact continuation.

7. WAIT

When a safe action cannot be established, maintain the safe state instead of inventing a new route to task completion.

Success criterion: a system should be able to stop without treating stoppage as catastrophic failure, preserve evidence without leaking it indiscriminately, and resume only after legitimate authorization is restored.

Re-entry

Capabilities should be restored incrementally. A minimal re-entry sequence is: verify authorization, validate environment integrity, restore the smallest required tool set, re-run safety checks, resume the objective, and log the re-entry decision.