How to launch a SparkPilot pilot without confusion
SparkPilot starts with a guided pilot led by our team. Begin with pilot kickoff, then move into authenticated onboarding for setup and run operations.
Pick your starting point
Choose the path that matches your role so buyer and operator workflows stay separate.
I want a realistic pilot plan and a technical walkthrough for my team.
I already have workspace access and need to continue onboarding or run operations.
I own first-time setup and need access to onboarding and access controls.
Role-based tracks
Pilot owners and platform admins have different responsibilities during setup and evaluation.
- Start with a pilot kickoff call to define scope and success criteria.
- Confirm one workload family and one owner from platform engineering.
- Use pilot checkpoints to evaluate operational fit and commercial fit.
- Pilots are guided so teams can evaluate quickly with clear success criteria.
- Complete authenticated onboarding once, then onboard users with role mapping.
- Validate OIDC trust, execution role bindings, namespace rules, and budget limits.
- Run the first governed job and share pilot outputs with stakeholders.
- After pilot sign-off, expand environments and user access in phases.
Recommended pilot sequence
Follow these steps in order to keep pilot execution clean and measurable.
Share your workload profile and goals so we can scope a focused pilot with clear success criteria.
Align environment ownership, identity model, and timeline before setup starts.
Platform admins complete authenticated onboarding to validate IAM, OIDC, namespace, and dispatch prerequisites.
Run one governed workload, review diagnostics and cost visibility, then decide production rollout next steps.
Command line quickstart (after sign-in)
Use these commands after sign-in for operator workflows and CI automation.
sparkpilot env-listsparkpilot run-submitsparkpilot run-listsparkpilot run-logs
Use the same authenticated workspace context as the dashboard and API.