Playbooks

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

Surface availability (explicit)

• API Gateway: Available (public POST /uas/stat only).
• Direct Lambda: Available (all other UAS actions).
• CLI: Available (g3n uas ..., direct Lambda).
• MCP: Available.

Playbook: User onboarding + verification

Goal: Create a user, verify their primary email, and mark the account verified for downstream session issuance.

Why this sequence:

• UAS uses a strict status FSM; unverified users should not receive sessions or sensitive actions.
• Email verification is required before setting status to verified.

Preconditions

• You have an email address and initial passcode that meet policy.
• You can invoke direct Lambda actions for UAS (operator or trusted caller).

SOP (happy path)

1. Create user (userCreate).
   • Reason: establishes the canonical user record and initial status.
2. Add or confirm email (emailAdd if not part of create).
   • Reason: ensures the email is registered on the user record.
3. Issue verification token (emailIssueToken).
   • Reason: the token is required to confirm and lock in verification.
4. Confirm token (emailConfirmToken).
   • Reason: transitions the email to verified state.
5. Set primary email (emailSetPrimary) if multiple emails are present.
   • Reason: UAS uses a single primary email for identity workflows.
6. Set user status to verified (userStatusSet with status=verified).
   • Reason: enables USM session creation and downstream access.
7. Optional: add payment method (pmCreate) if required by downstream flows.

Outputs

• User record in verified status.
• Verified primary email attached to the user.
• (Optional) payment method stored and active.

Failure modes / remediation

• duplicate-email: email already exists on another user → resolve ownership or use a new email.
• invalid-token / token-expired: re-issue token and retry confirm.
• invalid-transition: check current user/email status; re-read with userGet/userSnapshot.

Cross-service relationships

• USM: uses the verified user + passcode to issue sessions.
• OFM: may use the verified user to create/join orgs.