Admin follow-up contextOnboarding
You navigated here via the admin Week 8 readiness summary. Continue the targeted onboarding, billing, verification, or go-live review for this workspace, capture the outcome on that surface, then return to the filtered admin readiness view. This is navigation-only context and does not change identity, impersonate a member, or automate remediation.
Audit export continuity
Reuse the same Latest export receipt from /settings so the filename, filters, and SHA-256 stay chained from settings through verification, go-live, and back into this admin handoff. This manual evidence relay is navigation-only; open the receipt, carry the proof in the workspace surfaces, and then return here to complete the queue or readiness loop.
Current workspace: default · Requested from admin: default · Week 8 focus: Go-live ready
Treat this as the manual admin → workspace surface → admin loop: follow the requested surface, capture evidence or outcome notes there, then use the return link below to restore the admin context and keep the focus state aligned.
Returning keeps the same admin filter state in place so the operator can continue the governance review without rerunning the drill-down manually.
Launch lane context
This onboarding lane is the manual workspace launch hub for Week 5 and Week 8 readiness. It helps you create the workspace, bootstrap the baseline, issue credentials, run the first demo, and hand evidence into verification without implying support automation.
Current workspace: default · Context source: Environment fallback (non-production)
This sequence is still navigation-only across the console. Each surface keeps the same workspace handoff, but inviting, credential issuance, running, and evidence capture are all manual operator steps.
Trusted session reminder: if the active identity or workspace context looks off, go back to /session before continuing into members, onboarding state mutation, usage evidence, or Week 8 verification/go-live follow-up.
Invite-to-accept path
Week 5 onboarding starts with inviting the first reviewer, operator, and approver. Use the Members panel to create a one-time token, share it off-band, and then have the recipient redeem it at /accept-invitation before switching into this workspace context.
After acceptance the new member can follow the role lane (viewer → verification, operator → playground, approver → go-live) while you keep dashboarding onboarding, billing, verification, and go-live evidence manually.
Pending invitations reserve seats even before redemption, so members and onboarding readiness can be blocked by seat pressure before the invitee reaches usage or verification.
Launch and onboard a workspace
Create a workspace, seed the baseline provider and policy bundle, then track the first operational actions until the first demo flow is ready.
Step 0. Confirm session and launch context
Treat session, workspace, and plan posture as the first onboarding checkpoint before mutating anything.
This wizard is still a manual launch hub. Before creating a workspace, bootstrapping baseline, or issuing credentials, confirm the active session context and decide whether current plan posture leaves room for the first run.
Nothing here auto-provisions a customer workspace end-to-end. The wizard helps sequence the work, but the operator still owns each launch decision and evidence handoff.
Step 1. Create workspace
Create a workspace, then keep using this page as the persistent onboarding hub for that workspace.
Slug is auto-suggested from the workspace name until you edit it manually.
After creation, return to the session checkpoint if the new workspace or tenant binding looks wrong before continuing with bootstrap or credentials.
Progress
Each step unlocks the next one.
Workspace skeleton
Organization mapping and tenant binding
Baseline governance bundle
Bootstrap providers and policies for first-run safety
First operational actions
Service account, API key, and first demo run
Step 2. Bootstrap baseline
Seed the minimum provider and policy deck for a safe first demo run.
This creates a small, deterministic seed set based on the workspace id, so re-running does not create duplicates.
Baseline bootstrap is still a guided operator step. It does not send support requests or complete the rest of onboarding automatically after providers/policies land.
Step 3. Next actions
Turn baseline setup into a first demo-ready workspace.
Guided lane
Use the same workspace context for the full first-run path: invite the first operator or approver if needed, create one service account, mint one `runs:write` API key, run the first demo in Playground, then capture evidence in Verification.
Recommended next step
Bootstrap baseline
Baseline providers and policies must be ready before credentials and first run.
Current blockers
- Workspace is not created in a persistent SaaS context yet.
- Baseline providers and policies are not bootstrapped.
- Service account is missing.
- API key is missing.
Plan and usage awareness
Before sending the first governed run, confirm that plan posture and current-period usage still support the lane you are about to exercise.
Usage is still empty for this workspace period, which is normal before the first run. Keep this lane in mind so the first run has a clear plan and billing story.
Current usage window
-
Carry this billing window into verification evidence so plan pressure, onboarding readiness, and upgrade follow-up stay tied to the same period boundary.
First demo run
Finish the baseline, service account, and API key steps before invoking the run.
Follow the guided onboarding lane
Baseline providers and policies must be ready before credentials and first run.
Evidence and rollback prep
Capture verification evidence before widening rollout, and keep rollback ownership, settings review, and run replay context ready in case the first demo needs another pass.
The clean manual relay is: Playground proves the run, Usage confirms the signal, Verification records the notes, Go-live rehearses the next gate, and Session remains the safe place to re-check context if anything feels off.
Audit export continuity
Keep the Latest export receipt from /settings in play: reuse the same filename, filters, and SHA-256 throughout verification, delivery, and go-live notes so the admin handoff can cite the same evidence thread.
This is navigation-only and a manual relay; the links do not attach the receipt automatically or resolve rollout issues for you.
Use these actions to continue the guided walkthrough.
Members
Invite the first viewer, operator, or approver when the workspace needs shared governance.
Service account
Create one active machine identity for the first workload.
API key
Issue and store the first active secret for northbound access.
Demo runs
Runs started from the onboarding Playground flow.
First-run quickstart
- 1. If the workspace is shared, invite the first viewer, operator, or approver from Members.
- 2. Create a service account scoped to the first workload or external runtime path.
- 3. Generate an API key that includes
runs:write; store the secret and keep it handy for the first external run. - 4. Use the one-time secret with your agent client or a curl call against
POST /api/v1/runs, then return to Playground to inspect or reproduce the same flow in console context. - 5. After the run succeeds, open Verification to capture the evidence before widening scope or moving into go-live rehearsal.
The first run only needs a simple JSON payload and a bearer key. Playground stays useful as the in-console surface for validating the same path after the external API call succeeds.
Recommended sequence: members if needed, then service account, API key, Playground, and Verification.