Learning & workspaces
Choose the learning scope independently from identity, storage and execution.
Four boundaries to define
- Account
- The authenticated DID identifies the account. ATProto and the configured PDS provide the portable identity and registration path. Never trust an account ID supplied in a browser request body.
- Workspace
- Define the owner, project, permitted contributors, retention and export behavior for context, files, artifacts and activity. A workspace is a durable product boundary; a sandbox is a replaceable execution environment.
- Learning scope
- Choose the authorized individual or organization whose data may contribute to adaptation. Model sharing never grants access to underlying private records.
- Serving scope
- Specify who can use a model revision, which base model it requires, and which fallback to serve if it cannot be loaded.
A PDS account does not mean every private file, training example or model weight is stored in a public ATProto record. Document the actual storage and permissions of each data category.
Choose a learning strategy
| Strategy | Good starting point | Boundary to enforce |
|---|---|---|
| Context only | Base model with persistent context or retrieval, before training demonstrates value. | Retrieve only material this user may access. |
| Individual LoRA | Stable personal preferences or tasks with enough authorized examples to justify adaptation. | Keep datasets, adapters and evaluation specific to that individual. |
| Organization LoRA | Shared domain vocabulary, procedures or workflows. | Use approved organizational material; individual activity is not automatically eligible. |
| Combined | Organization adaptation with private personal context; optional personal adaptation later. | Do not assume adapters can be stacked or merged. Validate compatibility with the chosen serving system. |
LoRA means low-rank adaptation: a smaller set of trained weights used with a compatible base model. It is one adaptation method, not a requirement for having an account or workspace.
Design the continual-learning lifecycle
- Collect authorized evidence. Record provenance, applicable consent, ownership and the intended learning scope. Saving a chat is not permission to train on it.
- Curate a dataset. Separate training and evaluation examples, minimize sensitive content, and preserve the ability to trace examples to their source.
- Train a candidate. Select the base model, adaptation method, trainer, budget and cancellation policy. Continuous learning can be scheduled or triggered; it need not retrain after every message.
- Evaluate before promotion. Compare against the current revision on relevant tasks, regressions and isolation. More data does not guarantee a better model.
- Deploy and verify. Load the candidate in the actual serving provider and complete an authorized inference check before directing users to it.
- Promote with rollback. Record the active revision and its evidence; keep a known-working fallback. Monitor results and decide whether another training cycle is worthwhile.
Existing platform contracts
The gateway already contains account-scoped evolution primitives. These manage artifacts, evidence, jobs and active revisions; they are not a generic hosted LoRA trainer or proof that a model has been loaded into an inference provider.
| Purpose | Route | Capability |
|---|---|---|
| Register an artifact | POST /v1/evolution/artifacts | evolution:write |
| Store or retrieve content | PUT / GET /v1/evolution/artifacts/:digest/content | evolution:write / evolution:read |
| Record evidence | POST /v1/evolution/evidence | evolution:write |
| Create or run a job | POST /v1/evolution/jobs POST /v1/evolution/jobs/:jobId/run | evolution:execute |
| Inspect or cancel a job | GET /v1/evolution/jobs/:jobId POST /v1/evolution/jobs/:jobId/cancel | evolution:read / evolution:execute |
| Read or change the active revision | GET / PUT /v1/evolution/active-revision | evolution:read / evolution:write |
Use the repository contracts in packages/contracts/src/account-evolution.ts for request schemas. Artifact content uploads have a 64 MiB gateway limit; plan large weight storage with the operator rather than assuming these uploads support arbitrary adapter sizes. Compare-and-swap revision updates protect against concurrent promotion.
Ordinary browser sign-in does not grant these evolution capabilities. Request the required trusted integration and runner setup during review. An unconfigured evolution service returns evolution_unavailable.
Organization ownership is an integration decision
The existing evolution API uses account and product authorization, with project context. There is no new self-service organization-membership or organization-LoRA endpoint introduced by this guide. Agree on the organization’s principal, membership enforcement, workspace access and dataset scope before enabling shared learning. Do not represent a shared organization simply by accepting a caller-supplied DID.
Make data ownership actionable
Specify export formats, retention, revocation and deletion behavior for source data, derived datasets, artifacts and provider copies. Source-data ownership, base-model licensing and adapter portability are separate commitments. Do not promise that deleting a source record removes its influence from a trained model; define whether retraining or retiring the adapter is required.
Expose understandable controls in the application. Explain which actions affect the current user, the organization, or a shared model. See Data & privacy for existing storage boundaries.
What needs verification for launch
Not Organic is connected to Keating, Twyne, Interleave and Stich. Identity, authorization and account-evolution code exist today. Managed LoRA training and serving, organization provisioning and complete workspace portability must be configured and verified for the specific integration; these pages do not establish that those paths are operational for every customer.
During review, agree on data scope, supported base model, training provider, serving provider, evaluation criteria, costs and rollback. Then demonstrate a real training-to-serving cycle using authorized data before describing that learning path as live.