Crew members
A crew member is an AI worker. It is modelled as a stable handle plus a chain of immutable, versioned definitions.
Handle vs. version#
crew_membersis a stable handle with pointer fields only (e.g.active_version_id).- The actual definition — objective, instructions, tools, rules, rigidity — lives in
crew_member_versions, which are never edited after they leavedraft. - Every run pins the exact
version_idit executed, so history is reproducible.
Editing a published member forks a new draft; publishing advances active_version_id. This is
the immutability rule that keeps runs auditable.
Rigidity#
Rigidity is the one knob the user sees. It has four plain-language stops:
| Stop | Meaning |
|---|---|
| Strict | Follow the steps exactly. |
| Guided | Ask before any external effect (the default). |
| Adaptive | Work out the steps within guardrails. |
| Autonomous | Run end to end on its own. |
Users never see the underlying ScaiCore directives; the compiler translates the stop (combined with each tool's effect class) into the right enforcement. Rigidity feeds directly into approvals.
Implemented today: the Strict and Guided run path is complete. Adaptive/Autonomous depth is being rolled out — the object model and compiler already represent all four stops.
Publishing#
Publishing a draft (see the API reference):
- Compiles the version to a deterministic ScaiCore program.
- Stores the compiled artifact.
- Provisions the member's own ScaiKey identity on first publish.
- Activates the version, with an audit-log entry.