Create your account and workspace
Understand the currently verified account and workspace concepts while avoiding unsupported signup, invitation, role, and administration steps.
Create your account and workspace
This page explains what can safely be said about accounts and workspaces from the current Batch 01 sources. Use it to prepare for onboarding and to avoid confusing workspace concepts with verified administrative procedures. The repository recognizes workspace, project, session, and related shell paths, but it does not establish the exact signup flow, invitation controls, role names, permissions, hierarchy, or isolation guarantees. Those gaps remain explicit review items.
Before you begin
Decide what kind of first activity the workspace must support. A read-only model-research exercise has fewer prerequisites than a configured Gateway run or a task that may later involve approvals and external changes.
Prepare only the context needed for that activity. Approved platform language allows workspace context to include prompts, files, artifacts, decisions, evidence, and review notes when a surface supports them. It does not define a universal persistence period, storage boundary, or access policy for those items.
Before entering sensitive information, review the current product state and the verified Privacy or Terms pages when relevant. This guide cannot replace policy documentation or make retention, security, or contractual promises.
A practical onboarding brief should answer:
- Which Ethen surface will be used first?
- Is the first activity research-only, model execution, or a proposed workflow?
- Which files or facts are necessary?
- Who is expected to review the result?
- Which account or administrative details remain unknown?
This page is intentionally limited. The current product recognizes a shared shell, workspace-related route recognition, projects, sessions, and artifacts as platform concepts, but it does not establish a complete account or workspace onboarding contract.
Use this page to understand what must be confirmed before onboarding: the environment owner, the approved login path, the workspace to use, the data you may introduce, and the current status of the relevant product surface.
Before onboarding, rely only on account and workspace behavior visible in the current environment. Record the active route, product state, and any administrator-confirmed procedure rather than borrowing labels from another service.
Create an account
The supplied repository bundle does not verify an exact account-creation sequence. It does not confirm button text, identity providers, password rules, email verification, organization naming, billing steps, or account-recovery behavior.
Use only the controls presented by the current environment. If the product asks for information, read the surrounding explanation before continuing and avoid assuming that a similarly named control behaves like another service. If an account is provisioned by an administrator or an external process, follow that process rather than trying unverified direct routes.
The following outcomes can be documented without overstating the evidence:
- You gained access to an Ethen environment.
- The environment exposed one or more verified product routes.
- The product displayed a current availability state such as live, preview, mock, or setup-required.
- Additional configuration or administrative help was required.
Do not state that account creation succeeded merely because a public route loaded. Route access and authenticated account state are different facts.
No exact self-service signup route, form, identity-provider flow, verification step, or recovery process is established by the current product surfaces.
A repeatable procedure for the “Create an account” section must identify the exact control, expected result, failure state, and authority responsible for resolving access. Those details are not fully established in this batch. This Create your account and workspace page remains a draft because the complete lifecycle or administration model has not been inspected.
Create a workspace
Ethen’s approved positioning makes the workspace central: it is the place where model-centered work can carry context, outputs, evidence, and review information. The shell also recognizes workspace-oriented and project-oriented paths. However, the current source pack does not verify the exact control used to create a workspace or the data model that connects organizations, workspaces, projects, and sessions.
When a creation control is visible, choose a purpose that is narrow enough to review. A workspace name or description, if requested, should identify the task without embedding secrets or unnecessary personal information. Add context incrementally so it remains clear which material influenced a result.
After creation, verify what the interface actually shows:
| Check | Why it matters |
|---|---|
| Current workspace identity | Prevents adding context to the wrong area |
| Visible product surface | Establishes whether you are in the console, a model surface, or Gateway |
| Availability label or warning | Sets the correct expectation for live, preview, mock, or setup-required behavior |
| Context currently attached | Helps reviewers understand the material available to the task |
| Evidence or history controls | Shows what can be inspected later, without assuming universal retention |
If those controls are absent, record the limitation rather than filling the gap with expected behavior.
Workspace language is supported at the platform level, but the creation control, naming rules, ownership model, quotas, and default settings are not verified.
When a workspace already exists, use the one assigned to your task and keep context scoped to that workspace. When it does not exist, request creation through the current administrative process and ask which project, model access, and policy configuration will apply.
Workspace creation is a recognized platform concept, not a verified self-service workflow in this source set. Stop at the administrator boundary whenever the current product does not establish the next action.
Invite collaborators
Invitation behavior is not verified in the Batch 01 sources. There is no grounded basis here for naming an invitation button, delivery method, expiration period, guest type, domain restriction, or approval flow.
Before inviting anyone through a visible product control, establish the intended scope outside the interface:
- Identify the workspace and the specific task being shared.
- Remove context that the collaborator does not need.
- Decide who should review model outputs or proposed actions.
- Confirm the current product’s invitation and access behavior through its own interface or administrator guidance.
- Recheck visible access after the collaborator joins.
Do not describe a person as having a particular workspace role unless the product displays and defines that role. A successful invitation also does not prove access to every project, session, artifact, model, provider, or administrative area.
The current product surfaces do not define invitation controls, email behavior, directory lookup, acceptance states, expiration, or revocation.
Do not promise that collaboration is self-service. Before adding another person, confirm that the environment supports collaboration and that the administrator has approved the recipient, workspace, and data scope. Avoid using a shell route name as evidence that invitations are implemented.
For collaboration, follow only the access controls visible in the current environment. Preserve the workspace identity, product state, and administrator guidance used for the invitation instead of assuming a standard flow.
Workspace roles
Role names and permission semantics are unresolved for this batch. The safest documentation model is to describe responsibilities without presenting them as implemented role objects.
Possible responsibilities include choosing a model, supplying context, reviewing evidence, approving sensitive work, managing provider credentials, or administering workspace access. Whether Ethen maps those responsibilities to formal roles, and how inheritance or isolation works, requires direct product evidence.
Use a responsibility record while the role model remains unverified:
| Responsibility | Question to resolve in the current environment |
|---|---|
| Context contributor | What material may this person add or view? |
| Model operator | Which configured models and providers may this person use? |
| Reviewer | Which outputs, receipts, or artifacts can be inspected? |
| Approver | Which proposed state-changing actions can be authorized? |
| Workspace administrator | Which access and configuration controls are actually available? |
This table is a planning aid, not a declaration that these are Ethen’s role names.
No canonical workspace role names or permission matrix are available in this batch. The terms developer, operator, admin, and everyone used by this documentation describe documentation audiences, not product roles.
Treat access as environment-specific until a role source is supplied. Ask who can view context, change provider settings, manage keys, approve actions, or administer members. Do not infer permissions from job title or documentation audience.
A repeatable procedure for the “Workspace roles” section must identify the exact control, expected result, failure state, and authority responsible for resolving access. Those details are not fully established in this batch.
Troubleshooting
No signup or account control appears. The environment may use administrator provisioning or another onboarding path. Do not invent a direct URL; obtain current access guidance.
A workspace route is visible but creation is unclear. Navigation recognition confirms only that the shell understands the concept. It does not verify a complete creation workflow.
A collaborator can access more or less than expected. Stop relying on assumed hierarchy. Inspect the current access controls and remove unnecessary context until the permission model is confirmed.
Workspace, project, and session labels appear together. Treat them as distinct concepts. This batch does not verify their exact containment hierarchy or isolation behavior.
You cannot tell whether context persists. Do not infer a retention period from interface history. Keep the claim unresolved and consult the policy or product source that owns persistence.
The product is marked preview, mock, or setup-required. Limit onboarding claims to the controls that visibly work in that state. Preserve screenshots, route information, and status labels for review.
This page remains a draft because the administrative procedures are not sufficiently grounded. It can orient safe onboarding, but it cannot yet serve as a definitive account or permissions manual.
If you cannot access the console, workspace, or expected project, first distinguish an authentication problem from missing authorization or an unavailable product surface.
Capture the route, visible status, and exact error without including secrets. Ask the environment owner to verify account provisioning and workspace assignment. Do not retry by creating alternate accounts, sharing credentials, or following unverified routes. This page remains a draft because the required UI and role evidence is not present.
Troubleshooting should not become an invented self-service workflow. When the interface and inspected sources do not establish a corrective action, preserve the evidence and escalate through the current administrator path.
Before onboarding instructions are published, the environment owner should record the active sign-in route, identity source, account recovery path, workspace creation authority, membership process, and role definitions. The record should also identify who manages provider credentials and who approves state-changing work.
Until those facts are available, a user-facing procedure should stop after directing the reader to the authorized administrator. It should not substitute common labels such as Sign up, Invite member, Owner, or Admin unless those labels are visible in the current implementation. This protects readers from following a plausible but incorrect flow.