Workspaces and teams

Sciple’s user model is intentionally small. Six entities cover everything: workspaces, users, groups, services, owner groups, and environments. Permissions and ownership are expressed by linking these together.

The entities

Every install starts with a workspace. A workspace contains all of an organization’s users, services, AWS accounts, and configuration. Inside the workspace, the other entities live as flat collections.

• Users. People who log in. Sourced from SSO or local accounts.
• Groups. Named collections of users with a specific permission set.
• Services. The things the workspace ships. Each service has metadata.
• Owner groups. The group accountable for a service. Drives on-call routing.
• Environments. Deployment targets. Services join the environments they ship to.

How they relate

A user belongs to one or more groups. A group carries a permission set. A service points to one owner group. A service joins one or more environments. Pipelines are owned by a service-and-environment pair. Configuration attaches to a service, an environment, or both. Credentials are referenced by other modules through foreign keys, never copied.

The point of the model is that there is exactly one place to look up who owns what and who can do what. Once a service is registered, every other module recognises it. Once a group is granted a permission, every module enforces it. The user model and the feature surface are tightly coupled by design.

Groups carry permissions

Permissions are named, registered, and grouped into named groups. A group declares which permissions it grants, and every user in that group gets exactly that set. Adding a permission to a group is a checkbox in the dashboard, not a code change. The catalogue of permissions stays in sync with what each module actually checks.

See Access and audit for the full permission catalogue and the audit trail that records every change to it.

Owner groups are first-class

Every service has exactly one owner group. The owner group is what drives on-call routing, notification fan-out, and "who do I ask?" workflows. The AI assistant uses it to answer queries like "show me all tier-1 services owned by the Platform Team that are missing a runbook."

Environments are joins

Environments are not a per-service property. They are first-class rows that services join. This is what lets the configuration system have a real four-level hierarchy: global, environment-group, service-and-environment-group, and service-and-environment. The lowest level wins.

API keys for service accounts

Machine-to-machine integrations use API keys scoped to specific groups. An API key is a user-equivalent principal that you can rotate, revoke, and audit independently of the humans on your team. Every action an API key takes is recorded in the audit log with the key as the actor, so service-to-service changes never get lost in the noise.