Organizations, workspaces, and projects

This page explains the hierarchy vocabulary used around Ethen work while preserving the gaps in the current evidence. Read it when you are planning collaboration, deciding where context belongs, or reviewing an access assumption. The shell recognizes workspace and project concepts, but Batch 01 does not verify the complete organization model, creation controls, role inheritance, tenant isolation, or administrative guarantees.

Hierarchy

A useful conceptual hierarchy is organization → workspace → project → session or run, with artifacts and evidence associated with the work they describe. This ordering is a documentation aid, not a confirmed database schema.

When a decision depends on a hierarchy detail in the last column, stop treating the table as operational truth and verify the current product.

This guide presents organizations, workspaces, and projects to be explained as a hierarchy, but the inspected repository does not define a canonical parent-child contract.

A safe conceptual reading is that these terms represent progressively narrower contexts for people and work. Do not assume that an organization always owns a workspace, that a workspace always contains projects, or that settings automatically inherit until implementation sources confirm it.

Organizations

An organization can be described only at a high level in this batch: it is a potential administrative boundary that may group workspaces or people. The sources do not show the exact organization-creation workflow, whether every account belongs to an organization, how multiple organizations are handled, or which settings are inherited.

Do not infer business claims from the term. “Organization” does not establish enterprise tenancy, contractual separation, data residency, billing ownership, domain verification, or a particular administrator role. Those topics require direct implementation or policy evidence.

Before documenting an organization-level procedure, confirm all of the following in the current environment:

• the organization object is visible and named by the product;
• the control operates on the organization rather than one workspace;
• the actor’s permissions are displayed or otherwise verified;
• the effect on existing workspaces and collaborators is clear;
• any security, retention, or legal consequence is supported by an authoritative source.

Until those checks are possible, describe organization needs as planning requirements rather than implemented behavior.

Organization is a useful administrative concept for grouping people, access, and policy, but the inspected sources do not verify an organization page, membership model, billing boundary, directory integration, or delegated administration.

Treat organization behavior as unconfirmed. Administrators should document the actual deployment’s identity source, ownership, approval authority, and policy scope before publishing operational instructions.

Workspaces

The workspace is the strongest grounded hierarchy concept in the supplied platform copy. It is the context in which builders can work across model lanes while keeping relevant prompts, files, artifacts, decisions, evidence, and review notes together where the surface supports them.

A workspace should be treated as an operational scope, not as a guarantee about storage or access. Its practical value comes from making work legible:

• which task or project is being pursued;
• which context was available;
• which model or product surface was used;
• which proposal or result was produced;
• which evidence supports the outcome;
• which review or approval remains outstanding.

The exact creation control, naming rules, ownership model, limits, and archival behavior are not verified. If an interface exposes a workspace selector or title, use it as evidence of the current scope but do not generalize beyond what is visible.

A disciplined workspace practice is to add context gradually. Start with the smallest set of permitted material, label important decisions, and preserve the reason for model or provider selection. This improves reviewability without claiming that Ethen enforces a specific information-governance policy.

Workspace is the strongest supported organizational term in approved product language. Workspace context can connect prompts, files, artifacts, decisions, evidence, and review notes where a surface supports them.

The source pack does not define workspace creation, deletion, naming, roles, quotas, or data residency. A workspace should therefore be described as a working context, not as a guaranteed security or tenancy boundary.

Projects

Projects are recognized by the shell and can be used conceptually to group related work inside a broader workspace. A project might correspond to a product feature, research question, client deliverable, evaluation effort, or recurring workflow. Those are examples of organization, not verified templates.

The current bundle does not establish whether projects can span workspaces, inherit collaborators, own credentials, contain sessions, or control artifacts. It also does not verify project status values, archival controls, duplication behavior, or deletion semantics.

Use projects to clarify purpose:

1. State the outcome the project is expected to produce.
2. Identify the model or product decisions that belong to it.
3. Keep unrelated context outside the project scope.
4. Record important evidence and review notes with the corresponding work.
5. Avoid assuming that a project boundary alone restricts access.

If the current product does not expose a project control, preserve the project idea in naming or documentation rather than inventing a hidden route or API.

The shell recognizes a projects route, which supports the existence of a project concept but not its complete lifecycle.

A project can be described cautiously as a way to group related work inside a broader workspace context. Do not state how projects persist, whether they span sessions, who owns them, or how files and artifacts inherit access without direct evidence.

Isolation boundaries

Isolation is the most important unresolved part of this concept set. The existence of organization, workspace, project, and session language does not prove how data, credentials, models, artifacts, or people are separated.

At least five boundaries require explicit evidence:

Do not replace missing answers with general cloud, SaaS, or workspace assumptions. A navigation label cannot support a claim of tenant isolation, secret separation, or least-privilege enforcement.

For sensitive work, limit context and access until the product’s actual boundary is confirmed. If a task requires a formal guarantee, the relevant security, privacy, and contractual documents must be reviewed in addition to the interface.

No organization, workspace, or project isolation guarantee is established by this batch. Route separation and navigation labels are not equivalent to storage isolation, authorization enforcement, encryption boundaries, or legal segregation.

Before relying on a boundary, verify the current identity model, access checks, data stores, sharing controls, and administrator behavior. Security-sensitive documentation should link to the appropriate verified policy or implementation source when available.

Administration considerations

Administration begins with an inventory of what is known and unknown. Record the visible workspace or project identity, current collaborators, configured providers, linked credentials, available models, approval requirements, and evidence controls. Where the product does not expose an item, mark it unresolved.

Avoid assigning formal titles such as owner, admin, editor, reviewer, or approver unless the current product defines them. Responsibilities can still be planned:

• someone controls access and configuration;
• someone supplies task context;
• someone reviews model selection and output quality;
• someone authorizes sensitive work;
• someone verifies execution evidence.

Those responsibilities may be held by one person in a small workspace or distributed across a team. The documentation should not imply a fixed role model.

When moving work between scopes, recheck context and evidence. Copying an artifact into another project may not carry its route decision, source notes, or approval history. Likewise, opening a session from a workspace does not prove that every workspace item is automatically included in the model request.

This page remains subject to insufficient-grounding and UI-label review. It is suitable for conceptual planning, but not for definitive tenancy, access-control, or administrative procedures.

Administrators need a confirmed account path, role model, membership workflow, policy scope, provider configuration process, and evidence-retention policy before operating these concepts as production boundaries.

Keep an environment-specific inventory of who can create or administer each level, which settings apply, and where changes are recorded. This page remains a draft because those details are not supplied.

Planning a new scope

Before creating or requesting a new workspace or project, write a short scope statement that identifies the work, the minimum context required, the people who need to participate, and the review point for outputs. Keep provider credentials and external integrations outside that statement. If the current interface later exposes formal fields for these details, map the plan to those fields rather than assuming the plan itself creates access controls.

For an existing scope, perform a boundary review before adding a new model lane or collaborator. Confirm which files and artifacts are still relevant, whether earlier decisions remain current, and which provider configuration the next task expects. A workspace can remain understandable only when its context reflects the current objective.

Moving work between scopes

A move or copy can separate an artifact from its supporting evidence. When transferring work, carry the task objective, model or product used, source references, visible status, review notes, and unresolved limitations. Do not assume that session history, approvals, receipts, or credentials travel with the artifact.

If the product exposes no verified move operation, treat the transfer as a new handoff. Re-establish context in the destination and obtain any required review again. This is slower than relying on an assumed hierarchy, but it preserves the distinction between content ownership and execution authority.