Architecture

The single most important structural idea is that ScaiCrew owns a control plane and is a thin orchestrator over an execution / substrate plane of pre-existing services.

Control plane (this product)#

• The crew-member object model and versioning
• The conversational authoring orchestrator
• The trigger scheduler and webhook ingress
• The compiler (crew-member definition → ScaiCore program)
• The run dispatcher
• User login and the Bridge read models

Execution plane (existing services)#

The boundary is firm#

• ScaiCrew computes when approval is needed; ScaiQueue enforces it.
• ScaiCrew compiles to ScaiCore directives but never executes them itself.
• ScaiCrew references secrets by ScaiVault handle but never holds plaintext.

Anything beyond single-branch handoff orchestration is exported to ScaiFlow, not built here.

Load-bearing invariants#

• Workspace is the hard tenancy boundary. Every control-plane row carries workspace_id, derived from the caller's token — never from a request body. See Workspaces.
• Each crew member is its own identity. Substrate access happens as that identity, so every action is attributable and independently revocable. See Identities.
• Definitions are immutable, versioned records. Every run pins the exact version it executed. See Crew members.
• Approval is computed from rigidity × effect class. See Approvals.
• The compiler is pure and deterministic. The same draft compiles identically however it was produced (chat, form, API, or template install).
• Secrets only ever live in ScaiVault, referenced by handle everywhere else.