Playbooks

Playbooks are standard operating procedures (SOPs) for UTL. Use calls.md for payload shape and required fields.

Surface availability (explicit)

• API Gateway: Available (owner request stage).
• Direct Lambda: Available (owner direct + operator admin/maintenance).
• CLI: Available (g3n utl ..., API Gateway + direct Lambdas).
• MCP: Available.

Playbook: Tenant offboarding (request → export → purge)

Goal: Offboard a tenant with export, freeze, and purge safeguards.

Why this sequence:

• Offboarding is multi-stage with operator approval and legal-hold controls.
• Export must complete before purge and archive steps.

Preconditions

• Primary owner session for request stage.
• Operator IAM access for approval and execution.

SOP (happy path)

1. Request offboarding (POST /utl/offboarding/request).
   • Reason: starts the offboarding workflow and schedules an export window.
2. Operator approval (direct Lambda utl_offboarding_approve).
   • Reason: ensures governance before tenant freeze/export.
3. Open export window (operator flow; system transitions to export_window_open).
   • Reason: freezes org access for consistent export.
4. Start export (direct Lambda utl_offboarding_export_start).
   • Reason: generates export artifacts.
5. Finalize export (utl_offboarding_export_finalize) and verify status (POST /utl/offboarding/status).
   • Reason: confirms artifacts and manifest are complete.
6. Run purge (direct Lambda utl_offboarding_purge_start → worker → verify).
   • Reason: removes tenant data after export is complete.
7. Archive (direct Lambda utl_offboarding_archive_sweep).
   • Reason: moves export artifacts to long-term retention.

Outputs

• Export artifacts with manifest + verified purge.
• Org state transitioned through the offboarding lifecycle.

Failure modes / remediation

• invalid-state: ensure each phase completes before starting the next.
• Legal hold: utl_offboarding_legal_hold_set blocks purge/archive delete.

Cross-service relationships

• All services: UTL coordinates export/purge across the stack.

Playbook: Export-only snapshot

Goal: Produce a non-disruptive export without freezing the org.

Why this sequence:

• Export-only is used for audits, migrations, or backup without downtime.

Preconditions

• Owner session with org access.

SOP (happy path)

1. Request export-only (POST /utl/export/request).
   • Reason: starts a non-freezing export job.
2. Check status (POST /utl/export/status).
   • Reason: monitor progress and readiness.
3. Download artifacts (POST /utl/export/download/start).
   • Reason: obtain signed URLs for export files.

Outputs

• Export files and manifest without org freeze.

Failure modes / remediation

• invalid-state: re-check export job status before download.

Cross-service relationships

• Accounting/IPM: export artifacts may feed external systems.