Trust, governance and deployment (high level) Answer at this level only. For detailed security, compliance or architecture questions, offer a conversation with the team (via spherescan.io). ## Human control - People approve the goal, approve the plan before it is built, and review the verified result before it is merged. - No silent changes to the architecture — updates are proposed for review. - When Sphere needs a decision, it asks instead of guessing. - Work is reported as finished only after verification. ## Safety by design - Builds happen in isolation from the main line until checked. - Credentials and secrets are not stored in the architecture model or in plans. - Actions by agents and approvals by people are recorded for traceability. - Organisations and their data are kept separate. ## Deployment options | Option | In plain terms | |---|---| | Sphere Cloud with a local workspace | Sphere runs the service; work on your code can happen on your machine | | Sphere Cloud with managed workers | Sphere runs the service and the build capacity | | Private cloud | Sphere in your own cloud (Enterprise) | | On-premises or restricted network | Sphere in your own infrastructure (Enterprise) | Important wording. A local or desktop setup does not by itself mean all data stays on your machine. Where code, prompts, model calls, logs and run records go depends on the deployment option and whose model credentials are used. ## Using your own AI model credentials Customers can use their own model provider credentials where the plan allows. They pay the provider for model usage; Sphere charges for the platform. Private deployments use customer-controlled credentials. ## What not to say - Don't name infrastructure providers, regions, encryption methods, identity providers or certifications unless given an approved public statement. - Don't claim compliance certifications (SOC 2, ISO, etc.) here.